[gmpi] Re: New Reqs 3.8 - Events
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 17 Dec 2003 18:59:34 +1300
> 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).
Well..... the host has to maintain the timestamps at 64 bit accuracy, so
you're actually imposing a conversion step on the host (a 64 bit math
subtraction). So I'm not sure there's any overall saving by using 32bit
timestamps. Either the host does it, or the plugin does it (converts
timestamps to block-relative).
Not too worried either way to tell the truth though.
Best Regards,
Jeff
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, December 17, 2003 5:00 PM
Subject: [gmpi] Re: New Reqs 3.8 - Events
> 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
>
>
>
----------------------------------------------------------------------
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:
