Thomas Brand tom at trellis.ch
Tue Sep 20 17:19:50 UTC 2016

On Tue, September 20, 2016 17:03, Rui Nuno Capela wrote:
> On 09/20/2016 01:25 PM, Robin Gareus wrote:
>> Rui already has a working standalone prototype (no timebase support
>> yet, but it's a good start).
> 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.

Rui, thanks for this concise summary for the layz! It sounds like
something that's missing in Linux Audio land.

However looked from a distance, it's funny to see how things change. It
was for some people common practice to smile at ableton-like loop
facilities because it was looked at as something less favourable to
non-looped "real" music. Just to now explain why this new product from
ableton makes sense, after being sucked in at grandiose marketing events.
It's certainly well if that product is GPLed, independent of it being for
totally egoistic reasons of that company.

More information about the Linux-audio-dev mailing list