New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync is unstable when new JACK clients enter or exit #9
Comments
that is probably a sign that ardour, as a jack client I presume, is not even syncing to jack-transport; and what about which jack client is timebase master? are they all (ardour, rack and sc) trying to be?
yes, I know and that's been actually intended, to have it sync to precise beat times, at least with qtractor; you can of course try whether having |
Might be interesting so see what happens if you replace Ardour with Qtractor. |
It definitely is, at least at first, if I set everything up in a precise order.
This seems to be a fairly common misconception about Link. By design, Link establishes no master clock. The Link peers cooperate to converge on a shared timeline. I suspect this is the root of the trouble here. If JACK transport expects to be the master clock, that's at odds with Link's design where any/every clock should be able to make micro-adjustments to keep together with the shared timebase. But, if JACK transport clients expect the transport to be sample-accurate consistent, then JACK transport must not adjust. I'm guessing this is why it's using forceBeatAtTime: to avoid adjusting. (I bet if you try to run two JACK transports on separate machines, with jack_link on both machines, it would be messy.) So it may simply not be possible to make JACK transport and jack_link work in the Link way. What surprised me is that adding/removing JACK clients seemed to disrupt JACK transport. Maybe that's a JACK bug and not a jack_link bug. Not sure about qtractor. If I have time later I might try it. |
I don't think you can change the tempo of Ardour, but from Ardour itself. IIRC it doesn't accept a tempo change of jack_transport from a other Jack Tranport master. |
After some more tests, I think the central problem is that JACK transport just can't go along with the Link way. jack_link can't override JACK transport's behavior, so it can never be a polite Link peer. Qtractor handles it better than Ardour, but still not completely stable. Test A:
Test B (this one really highlights the difficulty):
At this point, two things happen depending on the Link function being called:
Link's specification here is that peers should begin in phase with the shared timeline. For JACK transport, that means, if I click "play" 1.5 beats into the bar, JACK transport should either begin playing immediately from 1.5 beats into the bar and not from the bar line, or it should wait until the next bar line to start playing. JACK transport doesn't know anything about Link, so it doesn't care what anybody else is doing, and jack_link has no power to make it care. I'm guessing Paul Davis would not be receptive to suggestions to change JACK transport for better Link cooperation (Link means sacrificing sample accuracy and perfect timeline continuity)... so it's probably better just to document that jack_link may work under specific situations (set up all peers and start the JACK transport before playing anything in other software -- but even here, tempo changes failed badly) but probably shouldn't be relied on in production. |
there's an alternative: |
Preparing for a video tutorial on Link sync and SuperCollider, I did this:
At this moment, the Link timeline slows and sync is lost: the barline on the JACK transport no longer corresponds to the barline in Ardour, Rack or SuperCollider (and they all seem to be slightly different offsets).
If I sync SC and Rack without jack_link, then I can boot and reboot the SC server (creating and destroying JACK clients) at will, without disrupting the Link timeline.
So I have to conclude that jack_link is doing something unnecessary.
For my demo, I think I can be careful to have all JACK clients running the whole time. Or I may simply not use jack_link at all (a pity, because I wanted to show it hooked up to a DAW). But something isn't right here.
Are you using
forceBeatAtTime()
? Ableton recommends against it.The text was updated successfully, but these errors were encountered: