I started up Oslo Mobile Orchestra (OMO) in 2009 (originally named Oslo iPhone Ensemble), expanding on Oslo Laptop Orchestra. This was part of teaching courses in sound and music programming at the University of Oslo. We used some ready-made mobile phone apps, including Brian Eno’s Bloom, but also programmed some patches in Pure Data, which we wrapped in MobMuPlat. Now, with the support of Cursor, I have ported a bunch of the old patches to web apps. In this blog post, I explain the process.

What OMO is (and what it is not)

From the start, OMO has had some simple rules guiding performances and instruments:

  • Sound comes from the phones: We rely on the built-in speakers or small handheld speakers so that it is clear where the sound is coming from
  • Phones are thought of as instruments: We focus on real-time interaction with immediate sonic response
  • Sensors matter: We use as many sensors as possible, including tilt, mic, camera, touch, and (where available) compass.
  • Playing together is social: We explore normal musicianship through listening, partaking and ensemble behaviour with and without a conductor.

Of course, the idea with the new apps is to continue this tradition.

The old stack: Pure Data and MobMuPlat

When we started up, we relied on everyone using iPhones to ensure that things worked well. Still, different iPhone versions behaved differently, so we bought a set of identical iPods to simplify maintenance. Still, it was a struggle to keep everything up to date; deploying new apps across all devices was a pain.

After I became Head of Department and later began developing RITMO, OMO activities dropped to a minimum. I assembled ad hoc ensembles from time to time, but never with the same momentum as in the “golden years” 2009–2012. However, we have decided to revamp OMO activities again, which was a good time to think afresh about the installation.

The new stack: Web Audio apps

Mobile phones have changed dramatically over the last decade. Faster hardware makes everything much snappier, but most importantly, the development of the Web Audio API and many JavaScript development tools.

The current collection is deployed as a static site at fourms.github.io/omo and the open repository is available here: github.com/fourMs/omo. It is based on a single hub listing each app, with a similar look and feel to simplify usage.

A typical instrument in the collection is assembled from shared pieces:

  1. Audio on — every app exposes the same header control and unlocks a shared AudioContext to turn sound on.
  2. A master bus — gain staging and light compression before the output.
  3. Volume (50%–150%) — some phones are quieter than others and need some extra “push”.
  4. Learn — performance instructions help users get started and explain the synthesis and sensing modes used.
  5. QR codes — make it possible to easily share the instrument URL so the ensemble opens the same patch.

All the synthesis is based on plain Web Audio: oscillators, biquads, delays, ConvolverNode reverbs, and Karplus–Strong buffers. Some audio engines used across apps are added to the shared/ folder.

Sensor data is collected via shared/sensors.js and can be reviewed on a device support page that can be run at workshops to get everyone on the same page.

The app collection

The collection currently counts around 50 apps. Several of these are ports of old OMO patches; some are mobile-friendly versions of OLO patches; and I got inspired to make some new ones while working on it.

SectionCountWhat it covers
Rhythm11Grids, pulses, delays, ensemble timing
Drones11Held tones, filters, motion-driven timbre
Melody9Keys, breath, pitch tracking, bowed surfaces
Synthesis12FM, Karplus–Strong, ladders, pads — “under the hood” teaching
Texture11Sampling, granular clouds, camera and room sound
AI4Small on-device models (k-NN, gesture classifiers) — no cloud

OMO started as a pedagogical tool, and I have decided to keep things simple. So there is often one synthesis idea or interaction idea per app.

Ready to perform

I have already tested the new apps in several spontaneous performance settings, with around 100 participants. So far, things seem to work almost as well as expected.

The addition of QR codes per app is great. I can easily connect my phone to a screen to share the app code to run.

As long as users use Chrome on Android or Safari on iOS, things generally work well. Still, phones behave differently. Most challenging is that the speaker levels are so different. So some calibration is necessary at the beginning of rehearsals.

Android phones generally work best. iPhones are tricky when it comes to access to sensors. I have experienced that several people struggle with the tilt sensor, for example.

The coolest thing now is how easy it is to implement new ideas with agentic support. So I am really looking forward to exploring new apps with students!

Try it yourself

Thanks to Cursor for assisting with porting the apps and writing the first draft of this post.