;-)
Let me get this straight: You want musical time to continue while
paused so that beat-sync FX can continue to run, yet you find fault
with all of the musical time types that allow musical time to
continue while paused?
As discussed ad nauseum, this really rather narrow need can be solved
either a) by sending musically regular musical-time position update
events (beats, barlines, etc.) to those few plugs that care about
that stuff continuing during pause, or b) requiring those few plugs
that care about that stuff to maintain their own internal
samplePositionToMusicalPosition() translations. Both solutions seems
uncontroversial to me.
Would you be willing to take a second whack at the four time types
from some (i.e. any less single-issue) other POV than while-paused
clocking? Like what the plug might conceivably want to do with each
one of them while the graph is running normally?
-- Chris G.
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.
> stop or reset this clock, but pauses pause it. Depends on transport- Performance time starts at 0 when performance starts, and grows monotonically until performance is stopped. Loops do notstate.
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
---------------------------------------------------------------------- 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
