Luppp's internals use a single(!) floating point, which mixes a bar number,
and a "percent" of that bar.
Found it quite nice to work with, to get the bar you just:
int bar = (int) floatBeatPercent;
while to get the percent you:
float percent = floatBeatPercent - ((int)floatBeatPercent);
In C you mention "bar" as int, and "beat" as float, I presume you want to
use the decimal part of the float to show "progress" trough that beat?
Thinking about very slow BPM's.. that could become important.
-Harry
On Tue, Feb 7, 2012 at 12:28 AM, David Robillard <d@email-addr-hidden> 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?
> * 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;
>
> I havn't run the math on precision yet, but I am leaning towards C. I
> actually hadn't considered mixing int and float before writing this
> email, but it seems the best trade-off, and working with float is
> certainly more pleasant than fixed point.
>
> Thoughts?
>
> -dr
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Feb 7 04:15:03 2012
This archive was generated by hypermail 2.1.8 : Tue Feb 07 2012 - 04:15:03 EET