[gmpi] Re: Topic 6: Time representation
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 30 Apr 2003 13:30:39 -0400
>Yes, the plug could quite likely need a mechanism whereby it can reliably
>work out bars, beats, meter etc. I worry that standardizing on this at too
>low a level in the spec may be restrictive, and would rather see this
>delivered as a high level sync event.
you're absolutely right. the LAD group discussed this all for weeks in
the context of XAP. tim presented the results yesterday. tempo/meter
events work much better than a continuous reference time.
likewise for transport changes.
so forget what i wrote. this leave us with:
>> monotonic sample clock (frames, int64)
>> UST (nanoseconds, int64)
plus events delivered to plugins that request it to notify them of
non-linear (or any?) changes in transport position, plus any (or some
subset of?) tempo/meter events (tempo changes, meter changes).
it was all laid out in tim's summary, which i repost for your delight:)
----------------------------------------------------------------------
Tempo and Meter
---------------
XAP uses Controls for transmitting tempo and meter information. If a
Plugin defines a TEMPO control, it can expect to receive tempo Events on
that control. The Host must define some unit of musical-time measurement
(Tick), which represents the smallest granularity the host wants to work
with. This is the basis for tempo and meter. The host publishes the
current count of Ticks/Beat via the host struct. A suggested value for
ticks/beat is 2520 (divisible by 2,3,4,5,6,7,8,9,10,12,14,15,18,20..).
Control: TEMPO
Type: double
Units: ticks/sec
Range: [-inf, inf]
Events: Hosts must send a TEMPO Event at Plugin init and when tempo
changes.
Control: METER
Type: double
Units: ticks/measure
Range: [0.0, inf]
Events: Hosts must send a METER Event at Plugin init and when meter
changes. Hosts should send a METER Event periodically, such as
every measure or once per second.
Control: METERBASE
Type: double
Units: beats/whole-note
Range: [1.0, inf]
Events: Hosts must send a METERBASE Event at Plugin init and when meter
changes.
This mechanism gives Plugins the ability to be aware of tempo and meter
changes, without forcing information into plugins that don't care. A
Plugin can sync to various timeline events, easily.
The Host struct also provides a mechanism to query the timestamp of the
next Beat or Bar, and to convert timestamps into the following time formats:
* Ticks
* Seconds
* SMPTE frames
Sequencer Control
-----------------
XAP plugins may be aware of certain sequencer events, such as transport
changes and positional jumps. These data are received on Controls.
Control: POSITION
Type: double
Units: ticks
Range: [0.0, inf]
Events: Hosts must send a POSITION Event at Plugin init, when transport
starts, and when transport jumps. Hosts should send a POSITION
Event periodically, such as every beat, every measure or once per
second.
Control: TRANSPORT
Type: bool
Units: on/off
Events: Hosts must send a TRANSPORT Event at Plugin init and when
transport state changes.
----------------------------------------------------------------------
>That looks like a good format for a default syncpulse event type. Are we
>assuming these musical_ticks are fixed at some common high resolution
>(1920PPQN or something) or host-defined?
as mentioned, 2520 is the best possible (reasonable) value. the host
should be able to define it and provide to the plugin.
--p
----------------------------------------------------------------------
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:
