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

71–80 of 110 posts

Re: Sonic Pi v5

#71

Post by throwaway89201 »

herpdyderp wrote: post #13
hiccuphippo wrote: post #6

How does it compare to https://strudel.cc/ ?

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

Re: Sonic Pi v5

#74

Post by spacechild1 »

samaaron wrote: post #55
spacechild1 wrote: post #54

Earlier quoted context omitted.

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

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/ne…

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.

Re: Sonic Pi v5

#75

Post by skor »

samaaron wrote: post #39
glimshe wrote: post #19

Earlier quoted context omitted.

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! why a port and not contribution to the original project? What were the reasons? Will this be 100% compatible in the future? Thanks!!

Re: Sonic Pi v5

#76

Post by spacechild1 »

samaaron wrote: post #60
spacechild1 wrote: post #56

Earlier quoted context omitted.

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, ex…

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 :)

Re: Sonic Pi v5

#77

Post by fitsumbelay »

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

Re: Sonic Pi v5

#78

Post by samaaron »

spacechild1 wrote: post #74
samaaron wrote: post #55

Earlier quoted context omitted.

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/ne…

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/superso…

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

Re: Sonic Pi v5

#79

Post by capital-g »

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.

Re: Sonic Pi v5

#80

Post by holsee »

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.
Post reply on HN