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

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Feb 2004 02:04:04 -0800

On Mon, Feb 02, 2004 at 07:24:52PM -0800, Chris Grigg wrote:
> Better, but I still don't see a definition of 'timeline controller' 
> in there.  Seems like it needs a different definition for each time 
> type.  I know there are some problems in the following long text, but 
> hope it points in the right direction...?

I like a lot of your prose, but it's more of a book than requirements.  This
should all go into the meat section.  I've attempted to step back and
distill the requirements from this and the existing reqs and merge them into
something usable.

Sorry it's long.  Does this capture the requirements?  All of the
requirements?

Comments on each req follow in [[ double brackets ]].


* GMPI must provide one master clock per graph.  The GMPI master clock must
provide sufficient range to represent several hours of time at a high
sampling rate, and enough resolution to address individual audio samples.
Hosts may build multiple graphs with different master clocks.

  [[ This just needs to establish that we want at least sample accuracy, while
  leaving room for sub-samples if the impl/spec requires it.  We hint that we
  expect 64 bits of resolution. ]]

* GMPI plugins must only be driven by one master clock - they may not span
subgraphs with different master clock rates.

  [[ It seems obvious, but better to state it, I think ]]

* 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" ]]

* GMPI must allow more than one timeline controller in a graph. Hosts may
choose not to allow this.

  [[ Does this need explanation?  A host may allow plugins to be running at
  different tempos. ]]

* GMPI plugins must only be driven by one timeline controller - they may not
have multiple tempos.

  [[ A single plugin can't be driven by two tempos.  Again, obvious ]]

* GMPI plugins must be able to easily sync to their timeline controller.
Plugins must be able to get relative timings (1 beat from now) and absolute
timings (the start of the next beat).

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

* 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? ]]

* 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? ]]

* GMPI plugins must only be driven by one transport controller.

  [[ May be obviated by changes to the previous. ]]

* GMPI must provide a way for plugins to be notified of changes in the
various transport variables, such as playback position and transport state.

  [[ I'm not sure what plugins will DO with this information, but it seems
  like they might do something if they knew about stop/start/pause, shuttle
  speed, playback position, loop points. ]]

* 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? ]]

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

  [[ Language needs work here.  What I mean is that given one unit of time
  info, a plugin should be able to get any other.  It may mean converting
  to/from master time or it may be direct - doesn't really matter here. ]]

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

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