On Tue, 2012-02-07 at 19:29 +0100, Pedro Lopez-Cabanillas wrote: > 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.
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. > > /* 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; We use this internally for sequences in Ardour, as it happens. > 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
