SC only half-recognizes sc3-plugins

In a nutshell

I’ve got scide installed and making noise. I’ve built sc3-plugins and symlinked it to my user Extensions folder. The existence of that symlink causes SC to treat the names of UGens from sc3-plguins differently, as if it knows something about them – but SC tells me they aren’t installed.

Details

I’m testing sc3-plugins by evaluating a piece of code from the documentation for Decimator, which a part of sc3-plugins. Without the symlink to SC3Plugins, if I evaluate this:

{Decimator.ar(SinOsc.ar([400, 404], 0, 0.2), MouseX.kr(0, 44100), MouseY.kr(0, 31))}.play

I get the error I expected:

ERROR: Class not defined.
  in interpreted text
  line 1 char 10:

  {Decimator.ar(SinOsc.ar([400, 404], 0, 0.2), MouseX.kr(0, 44100), MouseY.kr(0, 31))}.play

With the symlink in place, I get a different error:

exception in GraphDef_Recv: UGen 'Decimator' not installed.
*** ERROR: SynthDef temp__1 not found
FAILURE IN SERVER /s_new SynthDef not found

Thus, SC does seem to be recognizing the existence of the symlink from Extensions to SC3Plugins. It appears to be finding the word “Decimator” in the SC3Plugins folder. I believe that because, if I replace the word Decimator with the word GibberishNonsenseFlimflammery, then the existence of the symlink has no effect; I get the first Class not defined error regardless of whether the symlink is in place or not.

So even though it’s finding the word Decimator in SC3Plugins, SC is not actually using the Decimator.

Is there some extra step, after putting the SC3Plugins in the Extensions folder, required in order to actually install those things?

Possibly relevant: I’m using NixOS

I described in my post on Saturday what I did to install SC and sc3-plugins. At that point I thought it was a Nix problem, but now I don’t. Also I think maybe nobody tried to answer my post because they thought they’d have to know a lot about Nix. That’s why I’ve created this second post. I hope that’s okay.

What you see is that sclang can see the plugins, but the server (scsynth/supernova) does not.
The solution is to also link the ugens to the proper directory - IIUC on Linux it seems to be lib${LIB_SUFFIX}/SuperCollider/plugins, looking at SC’s CMakeLists.txt.

Well that’s a pickle – on NixOS installed programs are immutable. Is there anything outside of the SC installation (in my home folder, say) that I can modify in order to point the server at the plugins?

(If not, it means the SC and sc3-plugin installations are mutually recursive; neither can be built before the other. I can try to do some kind of Nix-fu to declare them both in the same expression, but I’m still a yellow belt at best.)

There’s a server command line option for it:

http://doc.sccode.org/Classes/ServerOptions.html#-ugenPluginsPath

The catch with this is that you have to specify all plug-in locations. Using this option means that the default locations will not be searched, unless you include the default locations in the string. But that’s not too difficult a requirement to satisfy.

hjh

In your first post you wrote that you symlinked SC3-plugins into Extensions. Can’t you also symlink them to lib/SuperCollider/plugins directory? (please check whether that’s the right directory on your system, it should already exist and have the regular plugins installed)

EDIT: I haven’t checked myself whether this works :slight_smile:

There’s a server command line option for it:

This looks promising! Thanks, @jamshark70!

But I’m stumped. I’ve created links to all the folders called “plugins” that I can find. I evaluate the following to boot:

s.options.ugenPluginsPath = "~/local/share/SuperCollider/Extensions/";
s.boot;

and am told that Control is not installed:

    Booting server 'localhost' on address 127.0.0.1:57110.
    *** ERROR: open directory failed '/home/jeff/local/share/SuperCollider/Extensions/': No such file or directory
    JackDriver: client name is 'SuperCollider'
    SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024
    JackDriver: connected  SuperCollider:out_1 to system:playback_1
    JackDriver: connected  SuperCollider:out_2 to system:playback_2
    SuperCollider 3 server ready.
    JackDriver: max output latency 42.7 ms
    Requested notification messages from server 'localhost'
    localhost: server process's maxLogins (1) matches with my options.
    localhost: keeping clientID (0) as confirmed by server process.
    exception in GraphDef_Recv: UGen 'Control' not installed.
    exception in GraphDef_Recv: UGen 'Control' not installed.
    exception in GraphDef_Recv: UGen 'Control' not installed.
    ... <four pages of that same message> ...
    exception in GraphDef_Recv: UGen 'Control' not installed.
    exception in GraphDef_Recv: UGen 'Control' not installed.
    exception in GraphDef_Recv: UGen 'Control' not installed.
    Shared memory server interface initialized

