[gmpi] Re: 3.9 Time Formats

  • From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Sun, 8 Feb 2004 09:30:16 -0500

Good summary.

Conductor time will get out of sync with other times after a pause. I think
a good question for thinking about GMPI time is how to handle the
synchronization between the times, especially as the user is fooling around
with the transport, loops, and such.

Just a preliminary and hasty list of use cases:

1. Straight scoring and playback, e.g. for making movie music using hardware
or software synthesizers. All times always in sync, but starting and
stopping at arbitrary points in the score.

2. Straight multi-track recording, e.g. for recording live music. All times
always in sync, possibly stopping and starting at various sections.

3. Straight multi-track recording with overdubbing, e.g. for recording
"live" tracks at home. All times always in sync, starting and stopping at
arbitrary points.

4 and 5. 2 and 3 with inserts. All times in sync, starting and stopping at
arbitrary points.

6 and 7. 2 and 3 with loops. Different timelines inside loops, starting and
stopping at arbitrary points.

8. 1 with score generating and time warping plugins (composer's assistant,
"feel generator"). All times always in sync, starting and stopping at
arbitrary points, plugins controlling or modifying host's timeline.

9. 4, 5, 6 and 7 with score generating and time warping plugins (band
recording with automatic rhythm section). Different timelines inside loops,
starting and stopping at various points.

10. Live performance with 1, i.e. to a scored performance ("tape with
performer").

11. Live performance with 8, i.e. to a scored/A.I. performance ("interactive
computer music", band performing with automatic rhythm section). Also need
to allow for "score follower" and "cue detector" plugins that would receive
user events and interact with the host's transport.

12. Live performance with 6 and 7 ("laptop music"). Also need to allow for
"score follower" and "cue detector" plugins that would receive user events
and interact with the host's transport and loop timelines.

13. Live performance with 9 ("computer-assisted DJ or dance music"). Also
need to allow for "score follower" and "cue detector" plugins that would
receive user events and interact with the host's transport and loop
timelines.


============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: "GMPI list" <gmpi@xxxxxxxxxxxxx>
Sent: Sunday, February 08, 2004 4:55 AM
Subject: [gmpi] 3.9 Time Formats


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


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