On 09/19/2016 11:56 PM, Patrick Shirkey wrote: Ableton link is used to synchronize software and devices on a *LAN*. It basically broadcasts BPM and song-position to the *local* network. Link does not allow to synchronize devices on a WAN. The complete source code is free (GPLv2) you can read it, no strings attached. ciao, robin

On Tue, 20 Sep 2016 07:03:58 +0200, Patrick Shirkey wrote: Hi, yes, it's not cross platform enough. Audiobus and other iPad apps provide Ableton Link. Jack doesn't run on the iPad anymore, so there unlikely ever will be netjack available. It would be nice to be able to sync a tablet PC with the Linux DAW by wifi. AFAIK Linux based tablet PCs are still not real-time capable. I have no idea how good sync by wifi works, maybe MIDI by cable still is the better way to go. Regards, Ralf

So then the next question would be is there any reason NOT to integrate it directly into JACK? -- Patrick Shirkey Boost Hardware Ltd

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 01:25 PM, Robin Gareus wrote: jftr. there's these posted upstream: https://github.com/Ableton/link/pull/5 https://github.com/Ableton/link/pull/6 however, for the time being, this is only about adding example applications (linkhut, qlinkhut, etc.) with jack audio support, as in alternative to portaudio on linux. again for the time being, it has nothing to do with jack-timebase, at least yet, and for x sake, it probably won't do anything about jack-transport, which i believe is not applicable nor substitute i see each, jack-transport and ableton-link, as orthogonal in function and purpose. iow., an application either adopts jack-transport *or/and* ableton-link protocol (possibly through a jack-timebase proxy) to sync its "play time". afaiu. jack-tranpsort is about absolute sample/frame real-time positioning; otoh. ableton-link is about relative tempo, beat and/or phase (within a bar or measure) musical-time ie. it's better described as a shared *metronome* over the LAN (wether it's wired or wireless: low level is multicast udp/ip, so that it works on the local net segment switches but never across routers). iow. ableton-link is *not* a wall/word-clock for keeping media streams in sync. and it doesn't do WAN, so you can keep your tinfoil in the closet :). point is, applications using the ableton-link facility have to implement special, dedicated sync patterns, which are not bearable to a linear real-timeline, so to speak. it is best suited, or recommended, for syncing loopers on musical BBT and tempo (BPM) units, abstract time boundaries if i may, not to concrete linear/real-time stream players. on the practical side of thoughts, i mean, i'd say to scrap any jack-transport implementation on superlooper or seq24, for example. make those sync to ableton-link instead. hydrogen would have a great boost in usability too, i'm sure. though, old plain linear timeline based DAWs, eg. ardour, (or sequencers for that matter) qtractor, muse(score), rosegarden, etc. would be better still set to jack-transport as master/slave as usual, maybe set ableton-link tempo and beat/bar phases according to their rolling playback state, that is as long as to function as timebase masters. as a final note, and conclusive perhaps, ableton-link integration is an application/client option, not quite on the JACK server/service side if one. just my 2eur. -- rncbc aka. Rui Nuno Capela

Thanks, Paul and Rui, very interesting info. On Tue, Sep 20, 2016 at 5:08 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote: -- Louigi Verona http://www.louigiverona.com/

Thanks Patrick.

The people who designedand wrote Link are entirely familiar with JACK (if only because I taught them about it). I too was a bit disappointed when Link was announced (last Novemeber) because it seemed redundant given JACK transport. But once they released the SDK for iOS and later the code for all platforms, it became clear that the Link team has come up with something quite different, extremely useful and really rather clever. Even just their clear identification of different kinds of musical time sync is a huge contribution for those of us who think about such things. Ableton is actually full of quite a lot of software developers who are into open source. I don't know why there needs to be the level of disdain and skepticism for the company itself just because, like most other s/w development companies, they use a proprietary model. Their documentation for their Push2 surface is an exemplary example of how any company (even an open source one like Monome) should and could document a hardware device and how to interact with it. Likewise, their release of the Link SDK as GPL code for all platforms is a remarkably strong statement from a company whose core products are all released under proprietary licenses. On Tue, Sep 20, 2016 at 1:03 AM, Patrick Shirkey <pshirkey(a)boosthardware.com > > > On 09/19/2016 11:56 PM, Patrick Shirkey wrote: > >> > >>> why? > >>> > >>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <tito.01beta(a)gmail.com> > >>> >>> > >>>> What is the content of the network packets ? > >>>> > >>>> Regardless, I'll ignore software with that technologogy. > >>> > >> > >> The OP seems to be suggesting that whoever has access to the data > >> captured > >> by Ableton Link or the potential backdoor that link *might* enable would > >> use it for nefarious purposes. > > > > Ableton link is used to synchronize software and devices on a *LAN*. > > It basically broadcasts BPM and song-position to the *local* network. > > > > Because netjack isn't good enough or cross platform enough or LGPL enough > or adopted enough? > > > Link does not allow to synchronize devices on a WAN. > > > > The complete source code is free (GPLv2) you can read it, no strings > > attached. > > > > Be careful, apparently you might get brainwashed ;-) > > > -- > Patrick Shirkey > Boost Hardware Ltd > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev >

On Tue, Sep 20, 2016 at 9:46 AM, Patrick Shirkey <pshirkey(a)boosthardware.com Except .. they didn't. Not a very good guess, IMO. I don't think you've read enough about Link. It does stuff that JACK transport cannot do. It is designed around concepts that JACK doesn't have. Conflating JACK (transport) and Link is a mistake. I made it myself. I would suggest not doing that. I didn't give ableton any "expert advice". I was a guest professor 6 years ago who happened to be one of the people who taught some of the people who were later recruited by Ableton and ended up developing Link. And again, JACK does *not* do what Link does (nor vice versa).