When I search the SC installation for anything called Control, I find two things, but neither is a plugin:

./share/SuperCollider/SCClassLibrary/Common/GUI/PlusGUI/Control
./share/SuperCollider/SCClassLibrary/Common/Control

@MarcinP wrote:

Can’t you also symlink them to lib/SuperCollider/plugins directory?

I can’t, because that’s part of the SC installation. I was able to link into ~/.local/share/SuperCollider/Extensions because that’s part of my user data, which is mutable. On NixOS, installed programs are immutable.

That might sound like a limitation, but it’s what lets NixOS do its magic. You can have more than one version of something installed, and different programs depending on different versions of the same thing can work together. And you never have to install anything that’s packaged; you just state in your configuration that you want it present and rebuild your system, and adding the new thing never breaks anything else. NixOS really is wonderful if you stick to packaged things. But once you need to package something yourself, it can take some thinking. Fortunately, even then, the thinking only needs to be done once per package. Once a package works, it works forever. (At least that seems to be true. I’m not an expert.)

I can’t, because that’s part of the SC installation. I was able to link into ~/.local/share/SuperCollider/Extensions because that’s part of my user data, which is mutable. On NixOS, installed programs are immutable.

You should be able to use a user directory for that, but again, I’m not exactly sure which one that is. It’s separate from Extensions. I’d try ~/local/share/SuperCollider/plugins or maybe ~/share/SuperCollider/plugins

As for trying to specify a path - the second line of your output says
*** ERROR: open directory failed '/home/jeff/local/share/SuperCollider/Extensions/': No such file or directory
so… it doesn’t look like SC was able to open this path.

As for checking for filenames of ugens - we currently have multiple ugens in a single file in most cases. You can see an actual list of files in the source.

Perhaps path needs to be fully qualified…?

s.options.ugenPluginsPath = "~/local/share/SuperCollider/Extensions/".standardizePath;

Haven’t tried but this is a common thing in SC (e.g. loading a buffer from “~/blah.wav” won’t work even if the file exists, but "~/blah.wav".standardizePath would).

hjh

Progress! Thanks for the advice! Making the path absolute helped. Changed local to .local (doh!) helped too. Now the link to the plugins in the SuperCollider installation appears to be working. The link to the SC3-plugins, though, is being recognized but not working.

Here’s the script I’m testing with:

// Boot
s.options.ugenPluginsPath = "/home/jeff/.local/share/SuperCollider/Extensions/"
s.boot;

// Builtin, works
{ RLPF.ar(Pulse.ar([100,250],0.5,0.1), XLine.kr(8000,400,5), 0.05) }.scope(1);

// Something from SC3-plugins
{Decimator.ar(SinOsc.ar([400, 404], 0, 0.2), MouseX.kr(0, 44100), MouseY.kr(0, 31))}.play

I have these links in my local Extensions folder:

jeff@jbb-dell:Extensions$ pwd
/home/jeff/.local/share/SuperCollider/Extensions
jeff@jbb-dell:Extensions$ ls -l
plugins -> /nix/store/22jyx8mm6ynlxcxwaaabyxvvwq5dss4c-supercollider-3.11.2/lib/SuperCollider/plugins
SC3plugins -> /nix/store/591z795zn2na6q0976b3ix0lk5nywgkv-sc3-plugins-3.11.1/share/SuperCollider/Extensions/SC3plugins

The passage marked “Boot” works; it no longer produces the UGen 'Control' not installed. error. (If I delete the plugins link, leaving only SC3plugins, then booting that way does produce that error. That’s why I think the plugins link works.)

