19 Dec
2002
19 Dec
'02
6:07 p.m.
On Thursday 19 December 2002 22.51, Tim Hockin wrote:
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 ---
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.