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

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Feb 2004 17:31:47 -0800

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.

They're generally not as cleanly separable as that -- by positing entities like timeline controllers and metronomes etc. in the first place, you're already asserting a lot of "how"s. You draw the lines where you need to.



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

I said sample-based, not sample counter. As I meant it, sub-sample clocks are still sample-based.



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

Fine, but try to concentrate on the expression of the design, not the design itself... you still didn't define 'address.' Since you want to place events on sub-sample boundaries, the requirement form might look like: "GMPI must allow sub-sample accurate event timing."



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

1. The details section is in my mind very much part of the requirements. Section 3 is pretty sketchy on its own.
2. If the group agrees that sample-or sub-sample accurate event timing is a requirement, then it's a requirement. If the group agrees that events should be represented as data structures, then that's a requirement. Once established as requirements (and then they're not implementation spec stuff), and you can build other requirements, like 64-bit time fields, on top of them.



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

A plug could do both of these without needing musical time as one of the event time fields in the event record, so these don't shed much light for the spec-writers who follow. For them, a more illustrative case is: Does a plug-in need to know the musical time of a note event, or is it enough to know the time just as the sample offset into the current timeslice? If not, why?



Without saying anything about fields of structures, or anything
implementation-ish, how do you state that GMPI must have the concept of
'music time' ?

Just stating it isn't enough, you have to characterize it enough to give spec writers a clear picture of what it needs to do, so they can design it to achieve that. So we have to finish detailing what we need 'music time' for, i.e. what GMPI plugs will want to do with it. Do plugs ever use music time to decide how far into the current timeslice to execute the event? Or is music time only context metadata? Or is music time not even delivered with an event, i.e. plugs only get the music time for the start of the timeslice? Also the distinction between score time and conductor time seems to have gone away in the last 24 hours, is that what we want?



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

I think we already fixed this, didn't we? Add a tempo control & resync to a downbeat after a Play/Resume.



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

Definition please.

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.

Keep going... What is its output, i.e. does it generate event pulse streams into the GMPI graph, or is it something plugs & the host query the time from via API? What is its input, i.e. how are tempo and meter changes fed to it at the correct times? Can it be a plug? Can it be external to the GMPI graph? Etc. etc.



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

I think you already withdrew opposition on this, but just in case: Are there any arguments against multiple timeline controllers other than ease vs. complexity?



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

Think in terms other than a plug having a tempo input and this becomes much more attractive. For example, a synth accepting note events from two different mini-sequencers running at different (though perhaps sync'd) rates. The receiving plug doesn't care about tempo at all, just sample-counter-based event times so there's no contention issue.



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

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

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.

OK, that's better, thanks. Though doesn't measuring, or scheduling, anything 1 beat into the future violate the future-blindness rule? Or is output look-ahead actually OK?



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

LOL... OK, then what does 'manage' mean as you imagine it? (It's getting kind of circular in here...)



> Please define relationship between a timeline controller and a
transport controller.

Unclear, based on all sorts of pending issues

Fine, but I'm asking why you proposed them as different things -- there seems to have been an idea there?



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

Since we seem to have a rule that all events scheduled for execution within a given timeslice are committed to just before the host presents the timeslice to the graph... then, yes. (But -so- uninteresting... really, this whole no-lookahead rule is a big drag from a composer's POV.)



I'm looking for input on UTC from the people who think it is
needed :)

Good, me too.


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