And the passage marked “Builtin, works” produces sound.

The passage marked “Something from SC3-plugins” produces this:

  -> Synth('temp__4' : 1006)
  exception in GraphDef_Recv: UGen 'Decimator' not installed.
  *** ERROR: SynthDef temp__4 not found
  FAILURE IN SERVER /s_new SynthDef not found

But if the symlink to SC3plugins is not present, I get a different error:

ERROR: Class not defined.
  in interpreted text
  line 1 char 10:

  {Decimator.ar(SinOsc.ar([400, 404], 0, 0.2), MouseX.kr(0, 44100),MouseY.kr(0, 31))}.play

-----------------------------------
-> nil

That’s why I think the symlink to SC3plugins is being recognized but not working.

I tried creating more plugins folders, with the same symlinks described above, at these new paths:

/home/jeff/.local/share/SuperCollider/plugins
/home/jeff/.config/SuperCollider/plugins

But the resultinig error did not change. (My system doesn’t have ~/share or ~/.share folders, so I didn’t try making links in those placese.)

Plug-ins have two parts:

  1. The server-side binary plug-in. In Linux, these usually have an .so extension.
  2. The language-side class interfaces, which must have an .sc extension.

In Ubuntu, make install for SC3plugins installs:

  • #1 to /usr/local/lib/SuperCollider/plugins/
  • #2 to /usr/local/share/SuperCollider/Extensions/SC3plugins/

It looks like you have symlinked only the language side class files, but not linked the binaries.

This is consistent with the behavior you observed: SC does not complain that the class is not defined, but it does complain that the server couldn’t find the plug-in.

ugenPluginsPath only concerns the server-side binaries. So it isn’t quite relevant to link the class files into this location.

So I’d suggest the following:

  1. Find the SC3plugins .so files.
  2. Symlink this location into whichever place you want to use (the ugenPluginsPath).
  3. There’s no need to symlink the class files into the same place, but do one of the following:
    • Symlink the class files into your user extension directory (which you already did).
    • Or add the path to the language configuration – either use the IDE preference panel > Interpreter, or LanguageConfig.addIncludePath("... the path ..."); LanguageConfig.store; and recompile the class library. (As before, this path shouldn’t use "~".)

I think this should cover all the bases, but I’m not trying this on a NixOS system, so this might overlook something.

hjh

1 Like

Thanks, @jamshark70! I tried to do, and hopefully did, what you suggested.

My latest configuration

In my User Extensions folder, /home/jeff/.local/share/SuperCollider/Extensions, I’ve now got the following symlinks:

plugins                 -> /nix/store/...-supercollider-3.11.2/lib/SuperCollider/plugins
SC3plugins              -> /nix/store/...-sc3-plugins-3.11.1/share/SuperCollider/Extensions/SC3plugins
SC3-plugin-so-files     -> /nix/store/...-sc3-plugins-3.11.1/lib/SuperCollider/plugins

(I’ve replaced a long hash with an ellipsis to make that easier to read.)

The new symlink, SC3-plugin-so-files, is to the only folder in the sc3-plugins installation that has .so files, which has no other kind. I believe that covers steps 1 and 2 of your instructions.

The plugin symlink is similar: It’s the only folder in my SuperCollider installation that contains .so files, and it contains nothing else.

The second symlink, SC3plugins, is different. It contains a lot of folders, each of which can have any number of .sc and .schelp files, and any kind of tree structure – for instance, one of the smallest looks like this:

└── VOSIMUGens
    ├── HelpSource
    │   └── Classes
    │       └── VOSIM.schelp
    └── VOSIM.sc

Is that what you were talking about when you said that I should (either do something else or) “Symlink the class files into your user extension directory (which you already did).”

The result

Booting SC from either the command line or scide, I now get this error:

Booting server 'localhost' on address 127.0.0.1:57110.
*** ERROR: dlopen '/home/jeff/.local/share/SuperCollider/Extensions/SC3-plugin-so-files/StkUGens.so' err '/nix/store/jsp3h3wpzc842j0rz61m5ly71ak6qgdn-glibc-2.32-54/lib/libc.so.6: version `GLIBC_2.33' not found (required by /home/jeff/.local/share/SuperCollider/Extensions/SC3-plugin-so-files/StkUGens.so)'
Server 'localhost' exited with exit code 0.

