samaaron

For the record I didn’t use LLMs to write this tutorial.

Here's DJ Dave using Sonic Pi: https://www.youtube.com/watch?v=w2s1DK1w3WI

Also, Sonic Pi was designed for teaching - the language priorities for professional programmers that touch-type are quite different to those for a learner. Lots of strict and unusual syntax can be a considerable and confusing barrier.

Also, Sonic Pi is implemented in Ruby, so you can totally use `{ }` just fine if that's your preference :-)

v5 now has AppImage builds for Linux ARM64, x64 and x86: https://github.com/sonic-pi-net/sonic-pi/releases/tag/v5.0.0

Oh amazing - thank-you so much for your kind and generous support! I can only do this work because of people such as yourself. Thanks!

I nerd-sniped myself porting SuperCollider's scsynth audio DSP engine for that Tau5 project. This then turned into SuperSonic (https://sonic-pi.net/supersonic/demo.html). I then wrapped SuperSonic back into a native form and used it to replace scsynth in v5 of Sonic Pi (https://github.com/sonic-pi-net/sonic-pi/releases/tag/v5.0.0).

I'm now working on a new audio DSP engine which builds on all this learning which combines my favourite parts of scsynth and Erlang. I'll be discussing and sharing progress over on my Patreon (https://patreon.com/samaaron).

As a sneak peek - here's an experimental prototype of the kind of direction I'm headed in: https://sonic-pi.net/tau

Of course - and it's what I've been working hard on in the background for the past year.

I ported SuperCollider's scsynth to Web Audio workouts (https://sonic-pi.net/supersonic/demo.html) late 2025, built an experimental spike called Sonic Tau (https://sonic-pi.net/tau). Then I wrapped SuperSonic in a native audio framework and used it to replace scsynth in Sonic Pi v5 (https://github.com/sonic-pi-net/sonic-pi/releases/tag/v5.0.0)

I'm now working on a new audio DSP engine building on this learning which combines my favourite aspects of scsynth and Erlang which I'll be discussing and revealing over on my Patreon over the coming months (https://patreon.com/samaaron)

For the record, this isn't an official Sonic Pi web version - it's an LLM rewrite by a fan.

Good points -I’ll clarify the LICENSE along those lines when I’m back from a family holiday. I’ll also look to move the recommended web deployment to an isolated-origin model with the same separation as the native out-of-process case.

Worth noting for context: SuperSonic is quite a bit more than the scsynth module - both it and the Link module are optional. A build without them contains no GPL code and carries no GPL obligations.

Yes, SuperSonic (the new internal synth and IO engine) specifically targets embedded devices, so expect some fun announcements in the future!

SuperSonic started life as an experiment side project and was the first successful AudioWorklet port of scsynth. When I got it working I shared it with the SuperCollider community with the hope that some form of contribution collaboration might happen but there didn’t seem to be much interest - and mostly friction possibly due to the fact that I had made use of LLMs to navigate and study the original code base. They then built their own audioworklet version which they merged into mainline. That was a signal for me to continue independently which I did - subsequently adding native and embedded targets to SuperSonic.

Sonic Pi uses the native version which includes substantial improvements specifically for the use case for Sonic Pi (schools and beginner ergonomics) vs pro audio workflows.

Also I definitely intend to keep things compatible where feasible and have already done this since November 2025.

Thanks for your kind support!

Fair - the aggregate clause does say “larger program” so I overstated. However, it doesn’t define combination, and “based on the Program” is defined in section 0 via copyright permission - which is why I keep returning to copyright rather than mechanism.

The JS client doesn’t call into scsynth code. In postMessage mode the client and the engine run in separate execution contexts with no shared memory, exchanging serialised OSC - the browser enforces that boundary the same way the kernel does between processes on a socket.

Also, the JS and Erlang clients are entirely my own code and copyright surely their licence isn’t in question. I think the question you’re actually raising is what obligations fall on users who combine their software with SuperSonic. You already state that my approach in Sonic Pi is fine.

> You are going to great lengths to make sure that SuperSonic (and thus scsynth) can be used from non-GPL code

Sure because it’s my understanding that using a clearly documented protocol that doesn’t share internal data structures does not constitute a derivative work. I’m not trying to change anything rather make the boundary clear.

>They clearly form a single combined program and therefore must comply with the GPL.

I don’t think that this is necessarily the case - if the shape of the architectural boundary is the same as the networked OSC case then I think it’s very reasonable to argue that its aggregation and not derivative. I don’t believe the gpl actually states anything about process boundaries or linking mechanisms. Rather it’s generally the advice that a compiled work is derivative as it likely does share internal data structures etc.

I also don’t quite know what licenses you’re asking me to change. The parts of SuperSonic that derive from scsynth are clearly licensed gpl. The parts that are my copyright are clearly licensed MIT.

I’m really not trying to circumnavigate anything. I’m just trying to assert that calling gpl software over a clearly documented and formal boundary that does not share internal data structures doesn’t trigger the gpl - regardless of linking or process specifics. The issue is about copyright not implementation details.

Congratulations on you anniversary! I’m so happy to hear that Sonic Pi helps you connect together with music. It makes me smile :-)

Thanks also for your kind support.

Awesome to hear! So glad you had fun with it :-)

