4 ms·

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 Son

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 https://github.com/samaaron/supersonic

glimshe 2mo ago
It seems that SuperSonic also uses GPL, no?
- samaaron 2mo ago
  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.
  - spacechild1 2mo ago
    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 https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
    - samaaron 2mo ago
      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.
      - fl0id 2mo ago
        also keep in mind that the gnu.org want gpl to apply as widely as possible. Generally, your approach should be fine imo
      - spacechild1 2mo ago
        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 :)
    - gamblor956 2mo ago
      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.
spacechild1 2mo ago
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?
- samaaron 2mo ago
  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.
  - spacechild1 2mo ago
    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 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/2652a28eb6cb51a4fb696fca2f04b3e073bd26c2/LICENSE#L123-L127 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.
skor 2mo ago
Hi! why a port and not contribution to the original project? What were the reasons? Will this be 100% compatible in the future? Thanks!!
- samaaron 2mo ago
  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.

glimshe 2mo ago

It seems that SuperSonic also uses GPL, no?

samaaron 2mo ago
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.
- spacechild1 2mo ago
  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 https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
  - samaaron 2mo ago
    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.
    - fl0id 2mo ago
      also keep in mind that the gnu.org want gpl to apply as widely as possible. Generally, your approach should be fine imo
    - spacechild1 2mo ago
      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 :)
  - gamblor956 2mo ago
    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.

spacechild1 2mo ago

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?

samaaron 2mo ago
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.
- spacechild1 2mo ago
  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 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/2652a28eb6cb51a4fb696fca2f04b3e073bd26c2/LICENSE#L123-L127 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.

skor 2mo ago

Hi! why a port and not contribution to the original project? What were the reasons? Will this be 100% compatible in the future? Thanks!!

samaaron 2mo ago
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.