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