[linux-audio-dev] XAP: Control events

[David Olofson]

On Thursday 19 December 2002 22.51, Tim Hockin wrote:
> > 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.
>
> OK, I'll buy that.  Send a SET event to stop a ramp.  It just means
> that a ramp is (almost always) two events.  Not too big a problem,
> I think.

No, no major bandwidth abuse or anything. And in fact, it's not even 
as bad as two events per ramp. You don't have to send any SET 
"stoppers" if you chain ramps - which is what you'll be doing most of 
the time anyway. Especially if you stick strictly to the rule of not 
letting ramps run across block boundaries. I don't in Audiality, but 
it doesn't really make any difference there: I *know* that the send 
level ramping is truly linear. ;-)

That's an example of the "aim ahead and change your ming" approach, 
BTW. The EG runs each stage of the envelope as a single linear ramp, 
but may still switch to the release stage at any point.


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