It always has to be complicated, doesn’t it? You just want to sit on your couch with your iPhone or iPad and finish some music, by recording that drum machine and a bass line into a multitrack song in a different app. And then, after months of this site saying the way to do that was something called Audiobus, everyone is suddenly talking about something called JACK, too. Ah, standards.
All of this had some wondering if JACK even has a shot, with Audiobus already out there. Even Apple has come onboard, as of last week, with the announcement that GarageBand would support Audiobus. At US$5, with versatile multitrack arrangement features, GarageBand is ideal for recording from Audiobus-compatible sources, which now include Animoog, ThumbJam, Samplr, DM1, and the Korg lineup, among others. (Apple even specifically mentioned those in a note on the upgrade.)
So with Audiobus succeeding, JACK will fail, right? I don’t think so. I think we may see both “standards” evolve, and that, contrary to first appearances, they may fit different needs and use cases.
First, some important points in favor of successful JACK adoption:
- JACK-compatible apps are coming, starting this week. JACK-compatible apps are coming. It’s only been days since the announcement, and already imminent support has been announced for ThumbJam, Live Guitar, the innovative Audulus modular, Audio Filter, and DrumJam. We expect these apps by the end of this week. Those apps may sound familiar, because:
- An app can easily add support for both JACK and Audiobus. Already, apps with Audiobus support are also adding JACK support. (More on why that may make sense in a moment.) Because you launch the JACK or Audiobus app first, then load these other apps, they will simply use whichever audio system is available. If a user uses neither, apps just operate like normal iOS apps. I’ve confirmed with JACK developer Christian Schoenebeck that you can support both. In fact, he tells CDM, “most of the upcoming third party apps with JACK support already support Audiobus, and they will continue to support Audiobus, of course. So there is absolutely no conflict.” Christian tells us more news, plus a forum, will be online in the coming days. Follow the iOS app page or Twitter tag #jackaudio / @crudebyte for the latest updates.
- Adding JACK support is dead simple. To add JACK support to your app, we’re talking about downloading the free SDK, dropping it into a project, and then adding a few lines of code. You could literally spend more time reading and commenting on this article than adding support, assuming the rest of your app is running smoothly in regards to audio. The step of adding JACK itself, then, is unlikely to be an obstacle. In fact, JACK support implementation I find easier than Audiobus – and you get more features (sync, MIDI, data, not just audio).
Which Bus Should You Ride?
But let’s back up. If the idea is that both apps can easily support JACK and Audiobus, and some already can, we return to the more important question: why would you want to support two different means of connecting audio?
Developers tells me interoperability between JACK and Audiobus is a possibility for the future. In the meantime, though, let’s assume you use the two separately. Audiobus and JACK each have specific advantages.
For simple audio connections between apps, Audiobus helps reach a broad audience. Audiobus’ simple source / effect / recorder structure, and focus on audio, may be too rigid for some users, but it can be a selling point for others. Part of the appeal of iPads and iPhones is in attracting new people to music making. Those users may intuitively want to connect different apps – recording a vocoder vocal line into a looper, for instance – but they may not need something much fancier than that. They may not even know what MIDI is, or need complex connections between apps. Here, Audiobus excels. It makes the flow of audio, effects, and recording clear and has a friendly, attractive user interface well suited to that audience. And…
Audiobus does a good job of evangelizing the idea of connecting apps. With an elegant website and documentation, a showcase for compatible apps, and active social channels (Facebook, Twitter, and a mailing list), Audiobus is actively getting the word out to new users. Some developers will wisely support Audiobus just to attract new people to their apps. (I think JACK can learn from this, too, but the niches remain a bit different – see my previous point.)
When your needs outgrow Audiobus, nothing can touch JACK. The reverse is true: JACK is the more powerful tool. Audiobus routes audio between apps, but it’s limited to basic connections, and it doesn’t do other kinds of data. JACK does audio, but also sync, MIDI, and data copy/paste. And connections of any of these elements in JACK can be more powerful, running between apps in any combination you like.
JACK is free. Not all developers may relish the idea of pointing users to an app they have to buy to make those connections. JACK is free. Audiobus (normally US$9.99, on sale now for $4.99) isn’t. And JACK uses the same free and open source technology found on desktop systems, so while “open standard” I think isn’t quite right (open source and “de facto” standard, to be precise), JACK is something developers can easily support.
Again, consider the landscape:
Inter-app audio: Audiobus, JACK. (JACK offers more flexible connections.)
Inter-app MIDI: via Code Audio, or JACK. (JACK makes it easy to see graphically how you’re connected.)
Sync: WIST (Wireless Sync-Start, from KORG), or JACK.
Arbitrary data transfer: AudioCopy and AudioPaste, or JACK.
JACK is the only tool that does all of these things with one technology, it has the most open approach to the SDK, and it allows more flexible implementation of all four of these functions than any of the competing technologies alone. Users get it for free. Developers get it for free. And it’s easy to implement.
Audiobus, meanwhile, still has a place as a tool that charges a few bucks for the convenience of audio connectivity that’s really simple to end users, for people who don’t need all those fancy features.
It’s impossible not to notice that this is a lot to implement for a developer making a $2 app. But it’s also creating an ecosystem in which $2 apps can more easily thrive.
Bottom line, my guess: Audiobus will be a good choice for newcomers to inter-app audio; JACK will be the preferred solution for more advanced users. Smart developers will take the time to implement both, and certainly at least JACK. (Even if your users don’t need it, I think you as the developer may get more pleasure out of using your own app!)
And both Audiobus and JACK can gain from each other. Apart from sharing any engineering insights, I think JACK could learn from Audiobus’ nice UI design and app showcase. Audiobus could benefit from working together with JACK’s more powerful features.
JACK is only days old; Audiobus has a three-month head start on iOS. So here are some tutorials on the Audiobus side.
My colleague Chris Breen takes GarageBand with Audiobus for a spin.
A new beginners’ guide vid:
Beatmaker MIDI used to sync Audiobus apps:
The Amazing Audio Engine is an open source sound engine for iOS with built-in Audiobus support (no surprise, as it’s from one of the creators of Audiobus).
The Big Picture: Addendum
I have to say, I think that this in general can be good for the open source ecosystem on one hand, and for music developers making their apps more useful with minimal effort on the other. For instance, with our libpd library, we now can allow people to work with Pd to target something as far apart as an iPad and a Raspberry Pi with the same visual Pure Data patch. JACK on iOS means that very easily that Pd patch could get recorded into another app on an iPad; JACK on desktop means you could route it to a DAW like Ardour. JACK and libpd each use similar interfaces for routing audio to and from the hardware interface, so these create friendly, consistent APIs developers can use to get glitch-free audio between apps on lots of platforms.
For users, it means that increasingly, we see music making environments in which software tools are flexible, easy to inter-connect, and designed for specific tasks, rather than the rigid DAW + plug-in architecture that has dominated desktop music making for years.
And that gets us back to your couch and your music. I hope in coming months, this helps you get more done there.