Is this still a SuperCollider problem, or should I go back and ask the NixOS guys why SC can’t find the libraries it expects?

Believe it or not, this is actually an improvement. It tells you that the server is now reading the SC3plugins .so files, where it wasn’t before.

The details of the error are important: “version ‘GLIBC_2.33’ not found” – this points to a system library problem, not strictly a SuperCollider problem.

TBH I’m out of my depth when it comes to system libraries in NixOS, because I’ve never used it. In Ubuntu, a similar problem could likely be solved by installing a package.

I do find a thread on the NixOS forum: `GLIBC_2.33` not found, although it is installed - Help - NixOS Discourse

hjh

It works! I just had to upgrade to nixos-unstable.

And I think I know what the problem was. nixos-stable uses SC 3.11.2, whereas unstable uses 3.12.1. I had installed SC through the nixos-stable channel, but the way I built sc3-plugins was by adding a package to the latest version of nixpkgs, which is (roughly? exactly?) equal to the nixos-unstable channel, and which uses 3.12.1. That newer version, I imagine, is what depends on glibc 2.33.

I opened a pull request. With any luck this will soon be packaged for NixOS, at which point someone will be able to install SC and SC3-plugins just by adding the words SuperCollider and sc3-plugins to their configuration file and rebuilding.

Many thanks, @jamshark70 and @MarcinP!

Hi all,

I’m running into this problem as well, however on I’m on os X Catalina (10.15.7), and I’m stumped as to how to fix it.

I copied the sc3-plugins folder to my Platform.userExtensionDir as described in the installation instructions and supercollider seems to be aware of their existence (I can see the help files and it shows up as installed in the quarks dialog window), but when I try and run this example from the documentation:

b = Buffer.alloc(s, 100);
b.zero;
b.set(33, 1.034);
// This should detect the 33rd value as the highest...
q = {BufMax.kr(b).poll}.play;

I get a similar error:

-> Synth('temp__8' : 1005)
exception in GraphDef_Recv: UGen 'BufMax' not installed.
*** ERROR: SynthDef temp__8 not found
FAILURE IN SERVER /s_new SynthDef not found

I’ve tried to follow along with the suggestions in the post as best I could with no luck. I made it up to the point of editing

s.options.ugenPluginsPath = "/Users/elarrieu/Library/Application Support/SuperCollider/Extensions

and I get a similar error saying

exception in GraphDef_Recv: UGen 'Control' not installed.

After that, the discussion seems to diverge a bit from my situation into what seems to be Linux-specific suggestions, so I stopped short of trying to create the synlinks as described.

Also possibly relevant, I’m on a work computer, so I only have access to Platform.userExtensionDir and not Platform.systemExtensionDir (and the systemExtensionDir doesn’t even exist on my machine), so I’m unable to try moving the folder to that location.

I feel like I must be missing some basic step, any idea what it could be? Thanks!

As @jamshark70 has pointed out, ugenPluginsPath needs to contain the paths to all plugins you want to use, including the core plugins. On macOS, the core plugins are inside the application bundle.

But in your case you shouldn’t have to fiddle with ugenPluginsPath in the first place. If you install sc3-plugins in your userExtensionDir, it should just work.

Just to make sure: did you download a sc3-plugins release (Releases · supercollider/sc3-plugins · GitHub)? Maybe you accidentally just downloaded the source code (which doesn’t contain binaries).

1 Like

Just to make sure: did you download a sc3-plugins release (Releases · supercollider/sc3-plugins · GitHub )? Maybe you accidentally just downloaded the source code (which doesn’t contain binaries).

Ughh… that was the problem, I had a feeling it was something stupid like that… Thanks @Spacechild1!

1 Like

Just in case anybody uses this thread as a reference in the future:

I’ve been using Lily Foster’s supercollider-with-sc3-plugins package. Since switching to it, everything just works – no need to pfaff around with ugenPluginsPath or anything.