20 Jan
2003
20 Jan
'03
2:06 p.m.
On Mon, Jan 20, 2003 at 06:08:48 +0100, David Olofson wrote:
Well, youd have to extrapolate the ramp to the pint where the next notch
is reached and reshedule a 0 duration event for there if the timing was
critical.
but the cases
I can think of it wont hurt:
notched switches: will always jump to the target value anyway, so
wont have to do any interpolation.
RAMP is always interpreted as SET? Not the best way to fake ramping,
but then, if you say you do not ramp, you shouldn't be expected to
even fake it. Makes sense. So, alternative 1; RAMP events only:
case XAP_A_RAMP:
if(ev->duration)
dvalue = (ev->value - value) / ev->duration;
I think you'll find that that should be
dvalue = (ev->value - value) / (ev->duration + 1.0f);
Otherwise you end up with unwanted shelves or delays in the ramp shape.
No branch is needed, cos the next delta of the control value will set it to
the correct value, but it may well just be easier to set it and not have
to cancel the delta next sample.
Using only RAMP events definitely looks like a great
idea to me. I'm
going to try it in Audiality right away! :-)
Yup, I like it too.
BTW, using INFINITY for duration (MAXINT for fixed
point, provided
MAXINT is not a valid control value) has the same effect as a STOP
event... Should this be allowed? We've already concluded that the
No, getting Infs into float code can cause problems down the line.
And yes, duration would be of the same type as the
control value, I
think. There's no point in making it an integer for float controls,
since plugins will only use it for a aim point -> dv transformation
anyway.
Yes, though there is the problem of what happens when the host specifies a
non integer duration, events cant arrive at non integer timestamps, so you
will end up with overshoot or undershoot. It may be safer to make them
ints. int -> float cast is not expensive.
- Steve