I played a bit with Jack Transport support in Renoise 2.8 x86_64 (registered version). It syncs multiple Renoise instances together perfectly, which is great! Much more accurate than the old MIDI sync.
But there are some issues which make Jack Transport cumbersome, and not very useful for live use.
To reproduce: Start 2 Renoise 2.8 instances, both with Jack Transport Sync enabled in the preferences (one will display “running as timebase master”, the other “slave”). Load identical song in both of them. I am using Jack2 (version string “jackdmp version 1.9.8 tmpdir /dev/shm protocol 8”).
The “queue pattern” feature plays the pattern immediately when Jack Transport is enabled. I would expect the pattern to be queued like it normally is.
When one instance is in Pattern Loop mode, queuing a different pattern just restarts the loop from the beginning. When scrolling the mouse wheel over the song position bar, sometimes it looks like the other pattern plays for a short time, then it switches back to the other one (but sometimes it does switch over to the other pattern). It happens in both slave and master mode. I’d expect that you could set the play position like normal.
When you change the BPM in a slave, both master and slave seem to jump to the beginning of the played pattern, “stutter” a bit, then the BPM goes back to the previous value. I’d expect that you can either change BPM in the slave, which would sync the master, or that changing BPM from a slave would have no effect. In either case, it shouldn’t stutter.
When you start, stop, or change play position from a slave (when not in pattern loop mode), the master gets synced to the new position too. I’m not sure whether that’s supposed to happen. “Slave” sounds to me like it should just accept transport commands, not send them, but I might be wrong.
Overall, basic sync with Jack Transport is functional. But I think the feature needs some work to make it as polished as the rest of Renoise.
Some of these problems root inside Jack and not Renoise, this also has been explained multiple times by Taktik (if you would have searched the forum around for it).
I’m trying to locate these topics for you meanwhile…
Thanks for the links. Although I don’t quite understand why the queuing doesn’t work when Jack Transport is enabled. I would think that one would just queue the pattern like normal, and then call jack_transport_reposition when the time comes to switch to the new position. Would that not work?
Speculation: It looks to me like some of the problems are there because the multiple instance are “fighting” to control the transport state. Is that the reason? If so, would it help to have config options whether a Renoise instance should receive/send transport commands? The idea being, if only one instance sends transport start/stop/position changes, there would be no “fighting”.
I don’t know what exactly has been changed with 2.8 to fix a few existing Jack Transport problems. Only Taktik can provide the best answer here.
I guess for two sessions of Renoise, everything can be tuned to eachother, but that does not automatically mean this tuning solution will work out when Renoise has to work with other hosts across the Jack chain.
The most important part first, is figuring out a clever way to make Jack work because that still doesn’t seem to be working flawlessly.
Ok. I’ll hope that he reads this then. Maybe he can give some more insight.
Renoise’s Jack implementation seems more robust than most other apps I have used. For instance, when the server exits, many apps just crash with a silly “zombified” message - Renoise prompts you whether you want to reconnect to Jack or ALSA, which is what every app should do.
Relocating never happens instantly but !at least! takes 2 processing blocks. At least, because any client may cause relocation to halt until it’s ready to play (slow syn clients) and other reasons. To seamlessly continue playback at a different position this would be required.
Further there is no way to tell jack to relocate to a position at a given time, just like there is no way to set up loops.
We changed our Jack transport implementation for Renoise 2.8 to properly deal with such slow sync clients, never guessing how long relocations may take. Because of the reasons mentioned above and others there unfortunately is not much we can do to improve the syncing on our side.