On Mon, Jan 20, 2003 at 06:08:48 +0100, David Olofson wrote:
> > 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.
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.
> 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
