[gmpi] Re: Reqs 3.9. Time - opening arguments.1

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 04 Feb 2004 08:03:10 -0500

>* GMPI must include the concept of music time.  Music time is dependant on
>variables such as tempo and meter and is measured in some musically useful
>unit, such as bars, beats, or a sundivision thereof.  Music time is managed
>by a timeline controller.
>  [[ Music time is what I was calling metronome-time.  Even if the track is
>  not playing, music time is running.  Tempo-synced plugins would track this.
>  Introduce "timeline controller" ]]

this is really unclear. music time and transport are totally and
inextricably linked. if the transport is not moving, then
{music,transport} time does not move. the only difference between
them, and its not really a difference, is that conventionally one
would express music time in musically significant units, whereas
transport time could be expressed in other units (e.g. audio frames
from some reference position). but this is a choice that could be made
for either kind of time (since they are the same time, in fact).

they are the same timeline. please dump one of them.

>* GMPI must provide a way for plugins to be notified of changes in the
>various time bases, such as tempo and meter.
>  [[ These are the real meat of the past few reqs - timeline sync. ]]

the other meat here is: Can a plugin notify the host of changes to the

>* GMPI must include the concept of transport time.  Transport time is
>dependant on variables such as playback position and speed.  Transport time
>is managed by a transport controller.
>  [[ Transport time is what I was calling music time before.  Transport time
>  stops when the transport stops.  I'm not sure what plugins would use this,
>  but it seems like we shouldn't leave it out.  I'm not sure the units.  I
>  had figured it would be in the same units as music time (ticks or beats or
>  whatever).  But if we allow multiple timeline controllers (specifically
>  multiple time signatures) in a graph, then the music time is different.
>  Maybe in percentage of track? ]]

transport time and music time should be merged. there is absolutely no
difference between them.

>* GMPI must allow more than one transport controller in a graph. Hosts may
>choose not to allow this.
>  [[ I'm not sure this is really needed.  Can some plugins be stopped while
>  others are playing?  Imagine a DJ rig with two subgraphs - it needs two
>  transport controllers.  Maybe we call that two graphs and say something
>  akin to master clock - only one transport controller per graph? ]]

Only one transport controller per graph. if plugins want their own
"play" or "stop" buttons that are independent of the rest of the
graph, they can have them.

>* GMPI must provide a way for a plugin to act as a timeline controller or
>transport controller for other plugins.  Hosts may choose not to allow this.
>  [[ Any comments needed? ]]

We have not defined what a "timeline controller" actually *is*, in the
sense of what its appointed tasks/capabilities are.

>* GMPI must provide a way for a plugin to accurately convert between time
>formats and a TBD list of other formats (e.g. SMPTE).

SMPTE is a time format too. I would just say:

 * GMPI must provide a way for a plugin to accurately convert between
   any of a TBD list of time formats (likely to include at least
   zero-referenced audio frames, bars|beats|ticks, minutes:seconds, SMPTE)

Q: Do we allow for offsets between the zero reference point of all
formats requiring such a reference? 

>* GMPI must include the concept of universal time.  Universal time is a
>system global clock which can be used for cross-application sync.
>  [[ I'm still not convinced of the utility or reality of this.  I'd like to
>  see some concrete examples of what it does that can't be done reasonably
>  well without it. ]]

Its *absolutely* *critically* vital. Any time you have two streaming
media clocks (e.g. audio hardware interface sample clock and video
display vertical retrace clock), syncing them requires an independent
third party. To not provide the UST for any event makes it impossible
to accurately convert its time of occurence into a format based on the
non-GMPI master clock (e.g. the video retrace clock).


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: