11 Jul
2010
11 Jul
'10
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…