[gmpi] Re: 3.9 Time Formats
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: GMPI list <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 10 Feb 2004 19:45:46 -0800
On Sun, Feb 08, 2004 at 01:55:09AM -0800, Tim Hockin wrote:
> filling in of details and aspects, and USE CASES for each. Then we can
> figure out which are really important.
Only one reply? Has everyone lost interest in this topic so quickly?
> 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.
For completeness, a use case:
A reverb plugin is called to process 512 samples of input. It is told the
sample time of the starting sample for that block. It may also receive zero
or more events, timestamped with the sample time at which time they should be
processed.
> 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.
a use case would be most helpful...
> 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.
I am not sure why this is useful. If the clock is running, I press pause,
then I unpause - one of three things happens. We either potentially cut the
last tick (or whatever unit) of the paused state short, or we delay the
unpause until the next edge, or we have this clock be out of sync with the
musical position
Example:
tick 0 1 2 3 4
|----|----|----|----|
playing .......... .......
paused ...
The pause happens when the musical position is DONE with tick 1 (the next
instant would begin tick #2). The pause does not last for an even tick
count. So when we unpause do we:
a) warp to the next tick-start, cutting #2 short
b) not unpause until the next tick-start, delaying the action
c) keep the musical position as unaligned from the conductor position
This gets worse if we consider any unit bigger than ticks. Do we wait until
the next bar to unpause? Yikes.
> - 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.
This suffers the same problems as Conductor time.
> - 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.
This does not suffer the same problems as Conductor and Metronome time,
exactly, but has a similar problem. If you allow the host to loop at a
point in time that is not at a tick-edge to a point that IS at a tick edge
(more correctly looping between two points at different phases of a tick),
then you have the same decision. Warp to the new phase, unsync the timeline
from musical position, or do not allow this to happen.
> - 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.
This one is always in sync with the musical position. No unsync issues
arise, but plugins see a discontinuous timeline.
> 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.
2 use cases:
A sequencer plugin has a track that is of some length. The user controls
the transport to jump to a point which is in the middle of this sequencer
track. The sequencer track needs to be notified so that it's playback head
can be adjusted. Is it notified in samples? It would need to keep a
mapping of all the tempo changes to sample positions in order to find the
right position. It's probably easier to notify it in musical units - ticks
or beats or similar.
An audio-track plugin has a track that is of some length. The user controls
the transport to jump to a point which is in the middle of this audio track.
The plugin needs to be notified so that it's playback head can be adjusted.
Is it notified in musical units? It needs to know the history of tempo
changes to find the right position. It's probably easier to notify it in
samples.
With those messes on the table, some more use cases. I think it will be
very useful to think up as many crazy use cases as we can and see how they
can be solved most elegantly.
1) A simple tempo-synced delay. The plugin needs to be able to find out
when the time will be 3 beats from now, and needs to know about tempo
changes.
2) A quantizer. The plugin needs to be able to to find out the current
position within the current bar/beat, as well as the start of the next
bar/beat.
3) A sequencer. The plugin needs to know the current tempo and the current
transport position in musical units or sample units
Let's think up more.
>
>
> ----------------------------------------------------------------------
> 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
--
Notice that as computers are becoming easier and easier to use,
suddenly there's a big market for "Dummies" books. Cause and effect,
or merely an ironic juxtaposition of unrelated facts?
----------------------------------------------------------------------
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:
