[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
requirements?
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.
...must
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...
...sample...
...clock - they may not span
subgraphs with different master ...
...sample...
...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....
...musical...
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...
...(which?)...
...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. ]]
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. ]]
Ron?
-- 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:
