Re: [Jack-Devel] JackTransport vs VST ppqPos

>> 
>> 
>> JACK does not do anything regarding those values: the timebase master *client* is responsible to update extended position information, counting beats, timecode, etc. (see : http://jackaudio.org/files/docs/html/transport-design.html)
>> 
>> I don't see any specific issues here on OSX testing either with jack_transport or Ardour as timebase master (well I see CBFBBT value staying the same while CBFF moving with jack_transport  at very low tempo like 1 or 2)
>> 
>> Can you try with Ardour also?
>> 
>> Stéphane 
> 
> Thanks for answer Stephane.
> Meantime I dig a little and I think that found a reason of this issue, If you look on this line from transport.c (jack_transport example client):
> pos->tick += nframes * pos->ticks_per_beat * pos->beats_per_minute / (pos->frame_rate * 60);
> 
> IMHO it mean "how many ticks are in current period". If nframes is 256 and frame rate is 96k  and BPM is 5 (or less) you got 0.928798 ... but pos->tick is uint32_t .. so you actually got 0 ;-). OFC this is related to your settings and that's way YMMV. Well ... in some cases jack_transport will not push BBT at all ;-)
> 
> The problem is in Transport design itself - because BBT master works always in current cycle space/context - I mean - it  doesn't look at the history (anyway it can't if we want to have tempo changes, right ?), and because ticks are uint32_t  we will have always some rounding.
> 
> The most simple way to fix this that I see is push tick to double - but this probably made some compatibility issues :(
> 
> Or maybe someone have better idea - maybe we can use pos->frame to adjust pos->tick in next frame ?
> 
> Pawel / Xj
> 

(this transport design is quite old…)

If ticks is changed from uint32_t to double then we may have a ABI problem yes...

Comments from other transport guru here? (I was not personally implicated with this design…)

Stéphane 

1368597271.561_0.ltw:2, <42B23749-2CE3-4DFD-BC51-C19FF3DD3352 at grame dot fr>