link

You’re probably so used to sync being broken that the first time you see Link, you might not believe what’s happening.

Link began its life as a research project and has turned into a full-fledged product from Ableton. But unlike Push or Live, Link itself isn’t something you buy. Instead, it’ll be built into software you use, and unlock seemingly magical wireless (or wired) sync.

The upshot: the electronic jam session is about to get a whole lot easier. And with a beta out today, that’s not some unknown future. It’s right now.

Ableton has their own demo video, but maybe the easiest way to see what’s happening is to watch a trio of iOS gadgets running Elastic Drums, as prepared by my friend (developer of this app) Oliver Greschke:

Now, what isn’t in this video is about as important as what is. There aren’t any wires. And there isn’t even a copy of Ableton Live running. This is a peer-to-peer jam session between three gadgets over a wireless network.

Also, any one of the devices can speed up or slow down. There’s not a “master” or “slave” (erm, “host” and “client” to sound less creepy). Everything is effectively democratic.

That makes a big difference, because it works nicely in a jam session. Musicians can join in or drop out at will. Anyone can change the tempo. Now, you probably don’t want to get too democratic about tempo changes, but that means you can easily hand off roles. And wifi sync is important, too, because it means you don’t have to get tangled in wires just to get going.

The use cases are pretty broad. Two producers working together can bring their own laptops running Ableton Live to a studio session or sync up onstage. Running an iPhone along an iPad, or an iPad along a computer, becomes more useful even with just one person. And forming impromptu electronic bands is at last something anyone can do, not just the occasional specialized laptop orchestra.

I can tell you it all works really, really well. We’ll have more to say about this.

There’s still a place for wired MIDI (or analog sync, for that matter), because so much gear requires it. But even in those situations, Link can help, by making the software bits work together (and then driving hardware off a computer or iOS device as the clock). KORG even has an app that can sync to hardware like their volcas (SyncControl).

I asked the developers of Link some questions about how this will work, anticipating what I thought readers would want to know. It seems the questions made sense, as some were apparently incorporated into the official Ableton FAQ (below). But here are some starting points:

CDM: What information is exchanged in Link?

Ableton: Link currently provides tempo sync and a grid to which apps can align. There are no Song Position or Start/Stop messages sent via Link.

Ed.: This is actually an interesting point. Think of it as synchronizing to a pulse rather than to a place in the song. So, in Ableton’s Session View, that’s easy to understand – you sync to the current quantize level of a bar or beat, etc.

What does it mean when you say all users are equal? What happens if people pull in different directions? What if someone stops the transport?

a) There will be a “tempo fight” and the winner will be the app that last changes the tempo.
b) Anyone can start and stop their part while the others keep playing.

What will developers get with the iOS SDK? They’re free to then use that in their apps?

a) Developers will receive the iOS SDK that comes with a pre-built library compatible with iOS8 and above and a simple example app for demonstration and testing purposes.
b) Developers who receive the SDK may integrate it into their apps free of charge.

What form does the SDK take? Will we see desktop versions? Is it possible for someone to create a port for a platform themselves – like Android or mobile Windows devices, for instance?

Initially and apart from Ableton Live, Link will be only available for iOS apps.

Ed.: Now, obviously, I think a lot of us hope that will grow. Android isn’t exactly exploding as a platform yet, but would still be welcome – and other desktop apps would be really valuable. I’d love to use Link to sync Ableton Live and Traktor or Serato, for instance, and I’m sure so would a lot of you. But this starting point should still keep us busy – and you can always then send clock to one of those other apps.

What’s necessary to license the Link name?

We license the name along with the SDK. Developers can use the Link name according to our brand guidelines, which we provide with he Link SDK.

When can we expect the SDK and beta – and they’ll be in that order?

A Live Beta version with Link is now available for everyone who wants to become a Live Beta tester.

What happens as wifi networks get crowded or signal gets weak?

If the network gets too crowded, apps can lose connection. However, it takes an extreme amount of Link users to cause this to happen.

Ed.: Link can also use an Ethernet connection if you have one.

linking

Learn more. For a complete set of FAQs, check:

https://www.ableton.com/en/help/link/getting-started/article/link-faq/

