[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:26 -0800

On Wed, Feb 04, 2004 at 08:03:10AM -0500, Paul Davis wrote:
> [[ 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" ]]

 this is really unclear. music time and transport are totally and
 inextricably linked. if the transport is not moving, then
 {music,transport} time does not move. the only difference between

Not necessarily true. If you think of music time more as a metronome, it keeps going.

Tempo change, time signature change...?

Transport time relates to the position within a piece of known

Length of a piece is not necessarily knowable.

If we allow syncing to music time - such as a delay every beat,
then we need to consider that music time continues while transport stops OR
we need to force tempo-synced effects to convert their tempo-sync into the
master clock or real time.

Freewheeling some clock from its last known rates to achieve this kind of special case effect is not necessarily the same as knowing the true musical position.

> transport time and music time should be merged. there is absolutely no
difference between them.

How would you like a tempo delay plugin to sync to the tempo? I know it's possible without a free running music time, but how do you think makes most sense? Specifically, if the transport is stopped, and I change the tempo, the tempo-synced delay must stay synced. If I change the time signature, it must stay synced.

1. I think musical position from the start of playback is a useful thing to be able to get, and is not a simple/direct conversion from sample clock, so I think we need both;

2. It remains to be seen whether the source of musical timing (out of band to note events etc.) should send interested plugs regular musical position update events (analogous to the MIDI Timing Clock message and/or MIDI Bar Marker & Time Signature messages), but this would be one way to clock the kind of thing you have in mind. (The alternative would be to rely -only- on a high-res fractional musical position stapled to the start of the current timeslice -- may be OK, but extracting beats gets messy.)

3. How bad would it be to say that musical clocking goes away when you press stop? (I'm asking, not trying to be snide.) Changing time signature and tempo while stopped is kind of an odd concept, as the conductor's baton is no longer moving...

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

 Only one transport controller per graph. if plugins want their own
 "play" or "stop" buttons that are independent of the rest of the
 graph, they can have them.

yeah, I agree.

Again I ask what the definition of 'transport controller' is. Is it just a tempo/time-signature master, or just a play/start/stop/locate master, or is it both? If it's just a thing that's iterating (say, looping) across its own chunk of score/notation/sequencer track, then there's no reason to limit the number of them. Imagine a bunch of individually start/stop/playable score readers each with its own little score fragment, ala Music for 18 Musicians. The only problem with having more than one is when it comes down to the music-time field in the event record, as you're no longer sure which TC's metrical system the field refers to -- but this can be solved by adding a TC ID to the event record.

> >* 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? ]]
 We have not defined what a "timeline controller" actually *is*, in the
 sense of what its appointed tasks/capabilities are.

I said earlier "Music time is managed by a timeline controller". It is the thing that manages music time, whatever music time ends up representing. I guess I can clarify the earlier to say something about how the timeline controller manages the variables, such as tempo and meter.

Yes please! 8-)

> >* GMPI must provide a way for a plugin to accurately convert between time
>formats and a TBD list of other formats (e.g. SMPTE).

SMPTE is a time format too. I would just say:

  * GMPI must provide a way for a plugin to accurately convert between
    any of a TBD list of time formats (likely to include at least
> zero-referenced audio frames, bars|beats|ticks, minutes:seconds, SMPTE)

SMPTE, like sample clock, can't be converted to musical position, nor vice versa, without knowledge of the full tempo/time-sig change history.

> Q: Do we allow for offsets between the zero reference point of all
formats requiring such a reference?

I don't know how SMPTE and friends work. I don't see any point in assuming that 0 on frames clock == 0 on ticks clock == 0:00 on time clock...

Offsets are needed.

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

 Its *absolutely* *critically* vital. Any time you have two streaming
 media clocks (e.g. audio hardware interface sample clock and video
 display vertical retrace clock), syncing them requires an independent
 third party. To not provide the UST for any event makes it impossible
 to accurately convert its time of occurence into a format based on the
 non-GMPI master clock (e.g. the video retrace clock).

I'm sorry I'm being dense on this - can you explain how UTC solves this? I understand about having a neutral high resolution clock, but based on my understanding of UTC (as we have defined it), how does it solve this?

Second that. I'd especially like an explanation of how UTC relates to sync across different boxes, word clock across different boxes, house sync, and how disagreements among all of the above should be resolved. In short: I'm a plug, hey here's an event that has to happen at a specific time, but the event has multiple time fields, so how do I decide when to use the UTC field vs. when do I use the sample frame index field?

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