On Fri, 16 May 2003, B.J. Buchalter wrote: > Thus the desire to have a plug-in specify an event transport latency, to > remove this problem. If the event takes time to process, why not define the start of the event as the start of the process? I don't see how a device can respond to an event before the event has happened. Now, there may be certain types of devices and certain types of event (albeit a minority of cases) where it's useful to know how long the event is going to take; it may be that we will also want meta-events to prepare devices for those events (in other words, "watch out, I'm probably going to send you a Program Change in a couple of blocks' time"). > Can we get a broader consensus one way or the other that this is either > something that is not worth talking about because it is beyond the scope of > the project, or that in fact it is worth the time because we need this or > something like it to deal with a real situation that is likely to become > more important as time goes on? Can you give us some examples as to what it would be used for? > What if a new event arrives that needs to be delivered during the current > timeslice? It is the same thing. How can that happen..? A timeslice is defined (i think) as having a set of buffers and events that arrive at the beginning of said timeslice. I don't see how a new event can arrive during the timeslice. That implies that the plug-in's timeslice was inadequately prepared or not yet ready for processing, or the system is not computing the latency properly. It can't just suddenly decide midway through processing a timeslice, "hey, I gotta do something else in response to this event". I think we're agreed that GMPI hosts are granular in response at the timeslice - any incoming events must be queued up for dealing with in the -next- timeslice at the earliest.. right? Hence a GMPI system always has some defined latency (one timeslice) in responding to events. Regards, Angus. ---------------------------------------------------------------------- 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