[gmpi] Re: New Reqs 3.8 - Events
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 16 Dec 2003 17:53:55 -0800
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
anything else. Was this intended? I know we had a long, painful
discussion on all this once but don't remember the resolution. There
was one efficiency issue that musical time events sitting in a queue
that the plug could look ahead into would of course have to wiggle
around in sample-time/abs-time space in the event of tempo changes,
and that that could mean a lot of wasted cycles and maybe reordering
in the event buffer.
Also I might say 'Events are how control CHANGES are represented.'
Or 'control setting actions' or something.
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?
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
Req 25: GMPI must support instantaneous events on all control inputs.
More on this requirement
Agree with Jeff, this is vague. Reword?
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'?
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.
- 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.
-- Chris G.
----------------------------------------------------------------------
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:
