[gmpi] FW: Re: Topic 6: Time representation
- From: RonKuper@xxxxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 7 May 2003 13:16:37 -0400
Summary thanks to Chris Grigg. Thoughts?
>Any volunteers to post a summary like the one I posted first thing
yesterday
>morning? Are we converging on anything here yet? <g>
Here goes... though my confidence is low on a lot of this. Let's
call it a strawman summary. (Everyone jump in, please, where I'm
wrong.) I'm writing this Saturday afternoon, from an email fetch
around 11:30am, so sorry if this is out-of-sync with the discussion
by the time you read it!
-- Chris
-------------------
Summary of Topic 6: Time Representation -- STRAWMAN #1
1. Discussion Notes
Deciding on time representations necessitated several side
examinations, notably time resolution requirements for various GMPI
deployment contexts, cross-host timing repeatability, and the
implications of different representations (esp. MUTIME) for the
design of the event routing and queuing mechanism. These sidetrips
should be reviewed as part of the discussion for the relevant
sections of the overall GMPI design plan.
2. Time Representation Formats
There are two different time representation formats passed to GMPI
plug-ins: ABSTIME and MUSTIME. It is expected that they will also
suffice for any event times generated by GMPI plug-ins, although that
has not yet been examined in detail.
2.1. ABSTIME
ABSTIME is an extremely high-resolution integer time with sub-sample
accuracy. In typical applications the ABSTIME timebase will be much,
much faster than the GMPI graph output sample rate, and not
necessarily an integer multiple of that rate. ((( include Mike's
proposal of samp rate * tick?))). Format for an ABSTIME timestamp is
a 64-bit binary integer.
There are two kinds of ABSTIME timebase masters in every GMPI graph:
the GMPI graph's "stream time" (((*** define please? ***))), and the
UST (aka "wall time"), for synchronization. (See also 3.1 below) The
UST is typically derived from a highly reliable host OS/platform
timing service or hardware source.
The rate of any ABSTIME timebase master is expressed in steps per
second. It has not been decided whether the number of steps per
second is limited to an integer, vs. can include a fraction. Any
ABSTIME timebase must always increase monotonically, not counting
wraparound events.
2.3. MUSTIME
MUSTIME represents a position in musical time, i.e. in ticks, beats.
In other words, the real time of a given MUSTIME depends on musical
tempo, including the accumulated history of tempo changes. Format of
a MUSTIME timestamp is (((*** TBD ***))).
There may be more than one MUSTIME master in a GMPI graph. In
typical applications a MUSTIME timebase may be driven by stored
setting or events in sequencer tracks, or manipulated in real time.
A MUSTIME timebase must never decrease over time, not counting
wraparound events, however the rate of increase is dependent on the
musical tempo which is liable to vary over time; remember that any
GMPI plug-in should be able to accept any tempo that can be
represented. (((OK, I just made that last bit up -- but only so
we'd remember to think about it when we get to tempo.)))
3. Uses of Time Representations
3.1. Time Representations In Timeslices Passed to Plug-Ins
For every timeslice presented to a GMPI plug-in's process() routine
(the function that renders audio buffers), two separate timestamps in
ABSTIME format are furnished: the GMPI graph's "stream time" at the
first sample of the timeslice, and the UST (aka "wall time"), for
synchronization. It is a design assumption that any timing errors
due to drift between the two sources over the course of a single
timeslice will be acceptable.
3.2. Time Representations In Events Passed to Plug-Ins
All events presented to GMPI plug-ins should include an ABSTIME timestamp.
Events intended to have a musical time semantic that are timed for
execution within the current timeslice should have both an ABSTIME
timestamp and a MUSTIME timestamp when presented to a GMPI plug-in.
For musical events timed for execution after the current timeslice,
either a) the ABSTIME timestamp should not be used, since any future
changes to the tempo would invalidate the times, or else b) an
invalidate-and-update mechanism should be supplied (((***boy, that
sounds messy. ***))).
3.3. Time Representations In Events Generated By Plug-Ins
All events not intended to have a musical time semantic that are
generated by GMPI plug-ins should include an ABSTIME timestamp, and
no MUSTIME timestamp.
When a GMPI plug-in generates an event intended to have a musical
time semantic that's timed for execution within the current
timeslice, in addition to the MUSTIME timestamp an ABSTIME timestamps
can and should also be included, since it can be determined by
consulting the corresponding MUSTIME timebase source.
When a GMPI plug-in generates an event with a musical time semantic
that's timed for execution after the current timeslice, ABSTIME
timestamps should either a) not be included (((*** implying the host
has to provide it just-in-time by scanning the queue right before
calling process()...??? ***))), since any future changes to the tempo
would invalidate the times, or else b) an invalidate-and-update
mechanism should be supplied (((*** messy again. ***))).
3.4. Time Representations Conversions
There should be a way for a plug to convert an ABSTIME timestamp to a
sample index, and vice versa, to allow the plug to use its internal
sample index counter to clock incoming events out of a queue.
For MUSTIME, there should be a mechanism for converting a MUSTIME
timestamp to an ABSTIME. Because of differences in tempo histories,
different MUSTIME masters will give different ABSTIMES for the same
MUSTIME, so care must be taken to consult the relevant MUSTIME
timebase master.
..end..
----------------------------------------------------------------------
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:
