On Sun, 11 Jul 2010, James Morris wrote:
can't say i exactly understand this bbt_offset. i'd already seen it in
the jack docs, and not really made sense of it there... but i've not
seen it used in source code in various sequencing/timebase apps and so
assumed i didn't need it either !???
Suppose you /intend/ for a steady stream of ticks (T) with a
certain 'nframes' for each buffer cycle (B)... shown below.
Your code will spit out ticks (0, 1, 2) as follows...
Intent: T T T T T T T
Cycles: B B B B B B
Output: 0 1 2 3 4 5
If you look at the output row, the output tick 1 isn't
really where tick 1 should be. More like 1.25. Likewise, 2
isn't being output where 2 is intended... rather 2.50.
So, bbt_offset allows you to keep track of this fractional
part. The bbt_offset is measured in audio frames. So, it's
like saying "Tick 1 /actually/ happened 25 frames before
now... but we haven't reached Tick 2, yet."
(I see you've used a low ppqn of 48 in Tritium/Composite, and are
using jack_position_t::bbt_offset)
<spouting_off>
FWIW, I inherited 48 ppqn from Hydrogen. Otherwise it would
be something like 1920... which is more common. However,
I've also considered totally dumping ticks as an obsolete
concept... using floating-point beats instead.
</spouting_off>
So with low ppqn values, the bbt_offset integer will be ok, but what
about for high ppqn values?
It is /never/ bad to use the bbt_offset. And in your case,
you need it in order to improve your calculations.
Even high ppqn won't be perfect, but might not a floating point
bbt_offset improve the timing?*
Yes, it will improve timing a little. In Composite
bbt_offset is a double in the range [-0.5,
frames_per_tick-.5). Using a floating-point bbt_offset
reduces long-term drift from tempo calculations.
For example, at 48,000 Hz, 48 ticks/beat, and 108.5 bpm....
----------- bbt_offset -----------
as double as int
================= ================
Frames per tick: 552.995 553
Frames per 100 beats: 2654377.88 frames 2654400.00 frames
Drift (frames): 0.00 frames 22.11 frames
Drift (sec): 0.00 sec 0.00046 sec
Using 44100/1920/108.5....
----------- bbt_offset -----------
as double as int
================= ================
Frames per tick: 12.70 13
Frames per 100 beats: 2438709.68 frames 2496000.00 frames
Drift (frames): 0.00 frames 57290.32 frames
Drift (sec) 0.00 sec 1.30 sec
So... if you use a high ppqn... you're more likely to drift
if you don't track bbt_offset.
-gabriel
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
