Sonic Pi in a web browser

hello, I am approaching sonic pi from a programming background and a basic love for raspberry pi.

I have been searching relentlessly the past few days. I am trying to find a solution that would allow people to collaboratively program music on a website.
I came up with this:
which is just hosted on my raspberry pi at home.
everything is done server side so the music takes time to catch up and be streamed to your browser. be patient.

I would love to see this project go as far as to have an online interpreter with autocomplete for sonic pi that allows people (students and kids) to program together from a web browser.

I know there are probably projects like this. Anybody know of them?


also it would be cool to see the ability to import samples from online

Take a look at gibber:, or EarSketch:

1 Like

Wow Sam Aaron replied to me! I have actually looked at those options. Are the sounds executed on the server side or browser side? Are they as feature rich as sonic-pi?

As far as I understand, they both use Web Audio for their sound production and therefore generate their sound in the browser. As for features, there’s likely to be things they can do that Sonic Pi can’t and visa versa. It all really depends on your musical goals :slight_smile:

I’d experiment with them both and see what you think.

Hey @daveyman123 , seems to be down. Can you update me on the progress of your work on that ? I have been thinking about building a similar platform but I would rather help an existing project than start something from scratch.

Could WebAssembly be an option?
Also @samaaron what are your thoughts on Rust?
I see that the githab has the code listed as C++ yet we are using Ruby when using Sonic Pi. Also, can you explain a bit more on Erlang and what role it may be playing in the future?

Reviving this thread for a specific reason: there’s now a web port of a port of that (in)famous livecoding software of which we dare not speak…

I’ll probably try it, as browser-based musicking is relevant to my (research) interests. It’s also expanding, what with WebMIDI.js and WebAudio API. (The reason I mention WebMIDI.js specifically has to do with my dayjob.)

I find Kirn’s take interesting:

{the software} has two problems, though. One is, it’s a little complex to install for beginners because of multiple dependencies. That’s not insurmountable, but it’s a pain if you’re teaching a workshop for a couple of hours to beginners, for instance. Two, the notation can get a little verbose.

Under most conditions, Sonic Pi is trivial to install and run. As we all know, a version has been part of the base Raspberry Pi install from the beginning. And it runs as a portable app on Windows. In other words, problem one is moot, for us.
Famously, a huge amount of power is unleashed by Sonic Pi with two simplistic commands: play and sleep. (Shorthand for any command is easy to implement.) Sure, notation can become verbose in certain hands. Yet SPi musicking is very satisfying with a concise and obvious notation.

So… What would a web-based instance of our beloved musicking environment solve, as a key issue?
One thing I perceive as a large benefit is integration in something else. And that’s going back to my dayjob as a technopedagogue as well as my longterm research on electronic musicking. It could become the musicking equivalent of JupyterLab. Documentation and musical code would coexist in webpages.
Then, there’s a notion that it could allow for some form of online collaboration. Of course, realtime collaboration would be very challenging. Asynchronous collaboration, not so much. That part would be very similar to what we’ve been doing for years on forums such as this one or on code repositories. The main difference would be that we’d be able to run the code we share and tweak without having to copy from a browser and paste in a SPi buffer.
A third issue is about device support. And that one is still not that clear, with musicking web apps. Typically, Safari isn’t supported and its engine is the only one available on iPadOS and iOS (even though there are several browsers, they all need to use Apple’s web rendering engine). So, in theory, a web app is supposed to increase compatibility across devices. In practice, it sounds like it’s not going to work well for some time.
There’s also a workflow advantage in having buffers in browser tabs (assuming they can all have unique URLs). With a bit of discipline, saving .rb files in cloud storage can work well. Having direct links to these files would greatly simplify things. (It could also help with metadata.)

So… I feel there’d be obvious advantages for a web-based Sonic Pi. Those are quite different from what Strudel adds to that livecoding software, in Kirn’s telling.

I don’t think in that case the Supercollider actually runs in a browser. Or am I wrong?

Right. The idea for Sonic Pi in the browser would be that there’s a Supercollider server behind it.
I don’t know enough about Strudel to tell if it uses SC at the server level. Kirn mentions using SC locally, using OSC from Strudel.
In a way, the ideal situation would probably be to have a browser-based app which also does the sound generation directly in the browser. With current performance, it’s not that absurd.

For me a big part of the attraction of Sonic-Pi
is the ‘Rubyness’ …
( Perhaps because of the simularity to BASIC
which I started with )
For a web SPi I think the synth here …
( SDL or ??? or web api )
Would do … IF …The programming grammar remained as is .

1 Like

Running Ruby in a browser window is not a big problem; e.g.: