[gmpi] Re: Topic 6: Time representation
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 30 Apr 2003 13:08:21 -0400 (EDT)
On Wed, 30 Apr 2003, Paul Davis wrote:
> yes, and in fact i realize now that just getting musical ticks is more
> or less useless without an equivalent "decompress musical time"
> conversion anyway (i.e. you really need something like
> bars|beats|ticks, not just ticks, to do useful things).
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.
> 1) we provide process() with:
> transport time (frames, int64)
> monotonic sample clock (frames, int64)
> UST (nanoseconds, int64)
The problem is that transport time can reasonably be expected to be
discontinuous within the block, so I'm not sure of the use of providing it
automatically at the start of process().
I agree we should provide the other two though.
> i would want structured musical time to look something like
>
> struct {
> int32 bars; // since transport_time = 0
> int32 beats; // since start of bar
> int32 ticks; // since start of beat
> int64 total_ticks; // since transport_time = 0
> };
> /* information about the current meter */
> float beat_type; // note divisor (eg. 4 for beat=quarter note)
> float beats_per_bar; // beats per bar, duh.
> float beats_per_second; // tempo
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?
Regards,
Angus.
----------------------------------------------------------------------
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:
