20 Sep
2016
20 Sep
'16
2:25 p.m.
On 09/20/2016 01:40 PM, Patrick Shirkey wrote:
There's an existing feature request already: [1]
JACK cannot be slaved to anything. jackd is always master, so there's a
conceptual conflict.
Closest concept is jack-timebase master [2]. A client can provide
musical-time to jack and thereby to all jack clients that support jack
transport.
So yes, there are some reasons to not *directly* integrate it, but like
existing jack tools [3] (jack_lsp, jack_connect, jack_transport,...) it
could be included with jack one way or another. Seamless integration is
possible. It just needs someone to do the work.
Rui already has a working standalone prototype (no timebase support yet,
but it's a good start).
There are also some technical details to be sorted out: e.g. the current
Link reference implementation requires C++11, jack-tools are C89... but
those are details.
Cheers!
robin
[1] https://github.com/jackaudio/jack2/issues/231
[2] http://jackaudio.org/files/docs/html/group__TransportControl.html
[3] https://github.com/jackaudio/tools
On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
So then the next question would be is there any reason NOT to integrate it
directly into JACK?
Because netjack isn't good enough
correct.
jack can have a single timebase master and likewise netjack has a single
net-master.
Ableton-Link is decentralized: Multiple performers can interact with
each other on an equal level (no master/slave semantics).
It's not groundbreaking tech. Laptop orchestras and the likes have used
similar techniques since a while, but all prior-art that I know is ad-hoc.
As far as I know this is the only protocol concerning *musical-time*
that's spec'ed out, has a cross-platform reference implementation and
potential to find its way into hardware.
Feel free to criticize the protocol on a technical level or hunt for
bugs in the implementation ... or simply ignore it silently.