21 Jan
2003
21 Jan
'03
12:27 p.m.
On Tuesday 21 January 2003 10.19, Steve Harris wrote:
[...]
Well, yeah. Back at square 1! :-)
Though, the 0 test is still really a fix for a logical glitch that
appears in the borderland between continous and sampled time.
So, if the test is needed anyway, is it all that bad to "abuse" it a
little, to make it usable as a SET event as well? I don't really like
it, but I don't like a special SET event any more...
Then again:
case RAMP:
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;
break;
}
case SET:
v->ic[ev->index].v = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv = 0;
break;
Note that while this fixes the broken 0 duration case, it also has
the side effect that RAMP(value, 0) becomes equivalent to SET(value).
So, you don't really need to use the SET event explicitly at all.
//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 ---
Another idea:
Since we need that (duration == 0) test anyway, why not have it
explicitly stop ramping as well, so we can connect non-ramped
outputs to ramped inputs and vice versa?
I'd say that has different semantics, and so should be a seperate
event. Say... SET ;)