[gmpi] Re: 3.8. Events Req 25 eventorder

> 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... 

-----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: http://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: http://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: http://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: http://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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: