What’s Playing?
A Google Chrome App walks into a pub…
In my previous article I covered the setup of the Duckbox — our latest project, a digital jukebox at the recently opened Duck and Rice in Soho, London. This time I’m going to talk specifically about the screen showing what’s currently playing on the Duckbox. It’s a HTML5 based Google Chrome app, running on a display just behind the bar of The Duck and Rice.
The idea goes back to two themes often found in British pubs — the clock on the wall and the three flying ducks. Our goal was to interpret these creatively in the final display and create the first version of hopefully many more different to come.
Besides these creative constraints, we outlined the technical requirements of the application:
- Display animation and the current track information
- Run fullscreen
- Launch automatically on startup
- Access audio-input to allow animations to be sound-reactive
- Works offline in case of loss of Internet connectivity
- Easy to update
What are the Options?
Media installations like this are often built using so called toolkits for creative coding. Among the most common ones are Cinder, OpenFrameworks and Processing. Aimed at visual arts, prototyping as well as teaching how to program they look to reduce the coding and let you focus on the creative instead. They can be very powerful and many excellent projects have been created using them. During the past few years my work involved every single one of the above at some point, usually in collaboration with specialised developers.
However, it’s left me with mixed feelings. Too often the results suffered from memory leaks, crashes and good old freezing. More importantly, it’s been incredibly hard to find good developers.
Luckily, over the past few years, we’ve seen a great evolution of both capabilities and software development standards in web development. Furthermore there’s a great pool of developers to choose from when it comes to web technologies.
This matters for the Duckbox display not only for the development process. Once launched, these kind of projects usually don’t receive much further support. Going for web technologies is the best way to make it relatively easy for somebody else to pick it up if need be.
There’re still good reasons to use Cinder, OpenFrameworks et al as they make great use of GPU acceleration and can outperform web depending on what you’re trying to create.
That One!
Settled on HTML5 there was still the question how to distribute the app without rolling out our own deployment system. Running the app off a web server would not go well with connection drop outs. So it quickly boiled down to a packaged web app running locally. This left us with two options.
Both share similar ideas, essentially allowing to install and run web apps in a native environment. This gives them the option to get special permissions to access data and hardware a normal web app wouldn’t be allowed to touch.
Since these permissions requests are specified in a so-called manifest file they only have to be granted once. This is great in our case for using the audio input as it won’t need any further user attention, unlike a typical website which would request permission every time a user visits it.
Conveniently, both stores also update the apps automatically whenever a new version has been published. We went for Google Chrome Web Store in the end because publishing the app doesn’t require a review and is therefor really quick. Also, Chrome usually is our preferred browser during web development and cross-browser compatibility isn’t really an issue in this case.
Technical Detail: Don’t try to publish to the Chrome Web Store when you’re logged in with multiple Google accounts at the same time. Log out first and log in again only to the account you want to use for publishing.
Fly Ducks, Fly!
While we were working out the technical approach the design had come together nicely. It primarily consists of a pattern featuring three abstract ducks and equally abstract digits to display the time. All the animations had to do now was showing and hiding shapes either based on the audio signal or on time.
The pattern itself is a SVG with the grouped shapes for each duck and digit. Using CSS transitions they simply change opacity. A renderer is responsible for updating the shapes based on the frequency information provided by the Web Audio API. Each duck representing a certain frequency range is drawn shape by shape just to fade out again shortly after. All this runs on loop and the higher the amplitude of the frequency the higher the opacity used to show the shapes. Only the time shapes works slightly differently — they only appear briefly once per minute.
That left us only with one more thing to add. At The Duck and Rice a dedicated computer drives the display, receiving the sound system’s audio via an external sound card — a Behringer U-Control UCA222 to be precise. So we included a simple settings interface to select and save the input device along with connection settings for the Duckbox API and we were ready to go.
The Duckbox Display is now running at The Duck and Rice. Pop in to see it yourself. If you would rather like to run it on your computer, install the app from the Chrome Web Store.
Want to tinker with the source code? Feel free to fork the project on GitHub. There are probably ways to increase the animation performance by using Canvas or possibly even WebGL.
I work at the Rumpus Room where we work with agencies, broadcasters, charities and clients designing and building technology to create social entertainment across mobile, web and real world experiences.
