It’s not always good practice to let JACK autoconnect, for instance when using session management on Linux and you let the session manager patching restoring tool, restore the connections for you.
I think you can let jackd ignore all self connect requests (--autoconnect a), but I think it should be possible to tell SuperCollider to not attempt to make any autoconnections without explicit instructions.
Booting server 'localhost' on address 127.0.0.1:57110.
...snip...
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024
... here we go...
JackDriver: connected SuperCollider:out_1 to system:playback_1
JackDriver: connected SuperCollider:out_2 to system:playback_2
SuperCollider 3 server ready.
Missing are the “connected system:capture” lines.
qjackctl:
… note the lack of connections to the “in” ports.
When I start SC, "SC_JACK_DEFAULT_INPUTS".getenv returns "system". In that case, the connections are made. If I override this with an empty string, then automatic connections are not made.
dlm@dlm-21cx:~$ scsynth -u 57110 -a 1024 -i 2 -o 2 -m 524288 -R 0 -C 1 -l 1
... snip...
JackDriver: client name is 'SuperCollider'
... NO CONNECTIONS HERE...
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024
SuperCollider 3 server ready.
On my system, when these environment variables are unset, no connections are made. Confirmed in qjackctl – there’s a freestanding “SuperCollider,” totally unconnected.
But, same console window:
$ sclang
compiling class library...
... snip...
*** Welcome to SuperCollider 3.14.0-dev. *** For help type ctrl-c ctrl-h (Emacs) or :SChelp (vim) or ctrl-U (sced/gedit).
sc3> "SC_JACK_DEFAULT_INPUTS".getenv
-> system
So it looks like sclang sets a default value when it starts up, which will take effect if you don’t override it. But you can override it.
(BTW I’m puzzled by your statement that “it doesn’t work” – it does work here. Typically “it doesn’t work” is unhelpful for troubleshooting because it omits the crucial details of what you actually did, and what actually happened.)
I second that. But if you use a small program like jmess, you can restore all connections the way you want. It’s all saved in an XML file, it’s so handy. In any case, you’re right.
(Another small program that can fit well with SC is non-mixer which can receive some outputs from supercollider. It supports ambisonics, and plugins, and each strip is a separate jack client, which means they are parallelized among your cpus. Also, can be controlled and send information using OSC)
Fortunately SC does provide a way to disable autoconnect, as noted in my earlier post. So there’s not really anything to second – non-autoconnect is a valid use case, which we support.
It’s at the end of the README_LINUX.md file. Maybe one supposed everyone read it once? But if someone writes good documentation in a help file, it could be an improvement.
Agreed – the statement “If these (env vars) are not set, SuperCollider will default to connecting SuperCollider’s inputs and outputs to your system’s inputs and outputs” is simply false. At minimum, this needs to be corrected.