[gmpi] Re: New Reqs 3.8 - Events
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 17 Dec 2003 13:44:44 -0800
Sorry to do this, but can I revisit an earlier decision?
I said:
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?
Tim said:
That's right - that's what was decided the first go-round with these.
I said:
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.
I'm concerned that having no possibility for look-ahead is going to
limit GMPI, and my intuition (sorry, that's the best I can offer) is
that this will be more of an issue for musical performance events
streams than it will be for mix automation style events. Maybe I'm
just wrong about this, but I would like to hear what some of the
experimental music advocates have to say about the matter.
One possible compromise would be to allow any plug that wants it to
request a second event queue, which would be different from the main
event queue, in that it would use musical timestamps and have
lookahead well beyond the current process() frame. The host would
add future note (and other performance controller) events to this
second queue as soon as they became known. Once added to the queue
the events would not change (because their musical times do not
change with tempo changes as happens with sample timestamps) so queue
maintenance work would be minimal (and only for plugs that request
it). With this kind of queue, the plug is free to look as far ahead
as it cares to, but the host and system burden is kept small. In
fact, the musical queue could be just an index of { musTimestamp,
eventID } pairs, i.e. references to event message records stored
elsewhere, including in the main event queue.
Now, i's quite possible that the use cases for musical look-ahead
aren't strong enough to justify this kind of thing, but I felt the
idea should be at least mentioned during this pass.
-- 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:
