7 Feb
2012
7 Feb
'12
7:37 p.m.
On Tue, 2012-02-07 at 19:29 +0100, Pedro Lopez-Cabanillas wrote:
We use this internally for sequences in Ardour, as it happens.
On Tuesday 07 February 2012, David Robillard wrote:
True. For some things you will need proper transport information
anyway, so perhaps it's not a good idea to complicate *everything* so
make the bar available, when no matter what certain things are going to
need to work with a real meter/tempo map anyway.
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. /* 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; Working directly with beats (and
fractions) would be more natural for applications like
quantization/groove/humanization/swing, or other rhythm effects.
This is true, and a very compelling argument, since this is the sort of
thing plugins are most likely to do.
Thanks,
-dr