linuxaudio.org

On Tue, 2012-02-07 at 19:29 +0100, Pedro Lopez-Cabanillas wrote:

quoted text
> 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) */

quoted text
> > 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

quoted text
> 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

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev