Subject: Re: [linux-audio-dev] XAP: Control events
From: David Olofson (david_AT_olofson.net)
Date: Fri Dec 20 2002 - 00:01:53 EET
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 ---
This archive was generated by hypermail 2b28 : Fri Dec 20 2002 - 00:10:23 EET