Hi thanks for your reply.
I'm trying to implement a portamento/glide to go from one value to another - thought I'd expand on it a little.
I tried your suggestion but there does not seem to be a curve occurring it seems to only scale the output. Which now that I think about it seems like an expected outcome for pow - do I need a more complex formula?
Here's my very basic testing patch - in case there is anything I've done completely wrong.
i have made a bunch of such expressions ... but it is really bit difficult to
have a set of expressions sitting between a multipoint ramp in order
to turn all the linear moves of different ranges into s-curves ... i wouldnt
what about using curve~ and converting to the signal to messages?
you can use curve~, connect it to a number~ object and out of the number~ right outlet you will get numerical data. i have used this for fading sound files up and down in a logarithmic and exponential fashion.
It's for a Midi Effect in Max4Live so I figured I'd try to keep it non-MSP thinking it would save CPU but it seems to be more trouble than it is worth. Especially since CPU is much less of a problem than Midi clogging is.
I tried curve~ with both number~ and snapshot~ with the later working better because it can get down to a finer resolution. But anything below a 10ms snapshot seems to knock my synth out of tune.
At 10ms the tuning is correct but even with a 1 ms curve~ ramptime there is an audible portamento (which, I'm guessing as you say Roman is the peak values getting lost)
Could a way around this be to use curve~ into a buffer~ use index and some scaling? that way there would not need to be an expr on each value leaving a [line].