Forums > MaxMSP

Restart a Ramp in signal rate

June 21, 2012 | 2:12 pm

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. –

June 21, 2012 | 2:46 pm

solution is a one sample delay..

– Pasted Max Patch, click to expand. –

June 21, 2012 | 9:16 pm

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 [%~]


June 21, 2012 | 11:31 pm

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


June 22, 2012 | 7:41 am

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


June 22, 2012 | 9:42 am

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.


June 22, 2012 | 10:00 pm

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?


June 22, 2012 | 10:50 pm

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.


Viewing 8 posts - 1 through 8 (of 8 total)