[linux-audio-dev] XAP: Control events

David Olofson david at olofson.net
Thu Dec 19 08:39:01 UTC 2002


On Thursday 19 December 2002 04.23, Tim Hockin wrote:
> > > 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.
>
> 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?


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



More information about the Linux-audio-dev mailing list