I fear this will open another big can of worms, but here goes anyway.
If the plug requested that the host deliver events up to some stop time,
then situation C wouldn't need special handling. Plugs that grab all events
for the current timeslice will continue to get timeslice quantized
resolution. Plugs that poll a bunch of times during the timeslice can get
finer resolution for just-in-time events. I'm thinking of an architecture
where the host maintains a time sorted queue of waiting events for each
client plug, and just in time events are inserted in sorted order into the
queue. One problem with this direction in thinking is that it takes us back
to the ideas of generating "future" time stamped events that are destined
to sit in a host queue, and from this follows the idea of stamping events
with MUSTIME rather than ABSTIME to facilitate sorting of tempo dependent
events. A can of worms indeed.
But, I don't like the idea of separate delivery mechanisms for just-in-time
events. I wouldn't mind having to ask the host for all the events for a
timeslice. It would be easy to ask again during the timeslice to get just
in time events. Just an idea.
Bill
At 10:12 AM 5/19/03 -0400, you wrote:
Before I throw sand into the vaseline, I'm noticing this thread is going way off-topic. The ideas are too good to shut it off at this instant, but at some point soon I hope we can wrap up the "time representation" question.
>>> A) The host gathers all real-world realtime events occurring during timeslice T and delivers them to the plugs for execution at the very start of timeslice T+1. ... B) Same as A), except that you preserve the time-offset-from-start-of-timeslice-T as a timestamp for each event, and the plugs observe the timestamps when processing the events during timeslice T+1. <<<
I opt for (C) Realtime events are delivered to the plugin just-in-time, as they occur, via a separate entry point into the plugin.
I believe there are actually situations where a plugin could render realtime changes just in time, even if the change arrived in the middle of processing an audio buffer. (Of course we need thread safety between the entry point that gets realtime events, and the process routine.)
Here's a concrete example of how this might work. A user is running DSP accelerated plugins. The DSP can natively chug away on audio using really small buffers (16 or 32 samples, say), but the proxy to the DSP needs larger buffers. Maybe the user wanted larger buffers for more stable streaming, or maybe there are some limitations to the host/DSP interface that require this. Heck, maybe it's USB.
In this scenario, a realtime volume change *could* change the volume in the middle of an audio "buffer", the reason being that a buffer from the host perspective isn't really the true buffer size. If GMPI is going to serve as a possible proxy for DSP, this can definitely happen.
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.
---------------------------------------------------------------------- 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
---------------------- Bill Gardner Wave Arts, Inc. 99 Mass. Ave., Arlington, MA 02474 Tel: 781-646-3794 Fax: 781-646-7190 billg@xxxxxxxxxxxx
---------------------------------------------------------------------- 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
