11 Jul
2010
11 Jul
'10
3:27 p.m.
Hi,
I can't see what's wrong with the calculations I'm performing for
timebase/transport in my JACK app. I'm not sure where the error lies.
I keep looking and looking at it, changing bits, experimenting, and
still not getting the desired result.
Everything is playing too slow. For example, @ 120bpm 4/4 time, the
second (or third) bar starts almost an entire beat too late.
Please could someone take a look at the calculations and see if
there's something obviously wrong with them?
The source can be viewed online at:
http://github.com/jwm-art-net/BoxySeq/blob/master/jack_transport.c
The poll function starts at line 169
the jack timebase call back starts at 226.
The code was originally based on non-sequencer or dino or some
combination of both.
It is also a bit grumpy with other JACK apps which use transport, but
I trying to fix the time keeping first.
TIA,
James.
11 Jul
11 Jul
5:02 p.m.
Hi Jamees,
On Sun, 11 Jul 2010, James Morris wrote:
Hi,
I can't see what's wrong with the calculations I'm performing for
timebase/transport in my JACK app. I'm not sure where the error lies.
I keep looking and looking at it, changing bits, experimenting, and
still not getting the desired result.
Everything is playing too slow. For example, @ 120bpm 4/4 time, the
second (or third) bar starts almost an entire beat too late.
Please could someone take a look at the calculations and see if
there's something obviously wrong with them?
Here's some thoughts. I haven't checked my math on these...
but hopefully they're helpful. FWIW, I've spent a lot of
time perfecting transport calculations[1], so I'm not just
spouting off.
250 pos->beat = (int32_t)(abs_beat -
251 (double)pos->bar * pos->beats_per_bar + 1);
Your abs_beat starts at zero. bar*beats_per_bar also starts
at zero. Beats in a measure start at 1. So, I think this
should be:
250 pos->beat = 1 + (int32_t)(abs_beat -
251 (double)pos->bar * pos->beats_per_bar);
Now... for the tick:
253 pos->tick = (int32_t)(abs_tick - abs_beat * ppqn);
Your abs_beat needs to be rounded down... because it's still
a double and still has the fractional part. Perhaps:
253 pos->tick = (int32_t)(abs_tick - floor(abs_beat) * ppqn);
Now, for your rolling transport counter code...
262 pos->tick += (int32_t)
263 (nframes * pos->ticks_per_beat * pos->beats_per_minute
264 / ((double)pos->frame_rate * 60.0f));
I think this suffers from truncation error. It assumes that
whenever the tick changes, it is perfectly aligned with
frame 0 of the current cycle. If nframes << frames_per_tick,
I think it'll get stuck. To un-stick it, you may want to
keep track of the bbt_offset.
Hope this helps,
Gabrial
[1]
http://gitorious.org/composite/composite/blobs/master/src/Tritium/Tritium/T…
http://gitorious.org/composite/composite/blobs/master/src/Tritium/src/trans…
http://gitorious.org/composite/composite/blobs/master/src/Tritium/test/t_Tr…
8:29 p.m.
On 11 July 2010 16:02, Gabriel M. Beddingfield <gabrbedd(a)gmail.com> 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 !???
Cheers,
James.
Everything is
playing too slow. For example, @ 120bpm 4/4 time, the
second (or third) bar starts almost an entire beat too late.
Please could someone take a look at the calculations and see if
there's something obviously wrong with them?
Here's some thoughts. I haven't checked my math on these...
but hopefully they're helpful. FWIW, I've spent a lot of
time perfecting transport calculations[1], so I'm not just
spouting off.
250 pos->beat = (int32_t)(abs_beat - 251
(double)pos->bar * pos->beats_per_bar + 1);
Your abs_beat starts at zero. bar*beats_per_bar also starts
at zero. Beats in a measure start at 1. So, I think this
should be:
250 pos->beat = 1 + (int32_t)(abs_beat - 251
(double)pos->bar * pos->beats_per_bar);
Now... for the tick:
253 pos->tick = (int32_t)(abs_tick - abs_beat * ppqn);
Your abs_beat needs to be rounded down... because it's still
a double and still has the fractional part. Perhaps:
253 pos->tick = (int32_t)(abs_tick - floor(abs_beat) * ppqn);
Now, for your rolling transport counter code...
262 pos->tick += (int32_t)
263 (nframes * pos->ticks_per_beat * pos->beats_per_minute
264 / ((double)pos->frame_rate * 60.0f));
I think this suffers from truncation error. It assumes that
whenever the tick changes, it is perfectly aligned with
frame 0 of the current cycle. If nframes << frames_per_tick,
I think it'll get stuck. To un-stick it, you may want to
keep track of the bbt_offset.
Hope this helps,
Gabrial
10:10 p.m.
Now, for your
rolling transport counter code...
262 pos->tick += (int32_t)
263 (nframes * pos->ticks_per_beat * pos->beats_per_minute
264 / ((double)pos->frame_rate * 60.0f));
I think this suffers from truncation error. It assumes that
whenever the tick changes, it is perfectly aligned with
frame 0 of the current cycle. If nframes << frames_per_tick,
I think it'll get stuck. To un-stick it, you may want to
keep track of the bbt_offset.
Hope this helps,
Gabrial
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 !???
12 Jul
12 Jul
12:10 a.m.
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
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>
5293
days inactive
5293
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
2 participants
participants (2)
-
Gabriel M. Beddingfield -
James Morris