3.15 '.so extension has been deprecated'

1 
*** WARNING: '/home/dlm/.local/share/SuperCollider/Extensions/GrainUtils/Disperser/linux/Disperser_scsynth.so': the .so extension has been deprecated!

BuFFT, GrainUtils, OversamplingOscillators and PortedPlugins are affected – possibly others.

  • OK, SC sources have been updated to build scx files.
  • sc3-plugins sources have not been updated for scx, but somehow the server doesn’t issue deprecation warnings for those .so files.
    • But it also doesn’t load the plugins. In an earlier thread, it was said that it was necessary only to recompile sc3-plugins, but that isn’t true. Sc3-plugins needs to build the right extension.
  • .so files in user-level Extensions get complaints.

Before 3.15 is released, we should try to reduce this kind of static: 1/ For authors of plugin packages, what exactly should they do to update their cmake configs? 2/ For users, how should they deal with it if the author of a plugin pack doesn’t update for some reason? 3/ Fix sc3-plugins.

hjh

2

sc3-plugins sources have not been updated for scx, but somehow the server doesn’t issue deprecation warnings for those .so files.

So you’ve manually rebuild sc3-plugins but they just don’t load? That definitely shouldn’t happen. Can you post the file structure of your extension directory/directories?

.so files in user-level Extensions get complaints.

I assume by “user-level” you mean “third-party”? sc3-plugins are also third-party, so I don’t understand why they should behave differently from other third-party plugins like GrainUtils or PortedPlugins.

1/ For authors of plugin packages, what exactly should they do to update their cmake configs?

Where would you put this information?

2/ For users, how should they deal with it if the author of a plugin pack doesn’t update for some reason?

This is actually explained in the warning message: “… To suppress this warning in the meantime, you can manually change the extension to .scx”.

3/ Fix sc3-plugins.

Will do!

3

Yes. My sc3-plugins are in the default systemwide location, /usr/local/lib/SuperCollider/plugins.

When loading my production environment, I get:

exception in GraphDef_Recv: UGen 'RLPFD' not installed.
exception in GraphDef_Recv: UGen 'DWGPluckedStiff' not installed.
exception in GraphDef_Recv: UGen 'DWGPluckedStiff' not installed.
exception in GraphDef_Recv: UGen 'DPW3Tri' not installed.
exception in GraphDef_Recv: UGen 'DPW3Tri' not installed.
exception in GraphDef_Recv: UGen 'DPW3Tri' not installed.
exception in GraphDef_Recv: UGen 'DPW3Tri' not installed.
exception in GraphDef_Recv: UGen 'DPW3Tri' not installed.
exception in GraphDef_Recv: UGen 'DWGPlucked2' not installed.
exception in GraphDef_Recv: UGen 'StkInst' not installed.
exception in GraphDef_Recv: UGen 'DWGBowed' not installed.
exception in GraphDef_Recv: UGen 'AY' not installed.
exception in GraphDef_Recv: UGen 'DWGPluckedStiff' not installed.

Plus a couple others, but these are the ones in sc3-plugins.

I assume by “user-level” you mean “third-party”? … I don’t understand why they should behave differently

I mean, in the user extension directory, not the system-wide extension dir. And they do behave differently: none of them load, but only some of them fail silently.

Where would you put this information?

This, I’m not sure, but there will need to be some better messaging.

This is actually explained in the warning message: “… To suppress this warning in the meantime, you can manually change the extension to .scx”.

SNR again, I guess: dozens of lines of “this file failed,” only one of this workaround.

But I’ll do that next time – I’ll need to roll back to 3.14 because of an issue that isn’t currently possible to workaround.

hjh

4

Yes. My sc3-plugins are in the default systemwide location, /usr/local/lib/SuperCollider/plugins.

Thanks, this explains everything. The current logic for skipping .so files is:

  • did we find any .scx in this directory or any parent directory?
    • yes → skip the file
    • no → attempt to load the file and print the deprecation warning

This works fine with “user-level” extensions because they reside in separate folders. The issue with the system-wide “sc3-plugins” is that it just throws the plugins in the same directory as the core plugins. Since the core plugins already have the new .scx extension, the sc3-plugins are skipped.

I think I just have to disable the skipping logic for the search paths themselves, i.e. only apply the logic when we are in at least one subdirectory. In theory, this can cause issues if the user adds a user-level plugin directory directly to the UGen plugin paths, but I don’t think this is very likely. Since this the deprecation mechanism is only temporary, this might be an acceptable workaround.

The other option would be to explicitly disable the skipping logic for the /usr/lib/SuperCollider/plugins and /usr/local/lib/SuperCollider/plugins paths, but this feels rather awkward.

This, I’m not sure, but there will need to be some better messaging.

Honestly, I think we can expect plugin authors to fix their own CMakeLists.txt. The change is really trivial.

I would just make an announce when SC 3.15 is released, probably as part of the official release notes, and also add a note to the change log.

In 3.15 API mismatch warnings signal-to-noise ratio - #2 by Spacechild1 you have complained that we’re repeating the same error message over and over again.

Here I actually only print the verbose message only once, exactly to reduce the SNR. What do you want me to do here?

5

That’s fine – to clarify, I’m just reporting static that I encountered during an (admittedly premature) upgrade, so that solutions can be prepared for the eventual release. It’s quite natural for sc devs to focus on core and sc3-plugins; I had problems with third party libs, and I guess others might have those problems too.

Touché :laughing: yeah, ok. I guess the point here is: in the other case, some non-critical information is repeated ad nauseam, and in this one, critical information is presented once and overlooked.

Or I’m just slipping and I need to attach an LLM agent to my SC post window :wink:

In any case, it’s on me to read the output, which I didn’t do very carefully. I’m not accustomed to that number of warnings during server boot, though.

hjh

6

I had problems with third party libs, and I guess others might have those problems too.

I will definitely add instructions to the release notes! After all, it’s not only for plugin developers, but also for power-users like yourself who can then just fix the CMakeLists.txt themselves (and ideally also make a PR to the upstream repo :slight_smile: )

I guess the point here is: in the other case, some non-critical information is repeated ad nauseam, and in this one, critical information is presented once and overlooked.

I see. So the issue is really with the many error messages caused by the OversamplingOscillators.

7

The issue with .so plugins in the system-wide plugins folder should be fixed with server: do not skip .so files in 'top-level' directories by Spacechild1 · Pull Request #7484 · supercollider/supercollider · GitHub. Please test!

8

And here’s a PR to the sc3-plugins repo for updating the plugin extension: set plugin extension to .scx on all platforms by Spacechild1 · Pull Request #428 · supercollider/sc3-plugins · GitHub

1 Like