Restart a Ramp in signal rate

Jun 21, 2012 at 2:12pm

Restart a Ramp in signal rate

Hello!
I have been trying to create some Kind of ramp from 0. 1. that can be reset at signal rate. I find it a little bit sad that the Phasor object doesn’t have this feature internally, but i found a very interesting solution here:
http://cycling74.com/forums/topic.php?id=37888
Anyways, i think after one day of thinking and trying around i coulnd’t come up with it myself which is a pity and speaks of my intelligence but also of a lack of usability of the ramp generators in max.
My last try befor searching on the forums was with an adsr(adsr~ 1000. 0. 0. 0.) object. I thought it is great because it outputs a linear ramp as i need it and can be started at signal rate. Then i tried to make it loop using a delta~ object to detect the end of the ramp. That brought me a lot more confusion(/bugs?)! Is there some kind of bug, could anybody try explain me what happens there?
Cheers!

– Pasted Max Patch, click to expand. –
#46071
Jun 21, 2012 at 2:46pm

solution is a one sample delay..

– Pasted Max Patch, click to expand. –
#165937
Jun 21, 2012 at 9:16pm

Using send~ / receive~ won’t be doing quite what you want here unless you have a vector size of 1. You could gen~ for single sample feedback instead.

Anyway, I’m not sure what your objective is. Was there a problem with the solution you found in the other thread? If this is just an intellectual exercise, you could try a solution using [+=~] and [%~]

#165938
Jun 21, 2012 at 11:31pm

Thanks for the answer, i eventually came up with the [+=~] solution too. I was building a signal rate sequencer/Sampler everything working already. Nevertheless, as the famous “i hate sample accurate patching”-thread says.. one really has to scratch one’s head for some time to find simple things as a sample accurately timed ramp, or something i wanted to achieve with an adsr there(i needed a value of one triggered by a [click~] that stays there for a specified time and then returns to zero), which is obviously not the best solution.
Thanks for pointing out that the send/receive~ pair introduces more than one sample delay.
i posted the whole thing for two reasons:
1. Confusion about the behavior without the delay.
2. Surprise that my objectives are quite simple things but not that easy when trying to stay sample accurate since some objects(eg. phasor), don’t accept signals as i would like it :)
cheers

#165939
Jun 22, 2012 at 7:41am

It’s partly a case of getting used to the MSP way of doing I think; it certainly took me a while also. Did you check out [zigzag~] also? It’s pretty versatile.

I used to find myself jumping into mxj~ quite a lot for this sort of thing, but have found that there’s a surprising amount of goodness to be had out of the stock objects (with an option on gen~ if I really do need single sample feedback).

Glad everything’s working now

#165940
Jun 22, 2012 at 9:42am

With [+=~] you’ll get a large number very fast. And there’s a limit to the amount of numbers Max can represent. So I don’t know if that’s the way to go. I would use the solution I gave in the other forum topic. The one with the [phasor~]. I don’t understand how that wouldn’t be usable. But maybe I’ll have to know more about the context you want to use this in.

#165941
Jun 22, 2012 at 10:00pm

That’s a good point Dave, but I’m not sure how problematic it would be in practice. When the max value is reached it should just wrap, no?

#165942
Jun 22, 2012 at 10:50pm

I’m not sure if it wraps or keeps hanging at its maximum value. But both cases are not really desirable. I think you’ll have to reset [+=~] at some point.

#165943

You must be logged in to reply to this topic.