Re: [LAD] transport/timebase calculations

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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Jul 12 04:15:01 2010