[gmpi] Re: 3.9 Time wrap up Try #1
- From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 1 Mar 2004 21:21:54 -0500
In a prior post, I described some of the use cases that you say are missing.
I repeat them below. Cases 11, 12, and 13 require "conductor time" or
"performance time", i.e. loops and pauses do not affect the time which is
used by live performers even as software and/or a human operator start,
stop, and restart loops or tempo-modifying software.
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: Monday, March 01, 2004 5:39 PM
Subject: [gmpi] 3.9 Time wrap up Try #1
> The first attempt at a time wrap up:
>
> So far, this is what I've been able to gather. Still waiting for more
> feedback, if it is needed?
>
> (for the final doc, I'll stick the use cases in, too)
>
> REQUIREMENTS:
> --------------------
>
> * GMPI must provide one master clock per graph. The GMPI master clock
must
> be sample based and provide sufficient range to represent several hours
of
> time at a high sampling rate (i.e. 64 bits). The specification or
> implementation may decide to provide sub-sample resolution. Hosts may
> build multiple graphs with different master clocks. All GMPI plugins
have
> exactly one master clock.
>
> * GMPI must provide some musically-significant clock. Music time is
> dependant on variables such as tempo and meter and is measured in some
> musically useful unit, such as bars, beats, ticks, or a subdivision
> thereof. There may be more than one such clock in a graph.
>
> * GMPI must provide a way for plugins to be notified of changes to
> music-time variables, such as tempo and meter.
>
> * GMPI must provide a way for plugins to get relative musical timings
(e.g.
> given a start time, accurately find out when the time is exactly 1 beat
> later) and absolute musical milestones (e.g. accurately find out when is
> the start of the next beat).
>
> * GMPI must provide a way for plugins to control music-time variables,
such
> as tempo and meter.
>
> * GMPI must provide a way for plugins to be notified of changes to the
> transport state (e.g. playing or paused).
>
> * GMPI must provide a way for plugins to be notified of changes in the
> playback location (e.g. loops or jumps).
>
> * GMPI must provide a system-global clock (UST) which is not dependent on
> the sample clock.
>
> [[ We still do not have a use case written for this. The thing that
holds
> me back from embracing this totally is Mike Berry's position (Premiere
> being a prime example of the application class that supposedly "needs"
> UST):
>
> "I believe that all of the systems we are talking about running on
> have some form of independent clock. So if the plugin needs it, it
> can do it with a system call, or if it is cross platform, it can
wrap
> the system calls per platform...While there may be a bit of utility
> (for plugins) added by having GMPI do the wrapping (i.e., making
the
> host do the wrapping), I think it is more than offset by the
> complexity of having another time..."
>
> So what is the verdict? ]]
>
> * GMPI must provide a way for plugins to accurately convert between the
> various timelines, and a TBD list of other time formats (e.g. SMPTE)
> within a processing timeslice.
>
>
> EXTRA INFO:
> -------------
>
> Timelines:
> 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
> * 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.
>
> [[ No use case supports this, and there are problems. I propose
we
> drop it. ]]
>
> - 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.
>
> [[ No use case supports this, and there are problems. I propose
we
> drop it. ]]
>
> - 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.
>
> [[ Same problems as 'conductor time'. If we force loops/jumps to
> always happen on tick edges, it can stay in tick-sync. Still, no
use
> case for it. ]]
>
> - 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.
>
> STILL OPEN:
> -------------
> * UST wrap up
> * What aspects are optional features of the host? Any?
> * Is music-time optional, or do you have to fake it?
> * Thoughts on resolution and units for music time?
> * Which music timeline(s) do we endorse and which do we drop?
> * Do we need to clock music-time (beats, ticks, etc) regularly?
> * Do we need to discuss anything right now about semi-static maps for
> meter/tempo/etc. ?
> * Other issues?
>
> ----------------------------------------------------------------------
> 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:
