[gmpi] Re: Reqs 3.8 Events - ramped events
- From: Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 7 Jan 2004 14:25:33 +0000
On Wed, Jan 07, 2004 at 02:47:46PM +0100, David Olofson wrote:
> > That assumes that the default values cause no click on
> > disconnection - I dont think thats likly to be true, it would be
> > easier/better to just xfade to passthrough with latency correction.
>
> Well, passthrough would probably be the default value for most
> controls - and what I'm describing *is* a fade from the current value
> to the default value, expressed as <target, duration> ramp events.
I dont think you can assume that passthrough is the default. I wasnt
talking about xfading the parameters, I was talking about xfading the
audio.
> You either merge event streams properly, or you never connect multiple
> outputs to one input. Anything else is to be considered a special
> effect, or something.
Agreed.
> > > * The duration parameter gives the control
> > > input a hint about the duration of the ramp,
> > > so it can hit the target value even if the
> > > internal ramping isn't perfectly linear.
> > > Useful when control->coefficient transforms
> > > are expensive and ramping is done on the
> > > coefficient level.
> >
> > True. Though this can be done equally well by multiplying delta by
> > the krate.
>
> Yeah. (Unless we use <delta> events, but that seems like a really bad
> idea. Rounding errors build up over time, whereas <target, duration>
> events eliminate it by always aiming at the target value.)
I dont think thats a valid argument, the vast majority of plugins will
calcuate a delta anyway.
> Multiplying is usually a bit faster than dividing BTW, but someone,
> somewhere will have to make that dreaded division anyway. :-)
Yes, but in the case where your given target and duration you have no
choice but to divide.
> > Some disadvantages:
> >
> > * Plugin will just do delta = target/duration 99% of the time
> > anyway.
>
> Probably - but if they don't, whoever generates the events will have
> to do it instead. Sequencers might get away without doing it in real
> time, but only if there are no non-destructive transformation
> features.
Thats assuming that the sequencer thinks in terms of targets and
durations, they may not, and there in a better place to optimise it, eg.
calualating the reciprocal of the duration if they're going to do a
hundred at once (fairly likely).
> > * Special case handling for duration = 0 (branch).
>
> That, or you have to check for zero duration when generating the
> events. duration == 0 is a special case that needs to be handled
> somewhere no matter what.
Not if you pass deltas, then its not a special case.
> > * Plugin has to store what the next value will be (and at what
> > time) if it wants to ignore ramps, or we need two seperate
> > representations.
>
> That's just a matter of how "well" ramps are to be faked when ramping
> is not supported. You can set the target value right away (which is
> the default behavior with <target, duration> events), at the end of
> the ramp, or in the middle of it. The last one is probably the best
> option of those, but the real solution is to support ramping, or at
> least approximate it properly.
But all of those are more work to handle that just taking the value from a
(value, delta) representation.
> Anyway, here's a disadvantage with <start, delta> ramps:
>
> * Senders and receivers of ramp events must be
> implemented with sufficient accuracy, or they
> may disagree about the current state when ramp
> events are delivered. Whan that happens, there
> will be a jump from the current value to the
> start value of the event.
Theres no way the error is going to be significant over a reasonable ramp
range. I just wrote some test code: http://plugin.org.uk/~swh/ramp.c
for a ramp of 100,000 samples, with krate=arate the error is 0.06%. That
wont be audible.
> <target, duration> ramps don't have this issue. You don't need to have
> a clue about the current value to generate a proper, click free ramp,
> so it works reliably even if the control input has an extremely
> inaccurate ramping implementation.
A lot of the time the plugin will be applying its own smoothing to the
result of the linear ramp, and I dont see this as an issue anyway. Why
would it be that innacurate?
- Steve
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
