On Wed, Feb 04, 2004 at 01:40:46PM -0800, Chris Grigg wrote: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.
It'[s important to remember that these are requirements and NOT spec. They are deliberately vague. We're supposed to define what it does, not how it does it.
> >* GMPI must provide one master clock per graph.
If you're thinking of a sample-based clock, why not say so?
Because it may be sub-samples. There has been talk of a host-defined sub-sample factor. If the requirements say sample clock, then we don;t leave room for that.
> >and enough resolution to address individual audio samples.
Define 'address'? Isn't 'sample accurate event timing' a clearer requirement statement?
Again, sub samples. The master clock must be able to exactly address samples at the sample rate.
> > [[...We hint that > > we> expect 64 bits of resolution. ]]
Don't let's be coy, say it out loud.
We can suggest it in the details, but we're NOT defining the spec right now.
> What does 'include' really mean? ...
Well, what is the requirement? As I understand it the requirement is simply that plugins be able to sync to the musical timeline, and get information about that timeline.
Without saying anything about fields of structures, or anything implementation-ish, how do you state that GMPI must have the concept of 'music time' ?
> > [[ 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.
The idea originally came from XAP with the intent of making tempo-synced effects simpler. If a delay+feedback is set to repeat every 3 beats, it can figure the # of samples (at the current clock rate and tempo) to delay. But we had some concerns about drift, for which we though periodic resyncronizations would be useful. Maybe not. Storing delays as samples or real time makes for a mess if the tempo or meter change suddenly.
Consider this: a sound with a 3 beat delay. Trigger that sound. 1 beat later you loop back to a part of the track that is in a different tempo and meter. If you have a free-running ticks clock, it is easy. The length of real time that makes up a tick changes, but the number of ticks to delay does not.
> >* GMPI must allow more than one timeline controller...
Defined above - the thing that manages musical time. It can and should be clarified to be the thing that manages msuical time and the variables that affect it, such as tempo and meter.
> > [[ 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.
This combined with the rule that plugins only belong to one musical timeline makes it easy. Your plugin only has one musical timeline controller. By asking for a bit of music time info, you will always know you are asking YOUR music time controller (via the host struct or something).
> >* 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.
This was something we all agreed was acceptable way back. It makes life easier if a plugin is only in one musical timeline. Yes, it limist some bizarre things, but those things come at the cost of COMPLEXITY.
What makes up music time: tempo, meter, ticks_per_beat. If you limit a plugin to having one view of all these things, then life is easier.
> >* GMPI plugins must be able to easily sync....
Define 'sync', please.
Really? I thought I covered that below...
>..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).
If you read the WHOLE requirement, is it not clear? Plugins must be able to figure out when the time is exactly 1 beat from any other time, but they must also be able to detect musical-time milestones, such as the start of a new bar.
> >* 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.
Please define 'transport controller'.
The thing that manages transport time. That's the only definition we CAN give at this point. Whatever is defined to be part of transport time by the spec/implementation is m,anaged by a transport controller.
> Please define relationship between a timeline controller and atransport controller.
Unclear, based on all sorts of pending issues
> > [[ 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.
Fair enough - within a timeslice, you should be able to convert to/from any format?
I'm looking for input on UTC from the people who think it is needed :)
---------------------------------------------------------------------- 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