Internal sclang and dynamically loaded libraries, drop/limit support?

[Hlöðver Sigurðsson]

Hello Overtone mailing list,

I've been having constant problems with scsynth ever since I started hacking on the Overtone sources. I will list the benefits of the internal scsynth

PROS:

1. It makes Overtone depend on less libraries

2. It gives Overtone a base of stability, the bundled scsynth would work as the stable supercollider release and unexpected errors in relation with supercollider should only be expected from external synths.

3. Faster setup in Workshops and for beginners.

CONS:

1. The environment which the java process is started can't conflict with the pre-compiled shared library files, resulting in cryptic errors.

2. The pre-compiled library files may totally conflict with other system dependencies.

3. Java Native Access creates it's own native context, in which conflicting symbols can cause cryptic errors, hence, in most cases, muiltiple JNA processes won't work (given that they both require libstdc++.6.so).

Possible alternatives

1. Just support the external synth and document jack and supercollider installation toroughly

2. Experiment with the new java hoptspot JVMCI and see if supercollider gets LLVM support in the future, enabling GraalVM support instead of JNA.

3. Continue supporting bundling scsynth, but remove libstdc++, libjack and libsndfile (use the system wide installations for those).

[joa...@verona.se]

My preference would be to move the complexity of using an external
scsynth to some kind of installer. If this worked well, the internal
scsynth could then be dropped.

My reasoning is mostly that it seems difficult to maintain the internal
scsynth, and the various linux distros already package scsynth.

OTOH I have never managed to get the external scsynth to works as
conveniently as the internal one, so I guess some work remains in that
area.



--
Joakim Verona
joa...@verona.se