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

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Feb 2004 14:46:07 -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.

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

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

We can suggest it in the details, but we're NOT defining the spec right now.

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

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.  That pre-supposes that GMPI defines some notion of
musical 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...
> 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.

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


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

> >* GMPI must include...
> See supra, what does 'include' mean really?

ditto - find me a better word? :)

> >...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 a 
> transport controller.

Unclear, based on all sorts of pending issues

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

We've already agreed that multiple timeline controllers - music-time
controllers - are allowed.  But can different plugins in the graph be in
different playback states?

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

I seperated them explicitly to elicit discussion of timeline vs transport.

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

> >* GMPI must include the concept of universal time.  Universal time is a
> >system global....
> Define scope of 'system global', please.

global to the OS instance on the computer on which the host is running?  I
don't know.  I'm looking for input on UTC from the people who think it is
needed :)

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

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: