buffer~ ramping with play~
|
Dec 20, 2009 at 9:55pm
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, – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
– Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
|
|
|
Dec 21, 2009 at 9:54pm
Any help here? As mentioned, I could easily be forgetting something simple. |
|
|
Jan 6, 2010 at 2:28am
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. |
|
|
Jan 6, 2010 at 2:50am
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. |
|
|
Jan 6, 2010 at 6:17pm
|
|
|
Jan 6, 2010 at 7:39pm
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! |
|
|
Jan 8, 2010 at 10:48pm
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 |
|
|
Jan 8, 2010 at 11:40pm
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. |
You must be logged in to reply to this topic.