On Sun, Jan 16, 2005 at 06:48:57PM -0500, Ron Kuper wrote: > > I wouldn't want to see GMPI plugin coders sorting events "just in > case". > > What's cheaper, maintaining a sorted queue or inserting events unsorted, > and sorting after? > > I think the GMPI SDK needs to provide an event queue class to handle the > details... Sure. Should the "events must be delivered in order" be a new Req? Or just a note in the extras? > -----Original Message----- > From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On > Behalf Of Jeff McClintock > Sent: Sunday, January 16, 2005 2:21 PM > To: gmpi@xxxxxxxxxxxxx > Subject: [gmpi] Re: 3.8. Events Req 25 eventorder > > > good but can we also assume that a Vst - Gmpi Wrapper will repair the > > event order. > > there are hosts out there which don't serve events in the correct > order! > > If we agree they should be in order ( I certainly do ), and the spec > says so. Then a wrapper must repair the event order (else it's the > wrapper at fault). > > I wouldn't want to see GMPI plugin coders sorting events "just in case". > > It's a waste of your time, a waste of CPU, and one more place for a > bug to creep in. > In fact, in general, if we write the spec clearly, we shouldn't have to > write "workaround" code. "workarrounds" indicates a poorly defined API. > > Best Regards, > Jeff > > Robert Fehse wrote: > > Hi > > > > > > > >>i would like to see a reqiurement for the host to serve the events in > >>the > >>correct order of time. > >><<< > >> > >>Remember that plugins can serve events to other plugins. So this > >>requirement is really about a mandate on whatever scheme we used for > >>event communication. > > > > > > good but can we also assume that a Vst - Gmpi Wrapper will repair the > event > > order. > > there are hosts out there which don't serve events in the correct > order! > > > > > > > >>it should be defined how to handle events outside a loop (note off's > >>after > >>loopend, note on's before ,...) > >><<< > >> > >>Hopefully GMPI won't need looping as an explicit construction. A host > >>can "unroll" loops on a strictly increasing timeline, so that plugins > >>always see time rolling forward. > > > > > > ok > > > > > > > >>for example allowing no or only 1 tempochange per process cycle. > >><<< > >> > >>Multiple tempos within one audio frame are a fact of life, we should > not > >>built mechanisms to hide that from plugins. If a plugin wants to be > >>lazy it can always interpret the first tempo change that it sees as > the > >>one that is in effect for the entire frame. > > > > > > sounds logic. > > > > thanks > > > > Robert > > > > > >>-----Original Message----- > >>From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On > >>Behalf Of Robert Fehse > >>Sent: Saturday, January 15, 2005 8:23 PM > >>To: gmpi@xxxxxxxxxxxxx > >>Subject: [gmpi] 3.8. Events Req 25 eventorder > >> > >>Hi. > >> > >>i would like to see a reqiurement for the host to serve the events in > >>the > >>correct order of time. > >>and that there are rules to handle the order of events with the same > >>timestamp. > >>for example it should be a reqiurement that note off events are sent > >>before > >>note on events if they have the same timestamp. > >>it should be defined how to handle events outside a loop (note off's > >>after > >>loopend, note on's before ,...) > >> > >>perhaps there should be the possibility to restrict certain eventtypes > >>(eventfilter). > >>for example allowing no or only 1 tempochange per process cycle. > >>perhaps such 'semi-static maps' metnioned in 3.9 Req 32 are a better > >>solution. > >> > >> > >>Robert > >> > >> > >> > >>---------------------------------------------------------------------- > >>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 > >> > >> > >>---------------------------------------------------------------------- > >>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 > >> > > > > > > > > ---------------------------------------------------------------------- > > 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 > > > > > > > ---------------------------------------------------------------------- > 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 > > > ---------------------------------------------------------------------- > 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 -- Tim Hockin thockin@xxxxxxxxxx Soon anyone who's not on the World Wide Web will qualify for a government subsidy for the home-pageless. ---------------------------------------------------------------------- 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