7 Feb
2012
7 Feb
'12
7:29 p.m.
On Tuesday 07 February 2012, David Robillard wrote:
Hi all, seeking opinions:
I have to choose a way to represent beat-based tempo time in 64 bits.
Uses are many, but the main one is event time stamps for plugins.
Requirements:
* No odd data sizes (for performance / programmer ease)
* High precision (ideally close to sample accurate for most tempos)
* Fits in the same space as two uint32_t's
Questions:
* Is "bar" needed?
Probably not, for most use cases. Bars are required for notation, and useful
for rhythm matters, but the important rhythm element is the beat, and with
beat count and tracking time signature changes you can calculate the bar
numbers very easily.
* Use floating point? Rounding errors an issue?
Options:
/* A (moderate range, ultra precise) */
struct {
uint16_t bar;
uint16_t beat;
uint32_t tick;
};
/* B (high range, moderate precision) */
struct {
uint32_t bar;
uint16_t beat;
uint16_t tick;
};
/* C (high range, good precision?) */
struct {
uint32_t bar
float beat;
};
/* D (high range/precision, but no bar) */
double beat;
This would be my preferred option. It would be similar also to Apple's
AudioToolbox framework:
MusicTimeStamp. A timestamp for use by a music sequence.
typedef Float64 MusicTimeStamp;
https://developer.apple.com/library/mac/#documentation/AudioToolbox/Referen…
CH3-SW3
Musical time is traditionally represented by an integer tick count, which
requires the reference of a timebase (ticks per beat) in order to calculate
beats from ticks. Timebase must be carefully chosen (for exact divisors) and
big enough to provide good resolution. Finally, you need the tempo (beats per
minute) to calculate the absolute time. Working directly with beats (and
fractions) would be more natural for applications like
quantization/groove/humanization/swing, or other rhythm effects.
Regards,
Pedro