>> 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 !??? >
I've been looking back over at those source codes... Using a low ppqn such as 24 in my timebase code (based on non-sequencer) utterly fails. Using a ppqn of 100 in non-sequencer fails too. As does using a low ppqn in Dino. (I see you've used a low ppqn of 48 in Tritium/Composite, and are using jack_position_t::bbt_offset) In other words, you're right about it sticking when nframes < frames_per_tick and needing bbt_offset. Until now I did not realize this is worked-around by using a high ppqn such as 1920 or 2520 (which give integer results when divided by integers up to values 8 and 9 respectively (ie what the magic number means)). So with low ppqn values, the bbt_offset integer will be ok, but what about for high ppqn values? Even high ppqn won't be perfect, but might not a floating point bbt_offset improve the timing?* *not in my case, it's some more serious problem in my code. Cheers, James. >> [1] >> http://gitorious.org/composite/composite/blobs/master/src/Tritium/Tritium/TransportPosition.hpp >> >> http://gitorious.org/composite/composite/blobs/master/src/Tritium/src/transport/TransportPosition.cpp >> >> http://gitorious.org/composite/composite/blobs/master/src/Tritium/test/t_TransportPosition.cpp >> > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
