[gmpi] Re: 3.8. Events Req 25 eventorder
- From: "Ron Kuper" <RonKuper@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sun, 16 Jan 2005 19:17:59 -0500
I think the req. should state, "The GMPI 1.0 SDK must provide an
implemention of an event queue that ensures events can be delivered in
temporal order."
I would personally want the queue to proved sorted and unsorted
insertion methods, so plugins that are going to insert masses of events
can sort them at the end.
-----Original Message-----
From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On
Behalf Of Tim Hockin
Sent: Sunday, January 16, 2005 7:00 PM
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: 3.8. Events Req 25 eventorder
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
----------------------------------------------------------------------
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
Other related posts:
