[gmpi] Re: New Reqs 3.8 - Events
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Thu, 18 Dec 2003 17:18:38 +1300
Hi Chris,
> One possible compromise would be to allow any plug that wants it to
> request a second event queue... and have
> lookahead well beyond the current process() frame.
"Non-causal systems exist in theory, but they cannot exist in the real
world". - Digital Filter Designer's Handbook.
The only way a real-time plugin can look into the future is via
host-provided 'delay compensation'. The plugin requests a certain latency,
the host provides events in advance, and delays all other plugins to
compensate. ( VST does this ).
The disadvantage is that delay-compensation increases the overall system
latency, so playing soft-synths in real-time becomes sluggish.
Any less rigid system falls apart as soon as you chain two or more
plugins (where each wants to peek into the previous event queue). Like the
plot of "TimeCop", the more you think about it, the more impossible it
seems.
My guess is that host-provided-delay-compensation is most suitable for
short-term lookahead ( typically less than 1 second ).
For longer lookahead, the best solution is a pure offline plugin, where
the plugin has access to the song's entire timeline, and can even perform
multiple passes over the musical and audio data.
Best Regards,
Jeff
----- Original Message -----
From: "Chris Grigg" <gmpi-public@xxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Thursday, December 18, 2003 10:44 AM
Subject: [gmpi] Re: New Reqs 3.8 - Events
> 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
>
>
>
----------------------------------------------------------------------
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:
