samaaron
Joined 17 years ago
Joined 17 years ago
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 :-)
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
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)
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.
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.
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.
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.
Thanks also for your kind support.