Get started. Try the beta:
https://www.ableton.com/en/beta/

Find apps. Check the bottom of the Link page for iOS apps already coming to the platform (though obviously even more will follow):
https://www.ableton.com/en/link/

Previous post

Flesh from Tim Exile transforms sounds into performances [Interview]

Next post

Watch techno made entirely with physical, mechanical objects

  • Dubby Labby

    More or less the protocol developed for the bridge opened to network… It isn’t OSC enough with its timestamp timecode and delayed messaging?
    In other hand the newcoming bomebox is getting new possibilities due its scripting cappabilities (implementing some kind of Sync standalone router box P2P) and ethernet/midi din/usb host ports…

    Next? Appletv av apps with link integration (vj ones could be amazing)… Just sayin’

    • Actually, no, as far as I know this has nothing to do with the engineering done for The Bridge. (though The Bridge did have some impact on Ableton’s internal sync engine)

      Bomebox, cool, though… yes, also kind of unrelated. 😉 Still, would be nice if this opened up a desktop SDK.

      • Dubby Labby

        As far as someone check inside the Serato Remote Scripts the coincidences emerge but I’m try to explain myself a bit better instead of make an wrong assumption…

        [quote]CDM: What information is exchanged in Link?

        Ableton: Link currently provides tempo sync and a grid to which apps can align. There are no Song Position or Start/Stop messages sent via Link.[/quote]

        This is how the internal protocol developed for the bridge worked. It had start, stop of course but you should “load” an special track to Serato which sent these “grid” from the turntable control directly avoiding transcodification (aka midi or osc) from pure “serial” messaging (and protocol baudrate dependencies).
        I understand Link goes a bit further with networking implementation (wifi or ethernet) but if it is a “from scratch (joke inside) development” it seems a bit redundant to me because the seed was planted far ago.

        In my eyes (coming back with pure imagination) it seems a failed technology recycled for new iteration (and mixed Bitwig SHARE also failed feature dropped from Live 8.2.5) and I hope Serato could get profit of LINK and give their forgotten users a second chance. All this isn’t news… are old revamped.

        Meanwhile I expect Gàbor to implement it the first as he did with NI Stems and Bome release to see the full possibilities. Everyday goes I lost more interest in desktop (ableton, max7…) and search in iOS/tvOS possibilities. Only Traktor keeps me in desktop domain…

  • Dubby Labby

    More or less the protocol developed for the bridge opened to network… It isn’t OSC enough with its timestamp timecode and delayed messaging?
    In other hand the newcoming bomebox is getting new possibilities due its scripting cappabilities (implementing some kind of Sync standalone router box P2P) and ethernet/midi din/usb host ports…

    Next? Appletv av apps with link integration (vj ones could be amazing)… Just sayin’

    • Actually, no, as far as I know this has nothing to do with the engineering done for The Bridge. (though The Bridge did have some impact on Ableton’s internal sync engine)

      Bomebox, cool, though… yes, also kind of unrelated. 😉 Still, would be nice if this opened up a desktop SDK.

      • Dubby Labby

        As far as someone check inside the Serato Remote Scripts the coincidences emerge but I’m try to explain myself a bit better instead of make an wrong assumption…

        [quote]CDM: What information is exchanged in Link?

        Ableton: Link currently provides tempo sync and a grid to which apps can align. There are no Song Position or Start/Stop messages sent via Link.[/quote]

        This is how the internal protocol developed for the bridge worked. It had start, stop of course but you should “load” an special track to Serato which sent these “grid” from the turntable control directly avoiding transcodification (aka midi or osc) from pure “serial” messaging (and protocol baudrate dependencies).
        I understand Link goes a bit further with networking implementation (wifi or ethernet) but if it is “from scratch (joke inside) development” it seems a bit redundant to me because the seed was planted far ago.

        In my eyes (coming back with pure imagination) it seems a failed technology recycled for new iteration (and mixed Bitwig SHARE also failed feature dropped from Live 8.2… freezer edition) and I hope Serato could get profit of LINK and give their forgotten users a second chance. All this isn’t news… are old revamped.

        Meanwhile I expect Gàbor to implement it the first as he did with NI Stems and Bome release to see the full possibilities. Everyday goes I lost more interest in desktop (ableton, max7…) and search in iOS/tvOS possibilities. Only Traktor keeps me in desktop domain…

        edit: Ableton erased all the Share videos from its site and youtube channels but anyone interested (and not so old to remember it) could check what I’m talking about in this link.
        http://blog.macformusicians.com/2010/07/01/live-share/

  • Zambari Owszem

    One thing bothers me a bit – Link does not currently allow for the clock to be offset. That means that if a device has a longer audio processing chain (i.e. external effector, or going through yet another computer for processing/mixing) it will be delayed relative to the master clock.

    • I believe actually that latency compensation though would impact the timing of all connected devices.

      Remember, there is no master clock. 😉

      • Zambari Owszem

        Think MIDI clock in its current state. You can shift the clock output (which you certainly won’t be able to do with Link) but you can also shift on the input, and I can’t see why that shouldn’t be possible.

        All the devices can mantain a common, shared concept of time, but any single device can, on its own, decide to start producing sound a tiny bit earlier relative to the … um… master.

    • Zambari Owszem

      To make the issue more clear with a use case:
      Imagine you are jamming with your mate, you don’t have a mixer but you have spare inputs on your soundcard. Your mate connects to your input, which happens to be an old, poorly supported usb card which needs 15ms of input and 15ms of output latency to work without glitches. Live knows about your 15ms output latency (assuming it is correctly reported by the driver), and it tries to produce your output in advance, so it would output in sync with your mate’s soundcard. But his output is now delayed by 30ms relative to yours!

      • Neil

        Couldn’t you just fix this using the track delay in Live?

        • Zambari Owszem

          I guess technically I could, but that would introduce additional latency on that second machine – which is avoidable if, insead, first machine knew to play ahead of time, problem would be solved in a more elegant way, but thanks for suggestion

          • Will

            “Technically” only for apps that have a think like track delay. An iOS synth app isn’t going to have this.

  • Zambari Owszem

    One thing bothers me a bit – Link does not currently allow for the clock to be offset. That means that if a device has a longer audio processing chain (i.e. external effector, or going through yet another computer for processing/mixing) it will be delayed relative to the master clock.

    • I believe actually that latency compensation though would impact the timing of all connected devices.

      Remember, there is no master clock. 😉

      • Zambari Owszem

        Think MIDI clock in its current state. You can shift the clock output (which you certainly won’t be able to do with Link) but you can also shift on the input, and I can’t see why that shouldn’t be possible.

        All the devices can mantain a common, shared concept of time, but any single device can, on its own, decide to start producing sound a tiny bit earlier relative to the … um… master.

    • Zambari Owszem

      To make the issue more clear with a use case:
      Imagine you are jamming with your mate, you don’t have a mixer but you have spare inputs on your soundcard. Your mate connects to your input, which happens to be an old, poorly supported usb card which needs 15ms of input and 15ms of output latency to work without glitches. Live knows about your 15ms output latency (assuming it is correctly reported by the driver), and it tries to produce your output in advance, so it would output in sync with your mate’s soundcard. But his output is now delayed by 30ms relative to yours!

      • Neil

        Couldn’t you just fix this using the track delay in Live?

        • Zambari Owszem

          I guess technically I could, but that would introduce additional latency on that second machine – which is avoidable if, insead, first machine knew to play ahead of time, problem would be solved in a more elegant way, but thanks for suggestion

          • Will

            “Technically” only for apps that have a think like track delay. An iOS synth app isn’t going to have this.

  • Rebelion Drones

    it is a shame that with no reason Apple removed the password option for ad-hoc networks. why did they do that?

    • It is a shame, but I like using a separate dedicated router anyway.

    • foljs

      Did they remove it? I still have it and I’m on the latest OS. Maybe it’s tied to carrier settings, because for a while the local carrier here demanded it was only activated for users in a special contract (I’m talking about ad-hoc wi-fi networks via tethering of your 3/4G signal).

  • Rebelion Drones

    it is a shame that with no reason Apple removed the password option for ad-hoc networks. why did they do that?

    • It is a shame, but I like using a separate dedicated router anyway.

    • foljs

      Did they remove it? I still have it and I’m on the latest OS. Maybe it’s tied to carrier settings, because for a while the local carrier here demanded it was only activated for users in a special contract (I’m talking about ad-hoc wi-fi networks via tethering of your 3/4G signal).

  • Robin Parmar

    Why don’t people: a) Just use OSC and b) make things compatible with different platforms. There’s absolutely no reason a protocol can’t be platform agnostic. Back in my day, that was the whole point.

    • Zambari Owszem

      OSC supports timestamps for events, but it is very generic in nature, has no common, universally accepted namespace, no provision for clock signals, and is uni-directional. It has broadcast but all the actuall syncing would have to be built on top of it anyways. I don’t think it suits the problem at hand very welll.
      Link on the other hand seems to do one thing well and effortless, with heavy lifting like compensating for jitter burried in the SDK

      • Robin Parmar

        OSC could be used as the basis for a more restrictive protocol, with an agreed-upon namespace etc. My point is: why re-invent the wheel? Oh yeah, corporations.

        • This project began as a research project before any corporation was involved. “OSC” doesn’t provide an obvious technique for doing this. Yes, it provides timestamps underneath, but while that’s a building block for this sort of work, it’s only the first step.

          And, frankly, if OSC hasn’t gone anywhere, it’s because no one has done the necessary work to make it a usable standard for a lot of the use cases people want.

          I love that, consistently, “OSC” is proposed as a solution without any real understanding of what actually making a finished solution really entails.

          • Dubby Labby

            The work of Fabriccio Poce is not a solution for networking abletons?
            Ok. I see the good things in Link but OSC is well documented and open to anyone interested in contribute.
            The irony becomes when the remote surface scripting inside Ableton was “inspired” by assembla python scripts developed to comunicate with… OSC! (and monomes)

        • foljs

          “””My point is: why re-invent the wheel?”””

          Because that new “more restrictive protocol, with an agreed-upon namespace” would also be a new wheel.

          And because they don’t care about the overhead of having to implement on top of OSC, when they just need a very simple functionality (basically just sync).

          • Zambari Owszem

            I don’t know the implementation details, but I have a feeling that they might be doing more work here than meets the eye. OSC, apart from being a signalling protocol, would require building quite a lot on top of itselt to reliably sync multi-master audio environments, and without a pre-written SDK (and a standard way of handling certain situations) you could very quickly end up in a situation where you would have an open standard that works sometimes, between some aps, but not that well beween others. Instead Ableton gusy are aiming to give us a proprietary standard that works always. Which is far better in my opinion.

            Yes, they could use OSC but that would give a fake impression of ‘great I can parse this message, means I am synced now’, and lame implementations can damage the ‘just works’ effect.

    • dabravanel

      OSC is a great protocol for those who can/will take the time to learn its ins and outs – or will spend money on programs like OSCulator. Otherwise, it’s nowhere near as simple as MIDI, and certainly not anywhere near as easy and immediate as Link. The point of Link is that you don’t need to think about it – you just start the apps and go, focusing on the music.

      Again, this isn’t to discourage OSC; but for syncing tasks like these, Link is VERY welcome and blazing a new trail – especially when it comes to bi-directional communication.

      • PaulDavisTheFirst

        Link isn’t blazing a new trail. It is doing something that could be done with JACK 10 years ago. We just failed to properly package and market JACK (or even specifically JACK transport) for actual users. I would prefer to live in a world where proper marketing and packaging doesn’t count as blazing a trail, but your mileage may vary.

        • foljs

          “””Link isn’t blazing a new trail. It is doing something that could be done with JACK 10 years ago. “””

          Yeah, only in a way and with devices and OSes that the majority of people making music actually care about.

          • PaulDavisTheFirst

            (1) I made the exact point as you. Also, it is Apple, and nobody else, that made JACK on iOS impossible. Until they decided to mess around with shared memory APIs, JACK was running on iOS and even had a GUI that “the majority of people making music” might have cared for.

            (2) I wasn’t being condescending about packaging or marketing. It has taken me many years to realize it, but I do now see the importance for users of getting this side of things right. It is just a little frustrating when stuff gets labeled as “blazing a new trail” when it is really just “getting this side of things right”. Letting people know about what you’ve done, and making it easy to use, are equally (and perhaps more) important than the technology itself.

          • foljs

            (1) Yeah, though it was a generic policy IIRC, not targeted to JACK specifically. Couldn’t JACK adapt to still work on iOS the way Audio-bus can (since it’s closer to that, transfering audio etc, than merely syncing like Link)? Or it would need to take it far outside its design/architecture?

            (2) Agree. It’s like with most things though, people tend to know more those that first brought them to their lives, rather than those that initially created the technologies/concept. E.g. how many know Doug Engelbart compared to Jobs/Gates?

          • Will

            Funny. I was reading this thread and thinking about Engelbart:Jobs.

            “Just Works” is absolutely a feature. And if it’s but the newest feature a top a history of feature making, it’s still worth noting.

  • Robin Parmar

    Why don’t people: a) Just use OSC and b) make things compatible with different platforms. There’s absolutely no reason a protocol can’t be platform agnostic. Back in my day, that was the whole point.

    • Zambari Owszem

      OSC supports timestamps for events, but it is very generic in nature, has no common, universally accepted namespace, no provision for clock signals, and is uni-directional. It has broadcast but all the actuall syncing would have to be built on top of it anyways. I don’t think it suits the problem at hand very welll.
      Link on the other hand seems to do one thing well and effortless, with heavy lifting like compensating for jitter burried in the SDK.

      And the protocol is likely to be simple enough to be reverse-engineered. I expect there to be 3rd party support by the end of this week (unless they made it hard on purpose, which I doubt), although Ableton owns the trademark.

      • Robin Parmar

        OSC could be used as the basis for a more restrictive protocol, with an agreed-upon namespace etc. My point is: why re-invent the wheel? Oh yeah, corporations.

        • This project began as a research project before any corporation was involved. “OSC” doesn’t provide an obvious technique for doing this. Yes, it provides timestamps underneath, but while that’s a building block for this sort of work, it’s only the first step.

          And, frankly, if OSC hasn’t gone anywhere, it’s because no one has done the necessary work to make it a usable standard for a lot of the use cases people want.

          I love that, consistently, “OSC” is proposed as a solution without any real understanding of what actually making a finished solution really entails.

          • Dubby Labby

            The work of Fabriccio Poce is not a solution for networking abletons?
            Ok. I see the good things in Link but OSC is well documented and open to anyone interested in contribute.
            The irony becomes when the remote surface scripting inside Ableton was “inspired” by assembla python scripts developed to comunicate with… OSC! (and monomes)

        • foljs

          “””My point is: why re-invent the wheel?”””

          Because that new “more restrictive protocol, with an agreed-upon namespace” would also be a new wheel. What benefit would it have apart from forcing them to work it on top of OSC? It would still need the same adoption itself.

          And perhaps because they don’t care about the overhead of having to implement on top of OSC, when they just need a very simple functionality (basically just sync).

          • Zambari Owszem

            I don’t know the implementation details, but I have a feeling that they might be doing more work here than meets the eye. OSC, apart from being a signalling protocol, would require building quite a lot on top of itselt to reliably sync multi-master audio environments, and without a pre-written SDK (and a standard way of handling certain situations) you could very quickly end up in a situation where you would have an open standard that works sometimes, between some aps, but not that well beween others. Instead Ableton gusy are aiming to give us a proprietary standard that works always. Which is far better in my opinion.

            Yes, they could use OSC but that would give a fake impression of ‘great I can parse this message, means I am synced now’, and lame implementations can damage the ‘just works’ effect.

          • Open standard please ableton.. It works great on my ipad, first thing I want to do is to start writing code for an implementing this for a euro rack module.. Would really be a shame if this is to be limited to ios+live.

            I guess I could start reverse engineering the protocol, I’m guessing the wire part isn’t that complicated.. In general link shouldn’t differ a lot from other types of network time synchronisation techniques. ( https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_synchronization_algorithm and others )

          • theres already at least one rev eng project started https://github.com/westhom/AbletonLinkProtocol

    • dabravanel

      OSC is a great protocol for those who can/will take the time to learn its ins and outs – or will spend money on programs like OSCulator. Otherwise, it’s nowhere near as simple as MIDI, and certainly not anywhere near as easy and immediate as Link. The point of Link is that you don’t need to think about it – you just start the apps and go, focusing on the music.

      Again, this isn’t to discourage OSC; but for syncing tasks like these, Link is VERY welcome and blazing a new trail – especially when it comes to bi-directional communication.

      • PaulDavisTheFirst

        Link isn’t blazing a new trail. It is doing something that could be done with JACK 10 years ago. We just failed to properly package and market JACK (or even specifically JACK transport) for actual users. I would prefer to live in a world where proper marketing and packaging doesn’t count as blazing a trail, but your mileage may vary.

        • foljs

          “””Link isn’t blazing a new trail. It is doing something that could be done with JACK 10 years ago. “””

          Yeah, only in a way and with devices and OSes that the majority of people making music actually care about.

          “”” I would prefer to live in a world where proper marketing and packaging doesn’t count as blazing a trail, but your mileage may vary.”””

          I don’t care about marketing, but what you write off condescendingly as “packaging” is the whole experience of using a product or technology, from the ease to setup to it being available in the popular favorite music apps and plugins that people actually use.

          • PaulDavisTheFirst

            (1) I made the exact point as you. Also, it is Apple, and nobody else, that made JACK on iOS impossible. Until they decided to mess around with shared memory APIs, JACK was running on iOS and even had a GUI that “the majority of people making music” might have cared for.

            (2) I wasn’t being condescending about packaging or marketing. It has taken me many years to realize it, but I do now see the importance for users of getting this side of things right. It is just a little frustrating when stuff gets labeled as “blazing a new trail” when it is really just “getting this side of things right”. Letting people know about what you’ve done, and making it easy to use, are equally (and perhaps more) important than the technology itself.

          • foljs

            (1) Yeah, though it was a generic policy IIRC, not targeted to JACK specifically. Couldn’t JACK adapt to still work on iOS the way Audio-bus can (since it’s closer to that, transfering audio etc, than merely syncing like Link)? Or it would need to take it far outside its design/architecture?

            (2) Agree. It’s like with most things though, people tend to know more those that first brought them to their lives, rather than those that initially created the technologies/concept. E.g. how many know Doug Engelbart compared to Jobs/Gates?

          • Will

            Funny. I was reading this thread and thinking about Engelbart:Jobs.

            “Just Works” is absolutely a feature. And if it’s but the newest feature a top a history of feature making, it’s still worth noting.

  • Tal Kirshboim

    This is great and exciting news. However stating that “Android isn’t exactly exploding as a platform yet” is maybe true in the audio app domain, but in many other ways it is exploding and is generally a much more popular platform than iOS..
    I was also wondering why there is no mention of the SyncJams project that has a similar goal and is platform agnostic. Any comment about or comparison to it would be very interesting to read. Thanks!

    • Frikandel

      Android OS lacks a realtime kernel. This is a problem in applications where timing is critical… audio latency needs to be low and consistent. Android also suffers from OS fragmentation and inconsistent hardware.

      • Tal Kirshboim

        While some of this is true, still most of the modern mobile devices in the world run on Android.. For a product that is addressing mobile devices, it’s surprising that Android support is not planned. I can imagine apps that could benefit from this technology even if their audio latency is not very low. The issues you mention here make it a problem harder to solve than supporting iPhones only, but still possible..

        • lala

          Its very simple, android is a nightmare for developers of music apps. No-one will buy 200 phones and stuff to test things out. Most of the devices don’t run the latest OS and never will.

          • lala

            so its lets say its 200 phones * 5 OS versions = 1000 absurd combinations, you see where this is leading

          • lala

            and there is so little going on with music apps on android, it would be a waste of time

    • foljs

      “”” but in many other ways it is exploding and is generally a much more popular platform than iOS..”””

      Not on the pro use tiers, mostly on the “cheap device bundled with contract” tiers.

  • Tal Kirshboim

    This is great and exciting news. However stating that “Android isn’t exactly exploding as a platform yet” is maybe true in the audio app domain, but in many other ways it is exploding and is generally a much more popular platform than iOS..
    I was also wondering why there is no mention of the SyncJams project that has a similar goal and is platform agnostic. Any comment about or comparison to it would be very interesting to read. Thanks!

    • Frikandel

      Android OS lacks a realtime kernel. This is a problem in applications where timing is critical… audio latency needs to be low and consistent. Android also suffers from OS fragmentation and inconsistent hardware.

      • Tal Kirshboim

        While some of this is true, still most of the modern mobile devices in the world run on Android.. For a product that is addressing mobile devices, it’s surprising that Android support is not planned. I can imagine apps that could benefit from this technology even if their audio latency is not very low. The issues you mention here make it a problem harder to solve than supporting iPhones only, but still possible..

        • lala

          Its very simple, android is a nightmare for developers of music apps. No-one will buy 200 phones and stuff to test things out. Most of the devices don’t run the latest OS and never will.

          • lala

            so its lets say its 200 phones * 5 OS versions = 1000 absurd combinations, you see where this is leading

          • lala

            and there is so little going on with music apps on android, it would be a waste of time

    • foljs

      “”” but in many other ways it is exploding and is generally a much more popular platform than iOS..”””

      Not on the pro use tiers, mostly on the “cheap device bundled with contract” tiers.

  • pinta_vodki

    I wonder how well it would work for providing wireless click tracks at a practice gig for example. With one person playing controlling Live and a drummer or guitarist syncing to a metronome on their iPhone.

  • pinta_vodki

    I wonder how well it would work for providing wireless click tracks at a practice gig for example. With one person playing controlling Live and a drummer or guitarist syncing to a metronome on their iPhone.

  • josephguisti

    The question I thought everyone would be asking: what does this mean for ableton’s current, notoriously wonky midi sync? Nothing?
    That would make the most sense, as this is about Link and not about midi. But if it works via Ethernet and some midi interfaces like iconnect4+ have Ethernet…hmmm

  • josephguisti

    The question I thought everyone would be asking: what does this mean for ableton’s current, notoriously wonky midi sync? Nothing?
    That would make the most sense, as this is about Link and not about midi. But if it works via Ethernet and some midi interfaces like iconnect4+ have Ethernet…hmmm

  • Polite Society

    Keen to see how this works in regards to midi and other hardware.
    Not a live user, but I love the concept of being able to connect to a bunch of friends with ipads and have a jam on our respective apps relatively easily, and it would be great to supplement that with other hardware without it being the cluster of connectors and adapters it can often turn into right now.

  • Polite Society

    Keen to see how this works in regards to midi and other hardware.
    Not a live user, but I love the concept of being able to connect to a bunch of friends with ipads and have a jam on our respective apps relatively easily, and it would be great to supplement that with other hardware without it being the cluster of connectors and adapters it can often turn into right now.

  • The only thing that’s rather weird is to call this protocol Link. That’s a bummer for search engines. Other than that: super nice!

  • The only thing that’s rather weird is to call this protocol Link. That’s a bummer for search engines. Other than that: super nice!

    • Zambari Owszem

      you could argue that Live isn’t much better

  • Freeks

    Would like to try Link, but none of my iOS apps support it. Maybe in the future…

  • Freeks

    Would like to try Link, but none of my iOS apps support it. Maybe in the future…

  • zelda

    Nice new CDM design, btw !

  • zelda

    Nice new CDM design, btw !

  • Will

    Good stuff, Mr. Kirn. In case the month-of-ableton continues, I’d be interested to know more about these things…

    Any insight into why this is iOS only? I get the Android/Windows Phone technical problems. But Windows and OS X (both platforms that support Abelton)? Just limiting scope for the initial launch? Platform competitive advantage? I’m an iOS user so no personal sweat here, I’m just interested.

    On that note, what about hardware access to the SDK? Is this tech a cheap wifi antenna away from being integrated into hardware devices? I could see this landing in the Korg Volca Mixer/Sync distributor box some have been dreaming of. Or an Elektron box. Or Eurorack module with clock dividers…

    I’m looking forward to learning how Link works with SPP. I totally get that this is going to be great for jamming and loop based music but what about integrating that sort of stuff into timelines? Obviously, MIDI will continue to work while Link is running but how is that going to work specifically with something like SPP? I don’t know much about the tech behind SPP (like, is it possible to send it *without* clock messages—just start, stop, continue and current location?).

    Also looking forward to seeing something like: two devices with Link, each connected to a a hardware beatbox via MIDI. How well do all 4 (two software and two hardware devices) stay in sync? Can one of the software devices be a MIDI clock slave to the beat box, have its clock changed by adjusting the tempo on the beatbox directly and then propagate that change across Link to software box 2 and beatbox 2?

    iOS is going to offer app-to-app Link syncing on the same device. Is this the eventual plan for desktop apps?

    • Zambari Owszem

      As far as antennas go, the biggest issue is ‘how do you program a device to connect to a given network, with a given password’. Its kinda hard to input that information into a hardware box. SysEx? Having open networks on stage is not a possibility.

      Regarding you sync scenario, I see it like this: From each respective hardware beatbox point of view, the Live to which it is connected is the MIDI master, which it has to sync to – nothing is changing in that departament – hardware doesn’t have a way to be aware of Link status, machines sync to their local Live. And on top of that we have another layer, Link, which sort of slaves both Live instances to its agreed time.

      Song Position Pointer is just going to be ignored I think (every instance can be looping a different section of its arrangement for example).

  • Will

    Good stuff, Mr. Kirn. In case the month-of-ableton continues, I’d be interested to know more about these things…

    Any insight into why this is iOS only? I get the Android/Windows Phone technical problems. But Windows and OS X (both platforms that support Abelton)? Just limiting scope for the initial launch? Platform competitive advantage? I’m an iOS user so no personal sweat here, I’m just interested.

    On that note, what about hardware access to the SDK? Is this tech a cheap wifi antenna away from being integrated into hardware devices? I could see this landing in the Korg Volca Mixer/Sync distributor box some have been dreaming of. Or an Elektron box. Or Eurorack module with clock dividers…

    I’m looking forward to learning how Link works with SPP. I totally get that this is going to be great for jamming and loop based music but what about integrating that sort of stuff into timelines? Obviously, MIDI will continue to work while Link is running but how is that going to work specifically with something like SPP? I don’t know much about the tech behind SPP (like, is it possible to send it *without* clock messages—just start, stop, continue and current location?).

    Also looking forward to seeing something like: two devices with Link, each connected to a a hardware beatbox via MIDI. How well do all 4 (two software and two hardware devices) stay in sync? Can one of the software devices be a MIDI clock slave to the beat box, have its clock changed by adjusting the tempo on the beatbox directly and then propagate that change across Link to software box 2 and beatbox 2?

    iOS is going to offer app-to-app Link syncing on the same device. Is this the eventual plan for desktop apps?

    • Zambari Owszem

      As far as antennas go, the biggest issue is ‘how do you program a device to connect to a given network, with a given password’. Its kinda hard to input that information into a hardware box. SysEx? Having open networks on stage is not a possibility.

      Regarding you sync scenario, I see it like this: From each respective hardware beatbox point of view, the Live to which it is connected is the MIDI master, which it has to sync to – nothing is changing in that departament – hardware doesn’t have a way to be aware of Link status, machines sync to their local Live. And on top of that we have another layer, Link, which sort of slaves both Live instances to its agreed time.

      Song Position Pointer is just going to be ignored I think (every instance can be looping a different section of its arrangement for example).

  • c016smith

    @peter kirn, I completely agree about the future hope to use Link to sync with external apps (not just iOS) such as Traktor. Seems like this could be a good way to hot-swap between DJs using Traktor vs Ableton rigs, between sets, if not even allowing collaboration between DJs and performers with different gear and workflows, i.e. Traktor vs Ableton Live vs any other live instrumentalist using iOS apps as their synth platform or whatever. Great article and discussion! Thanks

  • c016smith

    @peter kirn, I completely agree about the future hope to use Link to sync with external apps (not just iOS) such as Traktor. Seems like this could be a good way to hot-swap between DJs using Traktor vs Ableton rigs, between sets, if not even allowing collaboration between DJs and performers with different gear and workflows, i.e. Traktor vs Ableton Live vs any other live instrumentalist using iOS apps as their synth platform or whatever. Great article and discussion! Thanks