Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sonic Pi v5

patreon.com

Post reply on HN
Print view View original

91–100 of 110 posts

Re: Sonic Pi v5

#91

Post by aimxhaisse »

uwagar wrote: post #89

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!

Re: Sonic Pi v5

#93

Post by samaaron »

skor wrote: post #75
samaaron wrote: post #39

Earlier quoted context omitted.

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! 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.

Re: Sonic Pi v5

#95

Post by samaaron »

chaosprint wrote: post #94

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!

Re: Sonic Pi v5

#98

Post by kibibu »

herpdyderp wrote: post #33
spacechild1 wrote: post #30

Earlier quoted context omitted.

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.

Have you tried asking permission to do that?

The authors may be open to dual-licensing

Re: Sonic Pi v5

#100

Post by spacechild1 »

samaaron wrote: post #85
spacechild1 wrote: post #83

Earlier quoted context omitted.

> 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 larg…

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 seri…

> 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.

You won't convince anyone that a WASM module running in an AudioWorklet should be considered a separate application.

If you respect the SuperCollider project, you should also respect its license. The virality of the GPL is the point. Instead of trying to find loopholes, just follow the spirit of the license.

> Also, the JS and Erlang clients are entirely my own code and copyright surely their licence isn’t in question.

Those parts that do not directly reference scsynth code (or derived code) can indeed be released under the MIT license.

However, SuperSonic as a whole must be licensed under the GPL since it's a combined work and not a mere aggregate.

> 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.

Yes, but your approach with SuperSonic is not. In fact, it seems like you are actively encouraging other people to embed scsynth without following the GPL:

> 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

> It is the project author's good-faith interpretation that application code which uses the MIT-licensed client libraries solely to send and receive OSC messages with the engine would generally not constitute a derivative work of the GPL-licensed audio engine

https://github.com/samaaron/supersonic/blob/2652a28eb6cb51a4...

You are correct that the client libraries themselves might not be derivatives of the GPL-licensed scsynth code (although I'm skeptical about the Erlang client), but using these libraries together with the scsynth code clearly forms a combined work and thus falls under the GPL. This is not communicated at all in the LICENSE file and only hinted at in the README.

You can easily get rid of all this ambiguity and potential confusion by licensing SuperSonic under the GPL. You can still keep individual modules as MIT.

Post reply on HN