On Tuesday 20 May 2003 00.04, Bill Gardner wrote: > 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, A NULL for that callback is pretty simple... :-) > 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. Yes. > 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. Well, yes - but that's the whole point with this interface. If we're really talking about interrupting while process() is working (which BTW, is a *very* short time window for a "normal" plugin running on a fast CPU), this is the only way. The only case where we could avoid this would be the VST style "process() returns early; host polls to see if the output data is ready". Then we have process(), process(_async)_events() and process_done() and no need for reentrant calls - so we're not violating the rule. And, I think this is about the only case where async events really make sense, if they ever do. Allowing hosts to preempt process() with another plugin call seems utterly pointless when I think of 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