19 Dec
2002
19 Dec
'02
9:38 a.m.
On Thursday 19 December 2002 04.23, Tim Hockin wrote:
nonono. I always envisioned a ramp as being finite. That's the
whole point of the duration field. "Ramp to this value over N
frames" where you know (timestamp + duration) <= (buffer_start +
nsamples)
The duration + target level interface is the "only" way to do this
right - that's the primary reason to use it. The alternative would be
to use only slope, but that would mean you have to know the current
value, and - what is worse - you become dependent on the accuracy of
that value, as any rounding errors will build up through chains of
ramps.
A second reason not to view ramps as finite is that it requires
receivers to do one of two things:
1. Test for the target value for each sample. (Inner
loop conditional!)
2. Prequeue an event to itself to stop the ramping at
the right point. (Means you have to scan the event
queue for the right place to insert this event.)
Meanwhile, the sender must keep track of what it's doing anyway, so
it really doesn't matter whether ramps stop automatically or not -
there will always be a new event at the end of the ramp anyway.
Consider writing an envelope generator that outputs linear ramp
events. When would you ever have a use for stopping ramping without
an explicit event?
See above - they don't have to.
No, but I see no motivation to force implementational issues upon
plugins to implement a feature that will practically never be of any
use.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
Why do you need to stop ramping? Set the value to 0,
and ramp
for 1 block or 1/2 block or whatever
That only works if you're about to kill the plugin as well.
Otherwise, it will basically ignore that the port was
disconnected, and keep ramping forever. given that we know nothing about the future, I say no.
We've
set a rule that "things happen now and in this block only".
Let's stick to it.
Sounds logical, but one could say that the ramping events break
the rule anyway, since the ramping isn't stopped automatically at
the aim