[gmpi] Re: New Reqs 3.8 - Events
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 16 Dec 2003 20:00:37 -0800
On Tue, Dec 16, 2003 at 05:53:55PM -0800, Chris Grigg wrote:
> >Req 22: GMPI must implement a time-stamped, sample-accurate event
> >system. Events are how control >data is represented.
>
> This seems to imply that when the plug receives events, all event
> times are expressed in sample numbers, as opposed to musical time or
That's right - that's what was decided the first go-round with these.
> Also I might say 'Events are how control CHANGES are represented.'
Done.
> >Req 23: Events are delivered to a plugin immediately prior to the
> >processing block in which they are to be >realized.
>
> Obviously this conclusion is in conflict with the event buffering
> model question in the FIX ME after Req 24. Still, 'immediately
> before' seems vague. Reword?
How about something like "All events bound for a plugin during a timeslice
are delivered before that plugin is run. Events are never delivered while a
plugin is processing." ??
The main point is to be clear that plugins DO NOT handle asynchronous event
delivery during processing.
> >Req 24: Event timestamps are absolute timestamps, not
> >block-relative offsets.
> >
> >FIXME: If events are timestamped with absolute times, rather than relative
> >times, it is possible to deliver events FAR in advance, and just have
> >them sit on the event queue. Is this desirable? If not, do events
> >REALLY need 64 bit timestamps? 32 bit offsets is probably faster.
> >Or is it not endorsed, but not worth fighting against?
>
> See above comments on relationship to Reqs. 22 & 23
These aren't in conflict. The issue is whether the timestamp value in an
event is an absolute or relative timestamp. It was demostrated a while back
that 64 bit timestamps+associated math cost as much as 2.5x the performance
of 32 bit math. The real question whether that matters.
Keeping timestamps absolute is nice because you have one consistent
numerical stream.
Making timestamps relative to block-start may be easier for plugins to
handle, emphasizes the "there is no future" model, and saves 4 bytes per
event (as well as saving 64 bit math).
Absolute timestamps also have this ugly hole whereby you can stick an event
for the future onto a sorted event queue. I call it ugly because it breaks
the "there is no future" model. That's what the fixme is partially about.
Do we put effort into preventing this?
As for myself, I don't see any reason to use absolute timestamps, but the
reasons to use relative timestamps are pretty weak. If someone has a good
reason to go for absolute timestamps, I'd love to hear it.
This is a pretty minor point, but it will impact discussions and probably
designs.
> >Req 26: GMPI must support ramped events.
> >Ramped events do not make sense for
> >all control inputs, so control inputs must identify whether they
> >support ramped events or not.
> >More on this requirement
> >
> >FIXME: do we need ramped events?
>
> This could use a definition for 'ramped events.' Also is the idea
> really supposed to be ramped events? Or is it more like
> 'slew-rate-limited controls'?
Read the 'More on this requirement' link. I've reworded it a bit, now so it
reads:
For some control signals instantaneous changes are sufficient - change
the value exactly when the timestamp indicates. However,_ instantaneous
changes can produce unwanted artifacts. Plugins may have to specially
handle instantaneous events, such as using a fast linear interpolation
to avoid clicking.
Sometimes, it may be possible to provide the plugin with some clues
about event trends. For example, the host may know that the user has
requested a linear transition of a parameter over period of time.
Rather than sending the plugin a series of discrete events (between
which the value is steppy), the host can send a single or small set of
ramped events. Ramped events consist of a target value and a duration.
The plugin should interpolate linearly between the current value and the
new value over the duration.
Does that explain ramped controls? Do we want to support them?
> Further questions:
>
> - Imagine a single control with two event sources driving it, and
> fighting with each other. Is there any need for a way to selectively
> enable/disable event sources on a per-control basis? (One variation
> would be selecting one source per control, but that's not the only
> possibility.) I ask because this would seem to require encoding the
> source of each event in the event message. Might be a good thing,
> and help with event routing.
A good point. Maybe it is the host's job to resolve that? UI > MIDI >
automation ? or something. How else could it be done... hrrm, thinking..
> - Event routing. Do we want to require that the event mechanisms
> need to be transport-agnostic? I.e. a message format that can pass
> over wires & radio waves etc., not just a function call.
Not sure what you mean by that. Go a bit deeper?
Another open issue is 'control gesture'. I think it was Vincent who wanted
this. He wanted the idea of providing a way to say "all these events are
one gesture". I think it is mostly useful for things like 'Undo' features.
Obviously MIDI doesn't have any such concept, and automation doesn't need
it. MouseDown / MouseUp map nicely to it, for GUI stuff.
Anyone recall what this was about? I'll troll the archives a bit.
----------------------------------------------------------------------
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:
