[gmpi] Re: New Reqs 3.8 - Events
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 23 Dec 2003 14:59:20 +1300
Just an observation:
This description of tempo as a continuous quantity... sounds a lot like a
continuous controller. Is tempo really just another continuous controller?.
Can we use the same mechanism?
We were talking about continuous controllers needing to be ramps anyhow(or
splines), kind of applies equally to tempo.
I'm a bit daunted by the idea of interpreting controllers as splines, but I
guess the code only needs writting once, then we can all share it.
just thinking out loud...
Jeff
----- Original Message -----
From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, December 23, 2003 2:38 PM
Subject: [gmpi] Re: New Reqs 3.8 - Events
> >If the plugin only knows music time at the beginning of the sample
buffer,
> >or with every received event, that's not precise enough. In order to
> >represent music time at any large multiple of the sample frame rate, the
> >host must send to the plugin not only the instantaneous music time and
> >tempo, but also the derivative of the tempo or, if the accelerando or
> >ritardando is not perfectly linear, a spline function and its terms so
that
> >the plugin can interpolate the correct music time. Otherwise, sample
frame
> >synchronization of music time is not possible.
> >
> >I would like to have both of these facilities - polling and polynomial
tempo
> >maps - since each is useful for different purposes, but if I had to
choose
> >one, I would take the ability to poll for the exact music time on each
> >sample frame.
>
> i don't think that anyone here has ever proposed limiting the
> conversion in either of the ways you are proposing.
>
> i think its clear that musical time cannot be assumed to be either
> constant or linear over the duration of a buffer.
>
> i think its also true that a GMPI graph might contain more than one
> tempo map. so i would hope that rather than attempt to provide plugins
> with musical time per se, the GMPI SDK would instead provide a way to
> convert between sample times and musical times given a tempo map.
>
> this does imply a new area for the reqs document that we have not yet
> covered: what does a tempo map look like?
>
> but i don't think that GMPI should contain any concept like "what is
> the musical time now" without reference to a particular tempo
> map. given the map, everything else can be computed (albeit at some
> considerable computational cost).
>
> --p
>
> ----------------------------------------------------------------------
> 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:
