Watching a skyscraper go up is always fascinating. For a long time, the thing basically looks like a bit pit in the ground. After some time, you get the beginnings of a skeleton. Suddenly, the structure rises at a near-impossible pace, climbing into the clouds faster than you’d imagine. Then, it’s at a point when it looks finished, but isn’t – there’s this final, agonizing push to make it really inhabitable for everyone.
Yep, new standards are often the same way. Web audio had, in comparison to conventional native development, looked largely like that gaping hole in the ground for a while. But, while it’s not quite ready for occupancy, we’re seeing what the structure will look like – and it’s pretty amazing.
There are a range of different APIs here, looking at standards that work in more than one browser. There’s the Web Audio API, which goes beyond sound playback to allow real-time applications in the browser (even synths and the like). There are also hardware APIs for connecting this stuff to audio and MIDI. Here’s what you can anticipate:
- Safari comes onboard. Safari 6 adds the Web Audio API to Apple’s browser, so that we’re not only talking about Chrome and Firefox. (Firefox, having been a pioneer here, is gradually moving to something that will work across all three browsers, as well.)
- iOS is getting real audio support. iOS has added Web audio support in the browser – meaning faster desktop-to-mobile adoption than you might expect. Result: right now, hacks let you fist pump with your iPhone. Thanks to strong iOS adoption, that means a quarter of all iOS devices can already support this API, with more to come. Android is another story, with even basic audio playback capabilities missing from most devices as severe OS update problems and lagging support cripple the mobile OS.
- Live audio input is coming. It’s only in the unstable Chrome build, but live audio input is already working in at least one browser and likely to appear in others. It’s obviously a must-have, and while mic input itself isn’t terribly exciting, check out the really lovely stompbox demo below.
- Codecs remain an issue. As with video, one stumbling block is codec support; some browsers support MP3 but not OGG, some OGG but not MP3, and so on.
- Web standards continue to evolve. W3C, the Web standards body, is continuing its working group developing these standards, and —
- MIDI is coming. That same body will look at a standard for MIDI hardware connections.
Correction: Regarding mobile adoption, I very incorrectly suggested Android had similar adoption to iOS, when the reality is in fact bleak – disappointing given Google’s leadership in desktop (and another instance of Google’s Chrome and Android projects being badly out of sync).
None of this is really interesting until you get to the application, which is why Pedalboard.js is the most compelling news here, pictured at top. Building on this forthcoming line input capability – and the effects possible now in Chrome and Safari – effects no longer are limited to a native host. Running in a browser, they’re accessible from anywhere, and easy to share with friends. The framework is a free and open source toolkit for building other effects (stompbox or otherwise), all with JavaScript and CSS.
With just a few lines of code, you can add effects to a virtual pedalboard, and control switches and pots for parameters. The demo is already fun to play with.
http://dashersw.github.com/pedalboard.js/
It may be early to think about deploying anything this way – browser implementations are still not entirely stable. But you can see the building taking shape. And one day, a lot of happy music applications may be living inside.
Update: I should add a huge disclaimer to almost every Web audio post. I still think of Web audio as a supplement to, not a replacement for, native applications. What you need for production tools ultimately can require extensive integration with the desktop OS, for hardware control, file system integration, and the like. There’s also the fundamental problem that, because you’re leaning on the browser’s implementation, the underlying engine might change as you’re using it – that just doesn’t suit more sophisticated tools. That’s before we even get into the matter of whether you could build a business ecosystem for applications running in the browser that would allow developers to sell their work. These aren’t just minor issues that will get sorted out with time; they’re ways in which the browser is still fundamentally a different software environment.
But because it’s fundamentally different, it could be suitable to other uses – for instance, you could imagine trying out a hardware pedal or new plug-in in a browser demo, or sharing effects examples in education, or applying some simple effects to a track you’ve shared with others online. And the front-end capabilities of the Web may still have something to offer conventional desktop development, too. Ultimately, each could make the other richer.
In any event, the best way to find out is to try development exercises just like the ones here.