"Sonic Pi is your free code-based music creation and performance tool."
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.
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).
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?
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 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 ;) )
Consider his his older project instead? https://overtone.github.io/
He even used to perform using emacs before he created Sonic Pi.
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'm particularly happy to see keyboard shortcut preferences in the release notes, that's been a real pain point.
Thanking you kindly, sir.
I also like the new QuickStart Cards as a way to get started that doesn’t require reading the built-in tutorial.
Instead v5 officially supports AppImage builds.
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
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/.
- `<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
I think that app(bosca ceoil) is now back around among us, though I don't recall what had happened back in the day.
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
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 completely replaced it with my own port called SuperSonic - which targets native (used in this Sonic Pi release), WASM and embedded.
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?
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.
> 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.
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.
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).
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.
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.
> 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.
I definitely don’t want to create any issues and it would be great to get some clarity here.
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.
Thanks also for your kind support.
Congratulations and thank you for your hard work all these years!