12 Jul
2010
12 Jul
'10
12:59 a.m.
On 11 July 2010 23:09, Gabriel M. Beddingfield <gabrbedd(a)gmail.com> wrote:
On Sun, 11 Jul 2010, James Morris wrote:
Currently my system passes around two values, the tick of the
playhead, and the tick the playhead will be (supposedly) at the start
of the next process call. These are integers of course. And events can
easily be checked against these values to see if they should be
triggered/output/whatever.
Given the drift thing, and that jack_position_t::tick is an integer, I
decided to keep track of the tick position myself using a double and
then using the floored version of that to assign to jack's tick.
This works for low ppqns - ie the transport is no longer stuck, and
the debug messages informing a tick has been dropped every other frame
or so, are very similar to what happened when using ardour as timebase
master (as opposed to my app) which looks promising :-)
But the increase in accuracy afforded by the floating point tick
tracking, is lost with the integer playhead tick position being passed
around all over. So I then the offset* is stored.
*) offset = (double)int_playhead_tick - double_playhead_tick)
But then additionally a low ppqn means the next playhead position is a
fraction of a tick later. And then there's this bbt_offset business
which seems overly complex to me.
So rather than do the bbt_offset stuff, for each process period:
just brute-force-it and convert everything to the highest resolution
possible - frames
I suspect/hope it might be easier, but also suspect I'm still missing something.
James.
> 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>