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

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Feb 2004 13:40:46 -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

Well, my draft was long for a reason. Actually I think that in trying to simplify a lot of important details & assumptions in the underlying concepts have been glossed over, especially through the use of undefined terms. So the text looks better when you simplify, but a lot of problems can get obscured that way. Details inserted below.

* GMPI must provide one master clock per graph.

If you're thinking of a sample-based clock, why not say so?

The GMPI master clock...

Actually you mean the graph master clock.

provide sufficient range to represent several hours of time at a high
sampling rate

Good addition

and enough resolution to address individual audio samples.

Define 'address'? Isn't 'sample accurate event timing' a clearer requirement statement?

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

Don't let's be coy, say it out loud.

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

What does 'include' really mean? I'm not trying to be a jerk here, this really should be specific. Do you mean in the event record, or if not that, then what? E.g., are event times specified in music time, or is it just kind of advisory metadata?

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

I agree with Paul that this is too fuzzy, and agree in not seeing how this kind of time can correctly continue after the user presses Stop. But i might well be nice to know where you are relative from the start of playback in musical terms (bars beats etc.), so there I don't agree with Paul that this is redundant and can be ditched.

* GMPI must allow more than one timeline controller...

Definition please.

Also the name is not good. Sample time, SMPTE time, etc. are all timelines too, so your name should distinguish itself from these others, that's why I used 'Music 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. ]]

What is the relationship between a timeline controller and a given event? If all you have in the event structure is a music time but no timeline controller ID, multiple timeline controllers will just confuse you because you don't know which musical context the event belongs to.

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

?? - There's more to a timeline than tempo. Might need to re-think this whole area.

* GMPI plugins must be able to easily sync....

Define 'sync', please.

..to their timeline controller.
Plugins must be able to get relative....


Also please define: 'relative' to what? The event time? Start of the current timeslice?

..timings (1 beat from now) and absolute
timings (the start of the next beat).

* GMPI must provide a....

...single blessed/standard...

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

See supra, what does 'include' mean really?

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

Please define 'transport controller'.

Please define relationship between a timeline controller and 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.

Depends on the definition of transport controller, doesn't it? 8-)

Can some plugins be stopped while
  others are playing?  Imagine a DJ rig with two subgraphs - it needs two
  transport controllers.

Or maybe multiple transport controllers -and- multiple timeline controllers... depending on the definitions. 8-)

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

Not so sure.

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

This is so close to "GMPI must provide a way for plugins to be notified of changes in the
various time bases, such as tempo and meter" that the ideas should probably be merged in some way.

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

Again, depends on definitions.

* GMPI must provide a way for a plugin to accurately convert between...


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

This is not always possible, e.g. arbitrary musical position to sample clock depends on tempo & meter change history.

* GMPI must include the concept of universal time.  Universal time is a
system global....

Define scope of 'system global', please.

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


-- Chris G.

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: