[gmpi] Re: FW: Re: Topic 6: Time representation
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 8 May 2003 16:23:43 -0700 (PDT)
> I'm not sure, but it seemed to be that the argument for MUSTIME was that
> it's better for music data, while ABSTIME better for samples.
I just want to get an example of where this is ACTUALLY true, as opposed to
seemingly true. This is how I see it:
* a plugin can only operate on things in the current timeslice
* by the time the plugin is run for the current timeslice, all it's events
are known
* timeslices are measured in samples
* the plugin marches through the number of samples to generate and generates
data
> It might just be me, but I don't like the descriptions "MUSTIME" and
> "ABSTIME"... Can't we think of something which would be less
> confusing/technical for new users of GMPI, like "pulses" and "slices", where
> a pulse could be one element of musical time, while a slice an element of
> absolute time? Maybe they are the wrong words, but to people like me, when
> I'm introduced to a new API, I get easily put-off by un-necessarily
> over-complicated terms.
I agree about making things simple, but I don't know that this is too
obtuse. So far this is my understanding of the words:
* ABSTIME: free-running sample and UTS times - linear and monotonic
* MUSTIME: count of ticks since track start - non-linear and may loop
I'd actually like to change the way refer to time into:
* SAMPTIME: sample time (free-running sample count) - linear, may wrap
* USTTIME: unalterable system time (system-global usec or better) - linear,
monotonic
* TRANSTIME: transport time (ticks since start-of-track) - nonlinear, may jump
* METRTIME: metronome time (free running tick counter)
(obviously MTC, SMPTE, etc would be available, but based on other sources)
The only caveat this add, and I think it would be OK, is that any change of
the transport position must be tick-aligned.
> The problem with referencing by MUSTIME (for example, ticks) is that lower
> tempos reduce the resolution/precision. But the problem with ABSTIME is
This is a BIG and REAL problem. Now that I have defined the 4 time
references, their uses:
SAMPTIME: fundamental timestamp - every timeslice gets a 'now' value
measured in SAMPTIME and every event is stamped with SAMPTIME.
USTTIME: surrogate timestamp - every timeslice gets a 'now' value measured
in USTTIME and every event is stamped with USTTIME.
TRANSTIME: if we decide to have a peek API for plugs to peek
forward/backward, this is how those events would be stamped. It may be
simpler as 'Bar:Beat:tick' or just ticks. May need to be floating point.
Any plugin which cares about song position would register to get this value
as an event periodically.
METRTIME: fundamental musical timestamp. Plugins that want to stay
tempo-synced can receive metronome events every Bar, Beat, or tick. The
problem with a tick-based metronome is that at 140 BPM at 48k sampling with
2520 ticks per beat, you'll get a tick every 8.16 samples (or 352800 ticks
per second). Assuming timeslices of 128 samples or more, that will be a lot
of ticks per timeslice. Seeing as plugins can calculate this value simply
from available info, perhaps it is overkill.
Tim
----------------------------------------------------------------------
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:
