Removing internal SuperCollider

Skip to first unread message

Arne Brasseur

Nov 23, 2023, 4:23:57 AM11/23/23
to Overtone
The idea has been floated a few times to remove the internal/embedded SuperCollider from Overtone (libscsynth), and only leave the option of starting or connecting to an external scsynth.

Sam has also pitched in in a PR comment stating he's in favor, and I'm personally in favor as well. But before I start ripping it out I figured it would be good to bring it up here for deliberation.

Why? The embedded scsynth is one of the biggest sources of complexity in the project. We need to compile and package it ourselves for at least three operating systems/architectures, which requires access to Xcode and Visual Studio. That build process is undocumented, and there's no one left who understands it.

This has meant a number of accumulated issues, like no support for Mac M1/M2, or windows 64 bit. On Linux the extra plugins are missing, no ARM support for SBCs, etc.

To load libscsynth into the JVM we need JNA (or one of its alternatives), which is obscure and error prone. The code currently uses badigeon and tools.deps to unpack and figure out the path with native libraries, which massively blows up our dependencies. Transitively we're looking at 89(!) dependencies (see Without these this reduces to about 10.

When it goes wrong it goes wrong spectacularly, crashing the JVM. For instance on Linux if you try to load, but SuperCollider can't find a Jack server, then you get a JVM crash. That's not a very friendly user experience.

In theory it's nice that people don't have to think about SuperCollider, but it goes wrong often enough that it actually backfires. People want to try Overtone, it blows up in their face, and they decide it's not worth the trouble.

I think instead we should be more explicit, and help people figure out their supercollider setup. On most systems a simple install with the preferred package manager would be enough for us to find `scsynth` on the PATH and we can take it from there.

Removing it would allow us to immediately close a good few of the 100+ open issues, and focus our efforts on making the rest of Overtone better. So that's the proposal, remove all the JNA/libscsynth/internal stuff, default to trying to start and connect to an external scsynth, and if we don't find it on the PATH, then we print out a friendly message with a link to installation instructions.

Nov 23, 2023, 6:55:37 AM11/23/23
to Arne Brasseur, Overtone
I vote in favour of removing the inbuilt Scsynth, and instead make some
wrappers to manage an external Scsynth. This doesn't need to happen
overnight though.

Removing complex native stuff could presumably make Overtone more
compatible with other Clojure implementations like Clojurescript and

Joakim Verona

Bill Allen

Nov 23, 2023, 7:47:40 AM11/23/23
to Overtone

I’m in favor of this proposal for the reasons given and I’ll add one: understanding Supercollider at least on basic start/stop basis is worthwhile. It’s even more worthwhile to get to know it more deeply since it’s and incredibly powerful system on its own.

You received this message because you are subscribed to the Google Groups "Overtone" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Tristan Strange

Nov 23, 2023, 9:02:21 AM11/23/23
Yes please! Thanks for all the work you're doing @joakim and crew!

I'd like to see independence from different server versions! I want to build ugen graphs for my Bela Board (which has bespoke UGens) using Overtone! Perhaps for a later PR though? 

07562 304196

Arne Brasseur

Nov 26, 2023, 3:35:54 AM11/26/23
> make some wrappers to manage an external Scsynth

What kind of wrappers are you thinking of?

> I'd like to see independence from different server versions! I want to build ugen graphs for my Bela Board (which has bespoke UGens) using Overtone! Perhaps for a later PR though?

To some extent we have that, you can connect to pretty much any supercollider server, it all uses the same OSC protocol. For custom UGens you'd have to add definitions for those, which I don't think is easy right now or well documented, so there's certainly work to be done to make that easier.

Arne Brasseur
Gaiwan GmbH
Reply all
Reply to author
0 new messages