On Tuesday 21 January 2003 00.41, David Olofson wrote:
[...]
> > > So, alternative 1; RAMP events only:
[...]
> > No branch is needed,
>
> Excellent! :-)
I just realized something that might be worth pointing out.
If you send multiple RAMP events for the same control at the same
timestamp, only the last one will have any effect. This is because
RAMP events change only the delta, and it takes sample frame loops to
actually change the value.
The problem is that if you send multiple RAMP events that are so
close together they end up getting the same timestamp, results won't
be what you want.
For example, setting the initial level of an envelope and then
setting up the delay or attack phase won't work, unless you wait for
one frame before sending the RAMP event for the delay or attack
phase. Similarly, an attack duration of 0 would result in the decay
starting at the current value, instead of the attack peak level.
Note that waiting for one frame after saying "ramp to y over 0
frames" is actually illegal by the definition! You're one frame past
the aim point when the next event arrives, so results are undefined.
So, it seems like we'll need that 0 test anyway. It should obviously
apply the target value instantly, so that later events will work even
if they land at the same timestamp. It doesn't have to set the delta
at all, as sending a 0 duration means you *have* to send another
event with the same timestamp anyway.
Resulting Audiality code (how unusual! ;-):
if(ev->arg2)
{
v->ic[ev->index].dv = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv -= v->ic[ev->index].v;
v->ic[ev->index].dv /= ev->arg2 + 1;
}
else
v->ic[ev->index].v = ev->arg1 << RAMP_BITS;
//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 ---
