buffer~ ramping with play~
I’m trying to use play~ to read through a buffer~ at variable speed and curve. I tried this in two ways, one with regular numbers converted with sig~ and one all in MSP. The former just produces some clicking, while the latter does nothing. I could easily be missing something important, as I have more experience with Jitter than MSP.
I would prefer the first method because I am already using it to control another parameter in my larger patch (actually, I would prefer to use bline for efficiency, but found it got too complicated trying to run both the up and down parts of the ramp with one metro).
Please see both examples attached. Hear they use an ezadc~ to fill the buffer, but my patch uses spigot~ and derives the duration from the movie length.
On another note, is there a method I could use to fill a multislider with the unscaled ramping values, similar to point scroll mode except editable (and not scrolling)? I could use something like zl group or stream, but the list will vary in length so I need something like zl queue that would output the entire list with one bang.
Thanks,
Zach
Any help here? As mentioned, I could easily be forgetting something simple.
Sorry to ping this again, but does anyone have an inkling of what’s going on here? I implemented the first example above in a larger patch and all I get is a distorted clicking sound.
Since the sig~ object translates any numerical input (which does not occur at signal rate) into a fixed value (at signal rate), every signal value in that vector is going to have zero slope. Since the play~ object expects a positive slope for any forward playback (or a negative slope for reverse playback), you’re going to have a problem, aren’t you?
Unless you’re feeding those numbers at signal rate (which you aren’t), you’re actually dealing with a step function. I’ll wager that the clicks you’re hearing are the discontinuities between the horizontal data output of the sig~ object from vector to vector. You need something that outputs data at signal rate (line~, function).
Then again, I might be wrong.
Gregory, I think you’re spot on. I have those same numbers driving my video and feel foolish for not recognizing the difference between video and audio in this regard (that audio rate is obviously much faster than persistence of vision so I’m left with more gaps than actual signal). I should be able to correct this tonight, but I’ll update if I have any more trouble. Thanks!
I think that you must drive the play~ and bufffer~ size with two different number box. I think that the the problem is in the factor (7656) mult… is very large to read a play buffer if you use a raping exponent > 1. For the other I agree with the Raja and Taylor. Ciao
It sounds fine just throwing a rampsmooth~ in before play~. However, I am always experimenting with different ways to do this and may find one that works better for audio.