[gmpi] Re: Reqs 3.8 Events - ramped events
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 24 Dec 2003 21:28:53 +0100
On Wednesday 24 December 2003 19.01, Tim Hockin wrote:
> On Wed, Dec 24, 2003 at 04:16:07PM +0000, Steve Harris wrote:
> > On Tue, Dec 23, 2003 at 03:28:41 -0800, Tim Hockin wrote:
> > > * If and only if the plugin indicates that a particular control
> > > can be ramped, the host can send ramp events. Ramp events are
> > > linear ramps, for now, with the possibility of adding different
> > > ramp types later.
> >
> > I'd like to not rule out modular synth style plugins, where the
> > plugin is generating control events. The plugin will gen
> > generating output events, but would have to know if the receiver
> > could handle ramps or not.
> >
> > Might it not be better to have a system like XAP where "ramps"
> > and "sets" had a unified representation (IIRC). That way we dont
> > have to worry about some ports not accepting/wanting ramp data as
> > they can just ignore the slope.
>
> Hrrm, good point. Well, a point-value event is really just a ramp
> event with 0 duration, right?
Yeah, and it also eliminates a sender side check to avoid div-by-zero
exceptions in receivers. There has to be a zero test somewhere
(sender, host inserted "event cleaner" or receiver), so we might as
well put it in the receiving end and have the SET feature for free,
along with transparent ramp duration handling all the way down to 0.
BTW, using the <target, duration> "aim point" format, all you have to
do to ignore ramping is to ignore the ramp duration field and just
grab the target value.
As to the "aim point" definition; it looks a lot like events talking
about the future, but it's not. An "aim point" is an exact way of
describing a slope, and it gives a hint about the time frame.
(Internal ramp approximations should remain sufficiently accurate
within this time frame.)
For XAP, we decided that what happens after the duration of a ramp is
not defined by the ramp event. It is the senders' responsibility to
deliver a new event before the aim point is passed. (Connection
logic; if you're driving a control input, you're responsible for
feeding it with valid data - just as you're responsible for filling
in the audio buffers if you're driving an audio output.) The main
advantage is that it eliminates the logic needed to stop ramping some
time in the future, after receiving a ramp event.
> It seems weird that you might send a
> ramp and have the value jump immediately, though.
Why? If you say "duration = 0", that means the operation is supposed
to be infinitely fast, right?
> And jump when?
> at the start of the ramp? End? Middle?
The "fancy" version includes delaying the jump by half the duration,
but most of the time, that probably just adds to the inherent delay
of the internal filtering. Unless it's allowed to ramp over multiple
buffers with a single ramp event (which is probably a bad idea, for
many reasons), this shouldn't matter much.
Anyway, cheating with the ramping on some controls is an
approximation, and it's really only the plugin author who can decide
how accurate it needs to be.
//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:
