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
.scxin 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?