Re: External sync from another DAW: Ardour song pointer should follow ?

On 09/01/2018 03:34 AM, jonetsu wrote:
> On Fri, 31 Aug 2018 21:11:02 -0400
> Paul Davis <[email protected]> wrote:
> 
>> You can test this with qjackctl and jack_transport. qjackctl will
>> show its version of the position. jack_transport can be used to
>> locate a specific sample, and then you can compare. you can also see
>> in qjackctl if bitwig ever tells jack transport to go back to zero.
> 
> qjackctl will start at the bar position given by Bitwig.
> If Bitwig starts at bar 50 then qjackctl will start at bar 50.  If
> Bitwig loops between bar 25 and 35, qjackctl will do the same.  
> 
> However, the time value in qjackctl will always increment whereas when
> Bitwig loops, it will reset at the time value for bar 25.

A JACK timebase master is supposed to take jack-transport's absolute
timecode position and return the corresponding music-time (bar beat).
Bitwig lies about this. It ignores any absolute position and just
provides its own current music-time. This is pretty much useless.

Bitwig also ignores any absolute jack transport position, does not
support seeking, etc and only responds to jack-transport state: start/stop.

tl;dr: jack transport is not useful at all here.

This is a known issue and last I talked to Alexandre about it he said
it's a won't fix.  Mainly because jack-transport cannot varispeed,
jack-transport cannot be slaved and would be always in control (slow
sync clients, etc). -- This came up a while ago when users tried to
synchronize video to Bitwig using jack-transport and xjadeo.

The best you can probably do is to use Bitwig's MTC or MIDI-clock
generator as time-master and ignore JACK.

Cheers!
robin
_______________________________________________
Ardour-Users mailing list
[email protected]
To unsubscribe  or change your mailing preferences please visit:
http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org