So, let's say the plug doesn't want to set up a handler for just-in-time
events. It would inform the host somehow, and the host would then route
these to the normal timestamped queue. All events arriving during the
current timeslice would be timestamped for the start of the next slice, or
as someone else pointed out you could also add the timeslice delta time to
each event.
This seems OK, but another issue is that we already agreed not to have
multiple simultaneous entry from different host threads. A separate entry
point would violate this.
Bill
At 10:59 PM 5/19/03 +0200, you wrote:
On Monday 19 May 2003 21.13, Bill Gardner wrote: > 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.
Well, yes, but there are other ways. My "async alternative inputs" + process_events() (last mail) eliminates the host side queue management, queue thread safety issues and the polling. The host tells the plugin when there are new events, and then the plugin just grabs them and squeezes them in somehow. This way, the implementation is left totally to the plugin, which is the way it has to be for this feature to be of much use.
> 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.
I like the idea of just building it into the normal event delivery mechanism, but I don't like the polling part, or the implementation issues it brings. It would be ok if the host could only add events after the end of the existing queue, but that defeats the purpose of polling for updates. (You may well have events all the way to the end of the current buffer as soon as you enter process(), which would leave no room for new events, except for the last sample in the buffer.) If the host tries to squeeze new events in where they're intended to go, the plugin won't see them without rescanning the queues all over - and then, how would they know which events weren't there the last time...?
//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
---------------------- 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
