paul davis was present during the unveiling of ableton sync and has an interesting perspective:
...The JACK community developed technology back in 2005 or earlier that could do what Link does (and a whole lot more besides). But the developers failed to package it, failed to make it usable for anyone other than a small group of tech-oriented tinkerers, failed to give it an inviting face. In addition, the developers failed to understand how significant platform is when trying to create products for people. Designing the most awesome thing in the world is no help if it doesn't run on the platforms that people want to use (for whatever reason). Ableton not only chose OS platforms with huge numbers of users, but has proceeded to develop its own product-centric platform that provides compelling reasons for users to want to remain within its walls. The open source community shouldn't be trying to follow or copy what a company like Ableton does, but there is a strong lesson here: our technology is not as important as we like to think.
In any case, one thing that we've talked about to various degrees in the past is tempo ramping in JACK, and with the announcement of ableton link I'd like to revisit the topic.
http://linuxmusicians.com/viewtopic.php ... 81&p=46912
http://linuxmusicians.com/viewtopic.php ... 90&p=51449
http://linuxmusicians.com/viewtopic.php ... 35&p=30447
JACK does indeed largely do what Link does (and more) but I've been having difficulty successfully tempo ramping. Incidentally, danboid recently posted about how he can successfully ramp in MuSE; but I don't use MuSE nor do I plan to in the near future, and unfortunately my attempts to change tempo dynamically within the greater JACK/modular LAU paradigm have been rather unsuccessful.
To clarify my own use-case, I'd like to map an encoder/knob to a tempo control and be able to speed up/slow down the tempo live, e.g. during a performance.
changing tempo as timebase master
For the most part it seems that changing tempo dynamically is possible but it is not well-defined.
* seq24 forces itself to be transport master (I know there's supposed to be a patch but it has still never worked for me ever) and disallows tempo changes while playing
* hydrogen sort of allows tempo changes but it will sometimes politely refuse to change (which is bad)
* klick can be configured to send out predefined tempo ramps but I haven't been able to set it as timebase master and actually interact with it (I was trying klick -Ti and klick -To 8080 but it seems -i and -o somehow disregard the -T option)
changing tempo as a slave
* hydrogen is happy to oblige tempo changes but is equally happy to cut off the beginning/end of a bar
* qmidiarp follows tempo changes but doesn't stay in time and forgets to send note-offs
I'd appreciate if someone more familiar with the transport spec could chime in on this, I'd like to understand what is missing from a technical perspective (I'm actually not entirely clear on the timebase master/slave relationship either).
Going a step further, it seems that ableton link may become the go-to replacement for midi clock in software-based production; it could be beneficial to discuss possible timebase master clock clients that can also communicate using the ableton link protocol. Of course this is contingent on the SDK being compatible with linux, which may be unlikely but they are encouraging interested developers to get in touch.
By the same token it would be great to have this for midi clock as well -- I know of jack_midi_clock already but I don't believe the reverse case exists, though falktx and I briefly discussed something related a while ago.
1. lau apps have to implement tempo ramping in JACK properly
2. a JACK timebase master clock client must be made that can
- change tempo dynamically
- communicate with ableton sync to send/receive tempo information (pending a working SDK for linux (this should also be optional for those who don't want anything proprietary))
- set tempo given a midi clock input
Thoughts? I think tempo syncing is one way we can get JACK to interact more proactively with other software/equipment, and that seems like it could be a great way to reconnect with the rest of the audio community.