[gmpi] Re: Reqs 3.8 Events - ramped events
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 7 Jan 2004 14:47:46 +0100
On Wednesday 07 January 2004 12.54, Steve Harris wrote:
> On Wed, Jan 07, 2004 at 12:23:09 +0100, David Olofson wrote:
> > BTW, some advantages with <target, duration> events:
> >
> > * If a host wants to implement click-free
> > disconnection of control inputs, it can just
> > send <default_value, declick_ramp_time>,
> > eventually followed by <default_value, 0>.
> > This will ramp from the current value to
> > the default value. The host does not have
> > to know the value at the time of
> > disconnection to do this.
>
> 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.
> > * Quick'n'dirty merging of two event streams
> > generates a (sort of) sensible signal, since
> > ramps are always from the current value.
> > That is, no sawtooth curves, overshooting
> > or other nasty stuff.
>
> I dont see how that will work. Folling evnets will just clobber the
> proceedings ones causing random wanderings in the value.
Yes, that's what you get if you mix event streams like that. I'm just
saying that with <start, delta> or <delta> events, you'll get even
nastier results. Not much of an argument, though.
> In reality
> the host will still have to handle (or prevent) merges.
Yeah, that's the only seriously useful way of doing it.
In conjunction with the gesture requirements, it was suggested that it
be somewhat acceptable to just send the events to the plugin, but it
makes less sense the more I think about it. In fact, depending on the
ramp event implementation, it may not even be possible to do without
the risk of crasching some plugins. (Div by zero due to controls
going out of range, if nothing else...)
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.
> > * 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.)
Multiplying is usually a bit faster than dividing BTW, but someone,
somewhere will have to make that dreaded division anyway. :-)
> 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.
> * 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.
> * 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.
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.
<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.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
