@whale-av - thanks David! that is pretty much indeed what would work for me. oddly enough i play with only one speaker so most of my samples are actually mono, so i don't need it to load stereo sounds into two separate buffers. i did notice the sample start end issue while looping. if i set the end point for the absolute end of the sample i get clicking and the sample doesn't repeat/loop. i was able to solve the issue by moving the end point in from the edge a very small amount and then it behaved fine. i don't currently require the total loop length to the last sample, and may never need to worry about it really.
the only other issue was that the loop region couldn't be set to a really small size. i got pretty close by changing the [metro] timing rate to 10 from 100, though. honestly this is just about everything i need to move forward, so thanks immensely!
thanks to both of you for your reply! @seb-harmonik.ar - i'll check out your approach, as loop~ was getting pretty close to the behavior i wanted in the first place and i couldn't figure out how to get reverse playback.
@porres, actually i would be completely satisfied with current behavior in [player~]. just add the ability to create a loop size without resizing the buffer. this is pretty much what the [groove~] object does in MaxMSP - look at the attributes section:
the [wave~] object in MaxMSP to my recollection is a bit of a different beast, as it's limited to a very small amount of samples (or it used to be anyway) and is intended for wavetable synthesis, not sample playback from a buffer per se. however looks like the current version in Max removed that sample length limitation though, and works in a similar manner. biggest limitation i can see about it though, is possibly no ability to change pitch, or do reverse playback, both requirements for me. i might be wrong but i don't clearly see those options.
let me check cyclone's [wave~] object reference...okay it looks like variable speed playback and reverse is supported and there's no sample length limitation. but resizing loop length really messes around with the sample playback rate and i'd prefer it not change pitch/rate while that happens.
i think i would put a request in for a feature change add for [player~], as i think it would be helpful to others to have at least one object that could have adjustable loop size as well as directional varispeed.
cool! thanks for the clarification. it was a bit confusing.
so i tried the moop~ external and its interesting! it looks quite versatile. i tried it with a 15 sec sample and playing around with the presets i found that about 2/3 or them would produce sound i could hear. i'm obviously inexperienced so i could have easily done something to encourage wonky behavior.
anyway, despite that, enough of the settings worked that i could see its capability. it looks like it does forward/reverse and the pitch change via the [mtof] object and there's a lot of ability to chain together sequences of buffer positions for a complex effect (although it seemed like most of them were non looping).
but the pitch change offered by the (fake i think?) [times $1 pluto] isn't quite what i want in terms of varispeed. i need a more traditional speed control, more like a DJ scratch or pitchwheel scratch but with a variable loop size. is it possible you could give me some tips on getting that into the help patch of moop~? i'm assuming i need something like a [line] or manually driven [phasor~]. i'm pretty inexperienced at this digital signal theory. for example, it's weird how you can drive either input of [sig~],[*~], etc in order to get pitch change. still wrapping my around that...
hey folks, i'm sure this can't be a new issue but i'm using PD 0.49 using the [loop~] object (it's in the else library as well as ceammc] and i'm on the warpath to create a variant to **[loop~-help.pd] **that allows reverse, and maybe improve the looping performance so it clicks a bit less. here's a screen:
i've also been looking at the ELSE library from @porres. there's a lot of objects there that could work, but i need to be able to change loop size and the help file for these doesn't seem to indicate that any of the objects can do this - it seemingly loops the whole length.
any assistance on either of these issues would be helpful - thanks!
hey folks - greetings to the board!
i'm in the middle of designing a pretty simple sample playback and recording setup and i've consistently run into some issues that i seem to only be able to solve by using [del] which i know is generally discouraged. but it doesn't seem to work properly in the accepted way using a trigger. here's an example where i get the size of an array:
[t a b]
| ___ (
so, what happens in this case is when i bang the [array size] object, the blank message box at the very bottom is updated (it's connected to a send object which i did not draw) but its value is not sent by the bang coming from the trigger object. if instead i insert a [del 25] object after the bang outlet everything works properly. i'm pretty sure i'm likely not doing something right but to me it looks like the bang happens too fast and doesn't have time to send the message out, but i've seen this behavior when reading from [openpanel] too, and when switching between arrays. see the pic below.
can anyone shed some light on this situation? it seems like [trigger] should work but it's consistently late.
thanks in advance!