[LAD] transport/timebase calculations

[Gabriel M. Beddingfield]

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