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

Sorry,
Tim

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