I love Sonic Pi. I am a terrible musician but I really enjoy finding chords for a song and then putting them into a sonic pi buffer and messing around. U2 started as a cover band, right, so maybe this is a path to becoming musical someday.
The one thing that confuses me about Sonic Pi is the buffers/editor. I always wish I could replace the UI with my own embedded editor (emacs in my case). I would then be able to manage all my songs as files. Right now I hunt for "least crowded" buffer window, comment out the code for the song or songs, and then add my new song. If I had my own embedded editor (like emacs), I could rename buffers to be songs, have an unlimited amount (rather than just ten), integrated version control, etc.
Am I missing something simple about how others use sonic pi?
The big breakthrough of sonic pi is representing music as a highly readable text file. I assume I don't know how to use the built in editor and buffer system because I feel a lot of friction there.
Does this mean I just don't understand how to use the existing UI? I'm often messing around with a bunch of chords and sounds and I quickly run out of scratch space. Does that mean I'm doing it wrong?
You can save/load the contents of a single buffer or all buffers. For a single buffer, select the buffer you want to save, then go to the Live menu and choose "Save Buffer As". To load a file into a buffer, choose the buffer you want to load it into and then go to the Live menu and select "Load into Buffer"
You can also save off all the buffers together (e.g. if you've put different parts of the same song into different buffers) by going to the Live menu and choosing "Save Set As" (or just "Save Set" if you want to overwrite what was previously in your last saved set e.g. you made changes to your song and you want to replace the previous version).
So to achieve a workflow similar to what you're describing, you construct your song (in up to ten buffers) and then save the set and clear the buffers or load a different set to work on another song. True, it doesn't give you infinite buffers, but it does give you a way to "manage all [your] songs as files".
You can then use e.g. Magit to version control the files just as you would if you were working in Emacs itself.
The sets are also saved as text files in a very human readable format; basically just all of the buffers dumped out one after another with some delimiters. You could even use Emacs to edit them and then load them into Sonic Pi to run them! (That said, I'm not sure there's a good sonic-pi-mode for things like indentation and autocomplete yet. Hopefully someday; I would love to have my custom evil-mode Emacs keybindings while working in Sonic Pi, but I get that it's not really a priority right now ;) )
I've been playing with it the last few weeks, great software and really fun to use. Fantastic timing. Thanks for all the hard work that went into the release.
I'm particularly happy to see keyboard shortcut preferences in the release notes, that's been a real pain point.
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.
if you want to attract more userbase that's probably the least meaningful copy-text someone can provide. Not only doesn't even in one sentence what sonic pi v5 is but also doesn't explain whats difference between v4 and v5 - I mean what it means more friendly/accessible/fun really?
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.
Every time I click a HN post with the Something Pi naming convention my graybeard brain expects to see an SBC. This is something just about as interesting! I grew up on (and still use) trackers for sequencing. It might be fun to try a similar workflow in this!
The SBC in question here is the Raspberry Pi — Sonic Pi was one of the early pieces of educational that made up the RPi ecosystem, and Sam Aaron was sponsored by the Raspberry Pi Foundation to write it.
Oh my pi! (Same here, yesterday I came to the conclusion that I dont understand any of the front page links. Thanks for commenters clearing it up also!)
I blame Mario for ruining me until a year ago Pi was RPi or 3.142... but yeah this is nice, I have been using daws and have written my own small piano roll app because bosca ceoil vanished a couple years ago, but this is nice too.
I think that app(bosca ceoil) is now back around among us, though I don't recall what had happened back in the day.
I don't know what you mean with this. Strudel is AGPL, which is hardly "impossible to use on anything". The default sound banks are CC-by(-sa), CC0 and unspecified. The unspecified ones might indeed be a problem, but the other ones are fine.
As long as you allow anyone to get the source code of any derivative work you make of the Strudel code, and you take some measures to keep the distribution of the two works somewhat separate, you're should be good. And yes, there's a lot of FUD by the FSF, but your pet projects shouldn't be encumbered by such a narrow reading of 'derivative work'.
I want to embed the player into standalone video game binaries that don't require internet access to download the restrictively licensed files. I'm not looking to embed music file outputs, I want the music to remain customizable on the fly.
Hi, Sam! I have to say that's a strange statement. SuperSonic still uses scsynth as its synthesis engine. How is that a "complete replacement"?
I see that you are trying to circumvent the GPL, with somewhat dubious arguments. I'm pretty sure that running scsynth in an AudioWorklet creates a combined program and not an aggregate. (I'm not the only one who has raised this concern.)
Since scsynth is the foundation of Sonic Pi, why not respect the intention of its author?
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.
> I’m also definitely not wanting to circumnavigate the GPL!
You are going to great lengths to make sure that SuperSonic (and thus scsynth) can be used by non-GPL code. You are explicitly advertising in the README:
> Your application code interacts only with the MIT-licensed client APIs and is not intended to be a derivative work of the GPL components.
What's the point of this if not circumventing the GPL?
---
Running scsynth (or a derived application) as a separate process and communicating via sockets should be fine, at least from a legal standpoint. This is what Sonic Pi resp. the native SuperSonic clients do.
The SuperSonic JS client, however, lives in the same process as the scsynth WASM module. The fact that the two modules communicate via OSC messages is not really relevant. They clearly form a single combined program and therefore must comply with the GPL.
I'm pretty sure the same applies to the Erlang module. According to the LICENSE file, the scsynth engine is implemented as a shared library that the client calls into. This would be a textbook case of a combined program.
I would ask you to change the licenses accordingly.
> 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.
> 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.
Where do you got that? The GPLv3 license text only says:
> A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit.
The JS/WASM and Erlang modules in SuperSonic are clearly combined to form a larger program. The GPL v3 does not say anything about networking protocols, "architectural boundaries" or sharing internal data structures.
The GPL v3 FAQ further clarifies:
> If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
If you use a GPL-licensed library, your whole program must comply with the GPL. That's exactly why the LGPL exists: it adds an exception to the GPL so that a library may be used in a non-GPL program. James could have licensed scsynth under the LGPL, but he did not.
> I also don’t quite know what licenses you’re asking me to change.
The license of the JS and Erlang clients because they call into scsynth code (in the same process).
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.
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.
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.
Careful! Just because you are exchanging messages via sockets does not necessarily make it a mere aggregate! Quoting the official GPL FAQ:
> By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
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.
I don't think that the SuperCollider team has an official stance on this and I can't really speak for all developers. Legally, I think you're on the safe side as long as scsynth runs in a separate process (which is the case for Sonic Pi). However, it's probably against the intentions of James McCartney. If he had wanted scsynth to be used by non-GPL programs, he would have released it under the LGPL. But that's just my assumption. If you're in doubt, just ask him :)
that too could be a basis to consider the two parts as combined into a larger program.
That would not stand up in court. This battle has been fought before. Interoperability is not a trojan horse to spread the GPL anymore than it is a trojan horse to impose copyright restrictions by private software.
Since my first pi I've always been blown away by sonic pi's capacity and it's price. Surely worth the cost of the Pi itself and then some.
It's so good I feel the rare guilt of not using it enough especially as I see myself as lifelong musically-inclined (skill level is another topic tho ...)
Genuinely grateful to Aaron and everyone who helps keep this project going. Damn near a public good IMHO
I donate to this software because it's so much fun to play around with. My wife (of 30 years as of today) knows way more about music than I do and this is one way for me to connect a little bit with her hobby.
This is one of my favorite software projects. I have played a bit with it a few years ago, and I often recommend others to play with it.
I would love to have more musical knowledge, but even with my limited resources, I can do some cool stuff.
Congratulations and thank you for your hard work all these years!
I remember years and years ago getting a Raspberry Pi from my father. We were going to use it for something or other, but that plan fell through, and I ended up using it to "deploy" my first programming project when I was around 12 or so, which was a home assistant that I was really proud of. I remember using Sonic Pi to come up with what I think was an excessive 30 or so different sounds and indicator tones for it, and a little startup jingle. Good times.
I was just working on a music improv app for the MacBook trackpad [1] and tried to use Sonic Pi 4 for the backing track (muse) generator but it was too clunky to run a full fledged second GUI alongside the app and control it through OSC.
I had to do sample retrieval, decoding, native CoreAudio logic to get acceptable latency. A programmable synth would have made my life so much easier.
supersonic-scsynth in Pi 5 feels more fit now, it’s the first time I tried a JS frontend for a macOS app but if it lets me import this and use it so easily, it already paid its dividends.
I was at a final session of Code Mesh many moons ago in London, beer in hand, Sam + Joe Armstrong on stage banging out beats with Sonic Pi - good times.
I keep wanting to learn Supercollider but I never get to. Maybe I'm more enamored of the idea of live coding than actually wanting to play this way. Sonic Pi could finally convince me!
Get Claude to come up with ideas and generate .scd files which you can launch with supercollider. Ask it to build a gui with parameters. It’s pretty good at it.
As mentioned before, the license needs to be GPL since the audio engine is clearly a derivative of SuperCollider/scsynth. I also asked the original author jmc and he is also not agreeing w/ your "network barrier" interpretation to avoid GPL.
One more thought: it might be worth checking in with people before running AI agents over their GPL code, especially in a creative coding environment.
I tried it for a few seconds but there is a huge lag between pressing a button and the sound, and half the time the button press does nothing. It's basically unusable.
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.
why is the Amen Brother breakbeat included in this software as if it's open source and GPL / MIT license? Just because something has been stolen a million times, that doesn't make it public domain, it's still under copyright and owned by its publisher, who I'm pretty certain has never given it away under a free license.
You might be correct but the link you've pasted is still of the original copyrighted breakbeat, not a recreation, on a site again falling victim to what it offers for free and Creative Commons not being free or Creative Commons.
I'd be really curious for this particular sample to go to court because unless The Winstons have been aggressively enforcing this copyright they may have already lost it to the public domain.
That's not how copyright works. There is no "use it or lose it". You legally retain control of licensing for copying and distribution, including derivative works (samples) for the full copyright duration.
There's a limit of 3 years for you to bring a copyright infringement case after a specific infringement takes place, but that doesn't stop you from bringing further cases against further infringements. You don't "lose" copyright if you fail to self-police it, as you might lose a trademark.
It gets very complicated around this specific 1969 sound recording and suing for copyright infringement, because prior to 1972, sound recordings were subject to US state law (presumably Georgia as the Holly Bee Music Co. was incorporated in Atlanta?) rather than federal law.
The drummer, Gregory Coleman, died homeless and penniless. Some UK DJs raised money for the bandleader, Richard Lewis Spencer, in 2015. He died in 2020. So there's probably not going to be anyone suing you for infringing the copyright on Amen, Brother, but it's not not infringement.
Pretty sure that aggressive defense is required for trademarks and not copyright. However it may be interesting whether or not it's still protected by copyright.
It would need to be defended in court yeah, but the absence of that defence doesn't automatically make it so it falls under the GPL and can be included in MIT licensed code just because the copyright holder doesn't know about it to defend it or refuse to be part of your software. Maybe you can argue the technicality but certainly not in the spirit of open source. There would be hundreds of other breakbeats you could include and give away under your MIT license if that were the case.
Disclaimer: I use to donate to this project when I can.
This project has been around for 10+ years and the author dedicated a big part of his life for it, and could not have done so without Patreon support, and to my understanding went through rough times while could easily have gone through a more classic career and make money.
I don't see a lot of projects around that are as interesting as it (I recommend watching old TEDs from Sam on the topic of live-coding for the why), and a commercial approach would have killed it in the first place.
So I'm more on opposite side: the level of dignity required to keep putting energy for 10+ years on a software you believe in, makes it an example to me. If Patreon is the condition for more whytheluckystiff_'s style projects, instead of the ambient slope we see around these days, I'm all for it!
For those wondering what it actually is, as I was:
https://sonic-pi.net/
"Sonic Pi is your free code-based music creation and performance tool."
Reminds me of ChucK: https://chuck.cs.princeton.edu.
I had a lot of fun with ChucK back in the day, really nice system.
I love Sonic Pi. I am a terrible musician but I really enjoy finding chords for a song and then putting them into a sonic pi buffer and messing around. U2 started as a cover band, right, so maybe this is a path to becoming musical someday.
The one thing that confuses me about Sonic Pi is the buffers/editor. I always wish I could replace the UI with my own embedded editor (emacs in my case). I would then be able to manage all my songs as files. Right now I hunt for "least crowded" buffer window, comment out the code for the song or songs, and then add my new song. If I had my own embedded editor (like emacs), I could rename buffers to be songs, have an unlimited amount (rather than just ten), integrated version control, etc.
Am I missing something simple about how others use sonic pi?
The big breakthrough of sonic pi is representing music as a highly readable text file. I assume I don't know how to use the built in editor and buffer system because I feel a lot of friction there.
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).
Hi Sam, big fan of you and your work!
Does this mean I just don't understand how to use the existing UI? I'm often messing around with a bunch of chords and sounds and I quickly run out of scratch space. Does that mean I'm doing it wrong?
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 :-)
You can save/load the contents of a single buffer or all buffers. For a single buffer, select the buffer you want to save, then go to the Live menu and choose "Save Buffer As". To load a file into a buffer, choose the buffer you want to load it into and then go to the Live menu and select "Load into Buffer"
You can also save off all the buffers together (e.g. if you've put different parts of the same song into different buffers) by going to the Live menu and choosing "Save Set As" (or just "Save Set" if you want to overwrite what was previously in your last saved set e.g. you made changes to your song and you want to replace the previous version).
So to achieve a workflow similar to what you're describing, you construct your song (in up to ten buffers) and then save the set and clear the buffers or load a different set to work on another song. True, it doesn't give you infinite buffers, but it does give you a way to "manage all [your] songs as files".
You can then use e.g. Magit to version control the files just as you would if you were working in Emacs itself.
The sets are also saved as text files in a very human readable format; basically just all of the buffers dumped out one after another with some delimiters. You could even use Emacs to edit them and then load them into Sonic Pi to run them! (That said, I'm not sure there's a good sonic-pi-mode for things like indentation and autocomplete yet. Hopefully someday; I would love to have my custom evil-mode Emacs keybindings while working in Sonic Pi, but I get that it's not really a priority right now ;) )
> I always wish I could replace the UI with my own embedded editor (emacs in my case)
Consider his his older project instead? https://overtone.github.io/
He even used to perform using emacs before he created Sonic Pi.
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!
I've been playing with it the last few weeks, great software and really fun to use. Fantastic timing. Thanks for all the hard work that went into the release.
I'm particularly happy to see keyboard shortcut preferences in the release notes, that's been a real pain point.
Thanking you kindly, sir.
Congrats on the release Sam! Looking forward to checking it out. What's your favorite new feature?
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.
I tried it. but the Flatpak seems to be missing some of the documentation.
Apologies but I’m not the maintainer of the Sonic Pi Flatpak.
Instead v5 officially supports AppImage builds.
if you want to attract more userbase that's probably the least meaningful copy-text someone can provide. Not only doesn't even in one sentence what sonic pi v5 is but also doesn't explain whats difference between v4 and v5 - I mean what it means more friendly/accessible/fun really?
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
Every time I click a HN post with the Something Pi naming convention my graybeard brain expects to see an SBC. This is something just about as interesting! I grew up on (and still use) trackers for sequencing. It might be fun to try a similar workflow in this!
The SBC in question here is the Raspberry Pi — Sonic Pi was one of the early pieces of educational that made up the RPi ecosystem, and Sam Aaron was sponsored by the Raspberry Pi Foundation to write it.
A bit confusing that `<something> Pi` developed two meanings:
- `<brand/line> Pi` as a brand/line of SBCs, with Raspberry Pi being the original
- `<anything> Pi` as a software package targeting Raspberry Pis or SBCs generally
Oh my pi! (Same here, yesterday I came to the conclusion that I dont understand any of the front page links. Thanks for commenters clearing it up also!)
I blame Mario for ruining me until a year ago Pi was RPi or 3.142... but yeah this is nice, I have been using daws and have written my own small piano roll app because bosca ceoil vanished a couple years ago, but this is nice too.
I think that app(bosca ceoil) is now back around among us, though I don't recall what had happened back in the day.
How does it compare to https://strudel.cc/ ?
For starters, strudel runs in the browser while Sonic Pi is a stand alone application.
The primary difference to me is that strudel's license is so restrictive that it's impossible to use on anything. This is MIT.
I don't know what you mean with this. Strudel is AGPL, which is hardly "impossible to use on anything". The default sound banks are CC-by(-sa), CC0 and unspecified. The unspecified ones might indeed be a problem, but the other ones are fine.
As long as you allow anyone to get the source code of any derivative work you make of the Strudel code, and you take some measures to keep the distribution of the two works somewhat separate, you're should be good. And yes, there's a lot of FUD by the FSF, but your pet projects shouldn't be encumbered by such a narrow reading of 'derivative work'.
How exactly does the license matter if you just want to make music?
I want to embed the player into standalone video game binaries that don't require internet access to download the restrictively licensed files. I'm not looking to embed music file outputs, I want the music to remain customizable on the fly.
You could make your video game source AGPL. Source code is hardly a differentiating factor these days so you'll lose nothing.
Seems like a pretty special use-case.
I don't think it'd be that special if the licenses allowed it. (Meaning I believe it'd be normal already if it were possible.)
I think the underlying Supercollider sound engine uses the more restrictive GPL, though...
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
Hi, Sam! I have to say that's a strange statement. SuperSonic still uses scsynth as its synthesis engine. How is that a "complete replacement"?
I see that you are trying to circumvent the GPL, with somewhat dubious arguments. I'm pretty sure that running scsynth in an AudioWorklet creates a combined program and not an aggregate. (I'm not the only one who has raised this concern.)
Since scsynth is the foundation of Sonic Pi, why not respect the intention of its author?
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.
Thanks for the kind response!
> I’m also definitely not wanting to circumnavigate the GPL!
You are going to great lengths to make sure that SuperSonic (and thus scsynth) can be used by non-GPL code. You are explicitly advertising in the README:
> Your application code interacts only with the MIT-licensed client APIs and is not intended to be a derivative work of the GPL components.
https://github.com/samaaron/supersonic#license
Or in the LICENSE file:
> SuperSonic is deliberately designed with a strict execution boundary between the GPL-licensed audio engine and application-level code.
https://github.com/samaaron/supersonic/blob/2652a28eb6cb51a4...
What's the point of this if not circumventing the GPL?
---
Running scsynth (or a derived application) as a separate process and communicating via sockets should be fine, at least from a legal standpoint. This is what Sonic Pi resp. the native SuperSonic clients do.
The SuperSonic JS client, however, lives in the same process as the scsynth WASM module. The fact that the two modules communicate via OSC messages is not really relevant. They clearly form a single combined program and therefore must comply with the GPL.
I'm pretty sure the same applies to the Erlang module. According to the LICENSE file, the scsynth engine is implemented as a shared library that the client calls into. This would be a textbook case of a combined program.
I would ask you to change the licenses accordingly.
> 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.
> 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.
Where do you got that? The GPLv3 license text only says:
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit.
The JS/WASM and Erlang modules in SuperSonic are clearly combined to form a larger program. The GPL v3 does not say anything about networking protocols, "architectural boundaries" or sharing internal data structures.
The GPL v3 FAQ further clarifies:
> If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
If you use a GPL-licensed library, your whole program must comply with the GPL. That's exactly why the LGPL exists: it adds an exception to the GPL so that a library may be used in a non-GPL program. James could have licensed scsynth under the LGPL, but he did not.
> I also don’t quite know what licenses you’re asking me to change.
The license of the JS and Erlang clients because they call into scsynth code (in the same process).
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.
Hi! why a port and not contribution to the original project? What were the reasons? Will this be 100% compatible in the future? Thanks!!
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.
It seems that SuperSonic also uses GPL, no?
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.
Careful! Just because you are exchanging messages via sockets does not necessarily make it a mere aggregate! Quoting the official GPL FAQ:
> By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
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.
I don't think that the SuperCollider team has an official stance on this and I can't really speak for all developers. Legally, I think you're on the safe side as long as scsynth runs in a separate process (which is the case for Sonic Pi). However, it's probably against the intentions of James McCartney. If he had wanted scsynth to be used by non-GPL programs, he would have released it under the LGPL. But that's just my assumption. If you're in doubt, just ask him :)
also keep in mind that the gnu.org want gpl to apply as widely as possible. Generally, your approach should be fine imo
that too could be a basis to consider the two parts as combined into a larger program.
That would not stand up in court. This battle has been fought before. Interoperability is not a trojan horse to spread the GPL anymore than it is a trojan horse to impose copyright restrictions by private software.
Darn, you're right. Looks like there's still no hope here.
Since my first pi I've always been blown away by sonic pi's capacity and it's price. Surely worth the cost of the Pi itself and then some.
It's so good I feel the rare guilt of not using it enough especially as I see myself as lifelong musically-inclined (skill level is another topic tho ...)
Genuinely grateful to Aaron and everyone who helps keep this project going. Damn near a public good IMHO
Congratulations on your release, Sam!
Are you still considering hardware demos, such as those on Raspberry Pi?
If anyone here also wants to try a different syntax, check out http://glicol.org/.
Yes, SuperSonic (the new internal synth and IO engine) specifically targets embedded devices, so expect some fun announcements in the future!
I donate to this software because it's so much fun to play around with. My wife (of 30 years as of today) knows way more about music than I do and this is one way for me to connect a little bit with her hobby.
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.
Congrats on the 30 years of marriage!
This looks like a lot of fun. I wish they'd name it better though, the name makes me think it's a raspberry pi related thing. or a piece of hardware.
Sonic Pi was originally written for the Raspberry Pi and shipped on their OS for many years - hence the name :-)
In the defense of Sonic Pi, the first version of it and the Raspberry Pi were released in the same year. Obviously one went on to become more popular
That’s because Sonic Pi was originally built specifically for and in collaboration with Raspberry Pi :-)
Was thinking the same.
This is one of my favorite software projects. I have played a bit with it a few years ago, and I often recommend others to play with it. I would love to have more musical knowledge, but even with my limited resources, I can do some cool stuff.
Congratulations and thank you for your hard work all these years!
I remember years and years ago getting a Raspberry Pi from my father. We were going to use it for something or other, but that plan fell through, and I ended up using it to "deploy" my first programming project when I was around 12 or so, which was a home assistant that I was really proud of. I remember using Sonic Pi to come up with what I think was an excessive 30 or so different sounds and indicator tones for it, and a little startup jingle. Good times.
Awesome to hear! So glad you had fun with it :-)
Yesss. I have been here for years. Love to see v5 finally get released. Well done, Sam! Here's to many more years. \m/
Thanks for your kind support!
I was just working on a music improv app for the MacBook trackpad [1] and tried to use Sonic Pi 4 for the backing track (muse) generator but it was too clunky to run a full fledged second GUI alongside the app and control it through OSC.
I had to do sample retrieval, decoding, native CoreAudio logic to get acceptable latency. A programmable synth would have made my life so much easier.
supersonic-scsynth in Pi 5 feels more fit now, it’s the first time I tried a JS frontend for a macOS app but if it lets me import this and use it so easily, it already paid its dividends.
[1] https://lowtechguys.com/meander
I was at a final session of Code Mesh many moons ago in London, beer in hand, Sam + Joe Armstrong on stage banging out beats with Sonic Pi - good times.
I keep wanting to learn Supercollider but I never get to. Maybe I'm more enamored of the idea of live coding than actually wanting to play this way. Sonic Pi could finally convince me!
Get Claude to come up with ideas and generate .scd files which you can launch with supercollider. Ask it to build a gui with parameters. It’s pretty good at it.
Sonic Pi or Strudel? Which is better for a music noob?
Sweet. Going to make Pi help make Pi music. Just have to vibe code some method but this will be enjoyable.
As mentioned before, the license needs to be GPL since the audio engine is clearly a derivative of SuperCollider/scsynth. I also asked the original author jmc and he is also not agreeing w/ your "network barrier" interpretation to avoid GPL.
One more thought: it might be worth checking in with people before running AI agents over their GPL code, especially in a creative coding environment.
I tried it for a few seconds but there is a huge lag between pressing a button and the sound, and half the time the button press does nothing. It's basically unusable.
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
Thanks I appreciate the response but this is not for me. I clicked "your first note" and got a runtime error "Promise timed out after 3 seconds".
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.
Someone needs to introduce this to an AI model. Have agents recreate music from scratch! :)
Is there any (somewhat) known artist who uses Sonic Pi in their actual work?
https://m.youtube.com/@dj_dave____
she started with Sonic Pi back in ~ 2020 but i guess she uses other stuff by now
Yeah those recent videos are all Strudel. Pretty amazing stuff btw.
Her opening set for Github Universe 2020 that used Sonic Pi is still so great. https://youtu.be/LaKT3pli5EQ
why is the Amen Brother breakbeat included in this software as if it's open source and GPL / MIT license? Just because something has been stolen a million times, that doesn't make it public domain, it's still under copyright and owned by its publisher, who I'm pretty certain has never given it away under a free license.
It's worth noting that the particular recording they include[0] is not the original performance, it's a CC0 (public domain) recreation of the sample.
So the recording itself has no copyright attached, but yes, there's still a question of the copyright on the composition.
[0] https://freesound.org/people/Dolfeus/sounds/43389/
You might be correct but the link you've pasted is still of the original copyrighted breakbeat, not a recreation, on a site again falling victim to what it offers for free and Creative Commons not being free or Creative Commons.
I'd be really curious for this particular sample to go to court because unless The Winstons have been aggressively enforcing this copyright they may have already lost it to the public domain.
That's not how copyright works. There is no "use it or lose it". You legally retain control of licensing for copying and distribution, including derivative works (samples) for the full copyright duration.
In this case, it's a music recording published in the USA between 1957 and 1972, so the copyright expires on 15 February 2067: https://library.mi.edu/musiccopyright/duration
There's a limit of 3 years for you to bring a copyright infringement case after a specific infringement takes place, but that doesn't stop you from bringing further cases against further infringements. You don't "lose" copyright if you fail to self-police it, as you might lose a trademark.
It gets very complicated around this specific 1969 sound recording and suing for copyright infringement, because prior to 1972, sound recordings were subject to US state law (presumably Georgia as the Holly Bee Music Co. was incorporated in Atlanta?) rather than federal law.
Ultimately, no samplers paid The Winstons any royalties. https://en.wikipedia.org/wiki/Amen_break#Royalties
The drummer, Gregory Coleman, died homeless and penniless. Some UK DJs raised money for the bandleader, Richard Lewis Spencer, in 2015. He died in 2020. So there's probably not going to be anyone suing you for infringing the copyright on Amen, Brother, but it's not not infringement.
Pretty sure that aggressive defense is required for trademarks and not copyright. However it may be interesting whether or not it's still protected by copyright.
It would need to be defended in court yeah, but the absence of that defence doesn't automatically make it so it falls under the GPL and can be included in MIT licensed code just because the copyright holder doesn't know about it to defend it or refuse to be part of your software. Maybe you can argue the technicality but certainly not in the spirit of open source. There would be hundreds of other breakbeats you could include and give away under your MIT license if that were the case.
ud expect an open source / free software project to have some dignity and not link direct to patreon. times are changing.
Disclaimer: I use to donate to this project when I can.
This project has been around for 10+ years and the author dedicated a big part of his life for it, and could not have done so without Patreon support, and to my understanding went through rough times while could easily have gone through a more classic career and make money.
I don't see a lot of projects around that are as interesting as it (I recommend watching old TEDs from Sam on the topic of live-coding for the why), and a commercial approach would have killed it in the first place.
So I'm more on opposite side: the level of dignity required to keep putting energy for 10+ years on a software you believe in, makes it an example to me. If Patreon is the condition for more whytheluckystiff_'s style projects, instead of the ambient slope we see around these days, I'm all for it!
Is it just me or does the “Pi” branding give the connotation of “underpowered, expensive and hobbyist quality”?
Suggest you drop the Pi name in your next project.