Apologies but I’m not the maintainer of the Sonic Pi Flatpak.

Instead v5 officially supports AppImage builds.

Sounds like a possible bug which I’d be only too happy to support you with should you open a github issue. Sorry your experience wasn’t smooth.

Oh that sounds like the official SuperCollider stance might be that any use of scsynth from an existing project via the network OSC API is considered an aggregate. Is this the case?

I definitely don’t want to create any issues and it would be great to get some clarity here.

Sorry if it came across as strange. I’m just making sure people don’t confuse the two as SuperSonic isn’t an official SuperCollider project and I don’t want to cause any confusion.

I’m also definitely not wanting to circumnavigate the GPL! I have wholeheartedly embraced it as whilst I would argue it isnt scsynth it is most definitely a derivative work with a lot of shared code. There’s also a lot that is different/new.

Instead I’m only attempting to uphold the same network boundary that has existed since v3 of SuperCollider. When used over a network using an open and documented protocol that doesn’t tend to be considered a derivative work. This is observed in other software is such as databases.

Oh and in Sonic Pi’s case I am not running anything in an audioworklet. SuperSonic is built and shipped in its native form as a totally separate process. No js or browsers involved.

Sorry for any confusion.

Yep, as it’s a derivative work. But I have put effort into making the interface purely network shaped so it’s possible to use it from non-gpl projects without them being considered a derivative work and triggering the gpl.

Not sure if it’s possible to explain this in one sentence - I was just explaining the goals.

As a summary - friendly as in better autocomplete, better error messages. There are vast accessibility improvements for those with low vision and those that use screen readers. It’s more fun for many reasons but stand out ones are support for game controller input, interactive docs and low-friction QuickStart cards.

The post linked goes into more detail and the release notes go even further: https://github.com/sonic-pi-net/sonic-pi/releases/tag/v5.0.0

By default there’s a 500ms latency as this gives all target platforms sufficient breathing space for system pauses and other work not to affect the scheduling.

Multiple presses spawn multiple threads which layer over each other - unless you’re using Live Loops in which case it triggers hot code swapping.

What was the code you were running? Happy to help.

We also have a friendly forum to ask questions and get help: https://in-thread.sonic-pi.net

What do you mean by “running out of scratch space?”

Do you mean your code was too long that Sonic Pi refused to run it? If so this has been addressed in v5 with much larger buffer sizes supported.

Or do you mean you ran out of buffer? In which case v5 helps again as you can now save and load all the buffers to and from a single save-file :-)

Actually v5 no longer uses SuperCollider’s scsynth engine.

I completely replaced it with my own port called SuperSonic - which targets native (used in this Sonic Pi release), WASM and embedded.

See https://github.com/samaaron/supersonic

If you look in the source code you’ll find an example REPL which serves as a great minimal example of how you can build your own interface.

You essentially need to spawn a process, read the session’s port numbers and then send messages via OSC over the local network loopback.

This could easily done from your favourite editor of choice (e.g. Emacs).

I love the new Link Audio which lets you stream and receive audio on the local network with any other Link Audio capable software such as Ableton Live.

I also like the new QuickStart Cards as a way to get started that doesn’t require reading the built-in tutorial.

That’s because Sonic Pi was originally built specifically for and in collaboration with Raspberry Pi :-)

Sonic Pi was originally written for the Raspberry Pi and shipped on their OS for many years - hence the name :-)

Sonic Pi v5 is released.

Sonic Pi is now more friendly, more accessible, more powerful and more fun.

There's something to excite everyone - from the friendlier error messages, to the pro-audio config, to the new dynamic visuals for performance.

Enjoy!

Sonic Tau is a tech demo re-imagining Sonic Pi for the web.