[gmpi] Re: Time Summary (was *Ping*)
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 19 May 2003 22:45:27 +0200
On Monday 19 May 2003 16.12, RonKuper@xxxxxxxxxxxx wrote:
[...]
> If we design GMPI so that all events must be delivered in the same
> payload as the process() call, we lose this important capability.
> Also, we lose the ability for plugins to freely send non-process
> event data to one another.
I think it's very important to make this optional both for plugins and
hosts. Plugins that can't interrupt a process() call anyway shouldn't
have to worry about thread safety issues at all. Hosts that never
send events mid-buffer shouldn't have to deal with any side effects
just because the API supports it.
How about this:
The normal way would be to pass events to process(), and those would
have to be for the current buffer, sorted in timestamp order, etc
etc. The event streams are essentially structured audio rate control
streams working under the same conditions as audio.
Plugins that are implemented in a way that allows them to respond to
events delivered during the process() call, or while waiting for an
asynchronous process() call (VST style) to finish, could implement a
separate, thread safe entry point for event delivery. Events
delivered through this entry point are not hard real time, and not
guaranteed to be in strict sync with audio time as seen by process().
That is, even though events are timpestamped, they may arrive before
the buffer they're meant for, or too late for the intended timestamp
to be respected. Plugins are required to deal with this in a suitable
way.
If we use a XAP-like event model (each plugin has one or more input
event queues, selected by the plugin itself upon connection; events
are written directly to these queues, potentially directly by other
plugins), this could be handled by having secondary event targets
(target queue + addressing cookie) for asynchronous capable inputs,
and a process_events() call. The process_events() call would have to
be thread safe in respect to process(), and would be responsible for
passing the asynchronous events on to whatever is doing the work.
That is, process_events() basically means "Hey, you got some async
events! Deal with them somehow."
Of course, a plugin that has no async inputs, nor a process_events()
call, would have to receive all events the usual way; before (XAP
event model) or through (VST event model) the process() call. Hosts
that never bother doing this stuff just never connect any async
inputs, and never call process_events() of plugins that have it.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
