Finally, route audio, MIDI, sync, and data between apps however you like - one solution, free.

Finally, route audio, MIDI, sync, and data between apps however you like – one solution, free.

iOS now offers lots of options for using apps together, but – that’s part of the problem. The solutions are piecemeal. There’s inter-app MIDI. There’s Audiobus, which does audio, but requires the purchase of a separate app. Then you need something else for sharing data. And something else for sync. Confused yet? (Hey, it’s easy, just remember: Audiobus, WIST, AudioCopy, AudioPaste, Core MIDI and inter-app MIDI, and… yeah.)

By the time you’re done, you’ve actually had to buy new apps just to get things working together, and you have a number of different technologies just to do some basic things you might expect would be intuitive.

JACK adds yet another technology to this picture, but it might also bring relief. It’s free – no cost to download on iOS, and based on the free and open source JACK on Mac, Windows, and Linux. You can get it right now. It does, its developers say, everything: audio, MIDI, sync, and data sharing in any arbitrary combination you like. It’s high performance, both optimized for efficient processing and low latency. And encouraging adoption, the SDK is available to all developers; you don’t even have to fill out a form first.

That’s not to say JACK faces an easy battle into the iOS ecosystem. The user interface is powerful, yes, but some users may not grasp dragging connections between apps quite as easily as Audiobus’ dead-simple (though much less flexible) routing. Mainly, there’s the matter of timing: iOS users (and developers) may at this point have so much fatigue with all these solutions that anything new is likely to face resistance, no matter how good it is.

But if JACK can deliver what it’s promising on iOS, it looks really, really, really good. And it’s one solution for sharing data, audio, MIDI, and sync. That sets it apart from everything that came before. So, the choice is either lots of solutions, each put up by individual developers, based on ad-hoc solutions to components of the problem, or one existing, open standard that does everything. I think a number of developers and users will be testing this in the hope that the latter can work.

Here’s what’s encouraging: right now, you can look at that code that would add JACK support, and download the SDK without convincing someone to let you do so. And I don’t doubt that you could add this support in under an hour as the site claims. (Developers: you can release commercial apps, as they’ve released this iOS version under special license terms, not the GPL, which is problematic on iOS and, potentially, for commercial use.)

Update: Audiobus released its SDK publicly yesterday, an indication of just how fast this scene is moving. The documentation is copious and comes with loads of sample projects and the like:

The Audiobus developers have done an exceptional job, and I think they create a strong incentive for Audiobus support – and have the momentum. However, it is worth saying as a developer, implementing JACK support is actually vastly easier than implementing Audiobus support. In fact, the API is very similar to our API for libpd, the open source embeddable Pure Data engine – partly because libpd’s audio API was modeled on a simplified JACK API (though that’s a long story).

Both give developers a bunch of functionality, and almost no particular license obligation, for free. The answer to the question, “will some developers support all of the above and see what sticks?” Yes, probably. But it is worth saying: JACK does a lot more, and the amount of code you have to add it almost comically trivial. Some developers have probably already spent more time reading this article or replying to comments than it’d take to do.

The project description from the developer reads almost like a manifesto:

JACK is more than just one iOS app. It is a system that connects the music and audio world on your iOS device. JACK allows audio channels and MIDI ports of your audio & music apps to be connected with each other. It does not force a predefined schema in which way apps shall be connected with each other. You can freely connect them in any way you want, intuitively like drawing on a paper. Besides audio & MIDI interconnection, JACK provides other very useful mechanisms to let your audio apps work together like never before. For example record/playback synchronization between DAWs and sequencer apps. Arbitrary data sharing among apps and much more. Even though JACK is quite new on iOS, it already came a long way. Providing you the most professional and powerful environment for your audio apps, highly optimized with explicit multi core support, low latency and maturity which it gained over many years of usage and development on other operating systems already. JACK is an open standard, which can freely be supported by anybody.

Current Features:

