[gmpi] 3.9 Time Formats

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: GMPI list <gmpi@xxxxxxxxxxxxx>
  • Date: Sun, 8 Feb 2004 01:55:09 -0800

I'm trying to get a clearer picture of the various proposed time formats and
use cases.  If I have left any or mis-characterized any, please correct me.

I think what I'd like to see are reasons for/against the various forms,
filling in of details and aspects, and USE CASES for each.  Then we can
figure out which are really important.

I hope this helps to clarify some....


1. Sample time/absolute time:
   * samples or sub-samples
   * one clock per graph
   * immutable during the life of a plugin
   * set by the host
   * integral
   * monotonic

   This is the fundamental timestamp on all events.

2. Universal time/unadjusted system time (UST)
   * platform-defined resolution
   * one clock per computer
   * immutable
   * read from the OS/system
   * integral
   * monotonic

   Streams with different fundamental timings, such as video and audio, can
   be synced by UST.  All realtime events, such as MIDI input may need UST.
   It may be sufficient to calculate the UST time and the UST->sample time
   factor periodically, such as once per process cycle.

3. Music time
   * ticks or other musical units
   * N clocks per graph
   * totally variable, based on tempo and meter
   * set by some sort of controller entity (host or plugin)
   * integral or real number - unclear yet

   There are four proposed variants of this clock:
   - Conductor time starts at 0 when performance starts, and grows
     monotonically until performance is stopped.  Loops and pauses do not
     stop or reset this clock.  Depends on transport state.
   - Metronome time starts at 0 at some point in time and grows
     monotonically until the host exits.  Loops, pauses, and transport state
     do not affect this clock.
   - Performance time starts at 0 when performance starts, and grows
     monotonically until performance is stopped.  Loops do not
     stop or reset this clock, but pauses pause it.  Depends on transport
     state.
   - Score time starts at 0 when performance starts, and tracks the
     transport position.  Loops will warp this clock backwards, jumps will
     warp this clock forwards.  Depends on transport state.

4. Transport time
   * unknown resolution
   * N clocks per graph
   * totally variable, based on transport state, playback position, and
     shuttle speed
   * set by some sort of controller entity (host or plugin)
   * integral or real number - unclear yet

   Maybe this is the same as score time?  Maybe not.  If you have a wav file
   playback plugin, and you jump to 50% through a track, it doesn't do any
   good to express that in musical units (which depend on the history of
   tempo and meter), but it doesn't do any good to express that in samples
   to a plugin which is musically oriented.  It is not always possible to
   know the length of a performance, so percentage of performance is
   awkward, too.



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