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

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Feb 2004 10:19:11 -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.  Transport time relates to the position within a piece of known
length.  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.

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

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

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

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

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


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: