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