Audio connections between apps and external devices.
MIDI connections between apps and external devices.
Record/Playback synchronization between apps.
Multi Core CPU support for high performance (parallelized internal audio graph).
Low Latency Performance (configurable, i.e. 2ms buffer sizes).
Arbitrary, custom data sharing among apps (allows easy extensions of the system).
Arbitrary amount of audio & MIDI ports per app, changeable at runtime.
Intuitive user interface that allows you to easily manage all audio and MIDI connections, environment settings, monitor current overall CPU usage and more …

As always, for external audio/MIDI, you need a supported device.

But if you have iOS 5, you can try this now. We just need apps that support JACK for it to be useful. But – yes, I’ll be testing this, as this for me starts to suggest a workflow I’d actually want to use in a way that these other bits and pieces weren’t. Nice work by Christian Schoenebeck bringing this to the platform.

See also the developers’ very cool free MIDI monitor.




  • papernoise

    anybody knows which apps are currently compatible with Jack? Right now I’d like to test it but can’t because none of my apps are compatible with it. One thing the Audiobus guys did really well is the communication part, they built the list of compatible apps right in!
    Jack feels a lot more complex by how it is built, but it could easily become the one app to rule them all… if the developers give it a chance.

    • sletz

      Well Christian Schoenebeck (Crudebyte) did the GUI part, GRAME ( did most of the backend part, that is porting JACK code on iOS.

    • Peter Kirn

      I don’t think that answered the question. He’s looking for apps that already work with JACK on iOS. (which, right now, is none apps – know anyone trying this?)

    • papernoise

      I think their own piano app works on Jack but I think that’s it for now

    • sletz

      Chick and eggs problem. We at Grame use the Faust platform ( to generate a bunch of test audio applications. A subset of that is part of the Jack iOS SDK. We are working on improving the Faust to Jack iOS generation model.

    • Peter Kirn

      Actually, that’s the definition of a chicken and egg solution. ;) You’ve got both.

      But yeah, it’s going to take developer interest to jump-start this for everyone else.

    • Sylvain Poitras
  • papernoise

    One thing worth mentioning is that iOS is the only platform where applications need to be made Jack-compatible… On any other platform they just work

    • PaulDavisTheFirst

      not strictly true. On Windows, only apps that use ASIO can interoperate with JACK (because nobody from the Windows community has ever stepped up to write WDM or similar backends for JACK). Obviously, given ASIO’s prevalence on Windows for serious music creation and pro-audio software, this isn’t a huge issue, but it does mean that consumer/desktop audio apps tend not to be compatible with JACK at this time. If someone would write a WDM (or even a DirectSound) pseudo-device, this situation could change, but it appears that Microsoft has some opinions on this.

    • Peter Kirn

      Right, although that’s still a big difference from the situation here, given that so many apps on Windows people would want to use with JACK do use ASIO. Of course, there are still reasons to use JACK as your default audio API and not something else, on any of these OSes.

    • papernoise

      I think Peter nailed the point in his answer. I agree with you about Jack on Windows, but the point I was making is that iOS has introduced a layer of complexity for the developers that other OSes don’t have, with the risk that diversity, which usually would be a good thing, turns into a big mess for the users

    • Peter Kirn

      – right, but JACK is a nice solution to that. You can add a few lines of code and get all this stuff “for free.” (Actually, that’s why some developers are using JACK on other platforms.)

    • papernoise

      yeah of course, wasn’t saying Jack isn’t a great thing! All the contrary! I was more referring to the overall landscape of music applications on iOS.

  • Todd Keebs

    “Audio connections between apps and external devices.

    MIDI connections between apps and external devices.”
    Am I understanding this right in thinking this could be used in conjection with a real computer’s DAW to transfer audio and MIDI? If so, this seems like the big selling point to me, over iOS only routing. For many, this could make iOS significantly more useful as an addition to their normal studio setup.

    • Peter Kirn

      This is describing audio and MIDI devices. So, yes, you can use them with your DAW, but – that’s always true with external device support. ;) We’re talking actually connecting cables and such. What’s different is now you can route them arbitrarily from multiple apps to that output, so you’re not restricted only by the default output options of a single app (if that made any sense)

    • Todd Keebs

      Hmmm, I think what you’re saying is that it can act as a hub for a centralized MIDI/audio output from the iOS device through the normal methods (headphone jack/audio interface and/or MIDI interface)? If so, I was hoping for something more “elegant” like wireless audio and MIDI streaming to the host computer running the DAW.

    • PaulDavisTheFirst

      wifi is pretty horrible for low latency audio, which is what JACK is all about (though you can choose to use it with much larger latencies if you want)

      in theory, someone could port one of the netjack implementations as an iOS app, it would function as a JACK client, and could then route audio from any other JACK-compatible app to either a LAN or WAN.

      this technology already works, but has never been wrapped in an easy to use implementation. one of the beautiful parts about JACK is that you can add a client that can do “X” and suddenly every other client can do “X” as well (such as network streaming).

    • Mister Pickle

      One of my next purchases is going to be an iConnectMIDI4+ — it would be awesome if JACK supported audio and MIDI routing via that device.

  • wms

    Man, Android is ripe for this kind of thing, no licence restriction headaches, yet STILL no one wants to touch it with a bargepole!

    • Harry Pendergrass

      Android doesn’t do low latency audio. That, and making any money from an android app is even less likely than making any on an iOS app.

    • Peter Kirn

      Well, except, this is free. Just looking at what they’re doing, *I’d* rather do it on iOS than Android even if I weren’t getting paid.

    • Peter Kirn

      Yeah, actually, I can imagine JACK would be vastly easier to port to iOS than Android, unfortunately, because of the way the audio engine is put together on Android (just looking at things like the fact that this JACK implementation sets specific, very small buffer sizes, etc.). But it would be possible; I can imagine someone would want to make it happen. Testing – now that’s another story, that’s going to be additional added work.

    • foljs

      “”"Man, Android is ripe for this kind of thing, no licence restriction headaches, yet STILL no one wants to touch it with a bargepole!”"”


      1) the money are not there (because besides some tech enthusiasts that hate Apple or like “open”, most people that buy Android are lower tier just-give-me-a-free-phone-with-my-contract average Joes).

      2) And Android is bad at low latency.

    • wms

      1) I dont buy (scuse pun) those arguments, cause there is actually a ton of cash to make if you make the right app well. I bet there are many iOS music apps that are utter balls and make no cash. Besides I am a long time Mac user, that chose to buy an Android phone because I dislike the walled garden approach to its usage. I don’t hate Apple, and I prefer “open”.

      2) Android does do low latency – very low since 4.1. Define latency – The problem has been user input and not all music apps rely on that kind of input. Low latency input does exist on apps like Caustic for example.

      The real fact is that developers have had cushy time of developing for one platform rather than taking the bull by the horns and challenging those misconceptions, and potentially accessing and much wider audience to purchase their wares…

      just sayin, don’t wanna start a flame war :)

  • RichardL

    The SDK for the proprietary AudioBus standard for interprocess audio was released to the public yesterday too.

    • Peter Kirn

      Yeah, just added that to the article!

      Take a look at the JACK code examples, though. I mean, it’s stupidly, stupidly simple to do.

  • teej

    all of this effort and progress is very awesome and very welcome but, again, the need for special compatibility preparations from developers worries me.

    with Apple’s track record of eventually gobbling up or outright copying useful technology and making it native, i wouldn’t blame any developers who take the sit-and-wait approach on any of these third party solutions. do they waste time and resources integrating 3rd party APIs, or do they work on growing their own app under the presumption Apple will be swooping in any moment to answer those needs anyway?

    again, it’s still awesome and i hope all of my favorite devs get on board. that’s for sure.

    • PaulDavisTheFirst

      We developed (or more precisely, Stephane Letz @ GRAME in France, ported) JACK for OS X roughly 9 years ago. Apple sat on the sidelines as we (the JACK development folks) gave OS X users want they wanted – inter-application audio, shared transport and later MIDI. They never jumped in, they never expressed any interest in what we had done, they never gave us any particular consideration. Their interest in this sort of thing on OS X appears relatively weak, possibly because of the implications for “content providers”. Who knows. Maybe they consider iOS differently.

  • Mister Pickle

    I am SOOO there. I realize that I’m in the minority — and probably at risk of bodily harm — saying this, but: I don’t really like Audiobus. As Peter mentions, it’s not particularly flexible, and I’d like to be able to process MIDI. I guess it will take awhile for some of my favorite apps to provide the necessary support, but (IMHO) iOS music software is still evolving and there’s a long way to go before anyone is declared the winner.

    Also, this:

    • Geert Bevin

      Actually I’m with you, I was super excited about Audiobus and even got in as a beta tester. In practice though I never use it since it’s so basic. It’s got this single linear flow and that’s all that’s possible. I expected that it would be like Jack, but it’s not, it’s slimmed down for dummies. I’m very excited that Jack has now come to iOS but I fear it might be too late. Apps just finished adding support for Audiobus, I’m afraid they’ll punt on Jack support.

    • papernoise

      Totally agree, thinking now that I even paid for it… but well. If we dig deeper into the whole matter I think maybe the problem lays eve deeper and Jack will solve only part of it. One of the most brilliant innovations in virtual sound processing was the introduction of plugins… which is something that solves a lot of problems and saves a lot of time. On Linux there is some software that works with Jack, that can save a snapshot of your setup and recreate that the next time you turn on the computer, but yeah… a proper DAW and plugins are just the best solution around so far. Many things on iOS feel like a huge step back right now.

    • Taylor Holliday

      Papernoise, I agree… plugins are a great workflow. One cool thing you can do with JACK is set up a send/return loop so another app acts somewhat like a plugin. The downside, on iOS at least, is that you can’t have multiple instances of the other app, but I think its still a good step forward for more advanced workflows. And of course there’s no state snapshotting, but we can get there too eventually.

      I’m going to be adding JACK support to my own app, Audulus :-)

      - Taylor

    • papernoise

      Yeah, I guess someone will create something like Jack Session for iOS and the whole workflow will become a lot better. btw it’s great that you’ll be adding Jack support, I guess more developers will follow once someone starts. Looking forward to try Audulus with Jack.

    • MisterPickle

      Awesome! You’ll have to let everyone know how easy (or difficult) it is to add JACK.

    • foljs

      “”" but (IMHO) iOS music software is still evolving and there’s a long way to go before anyone is declared the winner.”"”

      Well, Apple just embraced AudioBus (with the latest GarageBand update).

      It’s probably the first time Apple embraces something made by a third party on iOS — on OS X the implement OSC, Rewire etc, and it’s a strong signal.

      So, I think we have a winner.

  • valillon

    Wow very exciting! A step closer to musical apps with Processing and libpd. About half a year ago, unable to glue processing-libpd-ios together, i had to move to OpenFrameworks, which works more than decently in any case. Awaiting for the next Processing’s step. Thousands of thanks developers!

  • Ivan

    It’s very exciting to see things moving there. The same day, I heard about Jack for iOS, the AudioBus SDK, and also the framework Amazing Audio Engine (…) from the same guys than AudioBus, helping developers to make iOS applications more easily, and allowing users of these apps to do interesting things. It would be interesting also to compare what all these tools can bring to us (developers and musicians).

    Anyway, even if I have an iPhone, and even if I can understand all that excitement, I’m still someone who DOES NOT MAKE MUSIC WITH IOS. I mean, someone here can say he has done something serious with a smartphone or a tablet here ? Like exporting something made in one of these cheap apps into its favorite sequencer ? Or using one idea found during a jam with an iOS DAW/synth ? I think sometimes that the workflow in “normal computer DAWs” is counter intuitive for music creation. But it’s worse with these apps for me ! I just don’t get what is so cool in them, when everybody has (or can have) a decent home studio.

    But that’s only my opinion ! And that’s why I still have an interest for these technologies : I’m waiting for something which will make a real difference for me, and I believe it can happen.

    • Sylvain Poitras

      “I mean, someone here can say he has done something serious with a smartphone or a tablet here ?”

      Sure why not? One electroacoustic piece I composed last year with Samplewiz has been featured in concerts across Canada (Vancouver, St-Johns, Montreal, Toronto).

  • Luca Frigo

    Hope that in a few Months all apps would support Jack by default…