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...@drobilla.net> 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@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev >
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev