3.15 API mismatch warnings signal-to-noise ratio

Development
1

Is there any thought about perhaps improving the signal-to-noise ratio of the plugin API version mismatch messages?

ERROR: API version mismatch: /home/dlm/.local/share/SuperCollider/Extensions/OversamplingOscillators/TriOS.so
    This plugin is not compatible with SuperCollider >=3.15
    The plugin has not been loaded; please find or compile a newer version.
    (Plugin's API version: 3. Expected: 6)

ERROR: API version mismatch: /home/dlm/.local/share/SuperCollider/Extensions/OversamplingOscillators/OscOS.so
    This plugin is not compatible with SuperCollider >=3.15
    The plugin has not been loaded; please find or compile a newer version.
    (Plugin's API version: 3. Expected: 6)

ERROR: API version mismatch: /home/dlm/.local/share/SuperCollider/Extensions/OversamplingOscillators/BuchlaFoldOS.so
    This plugin is not compatible with SuperCollider >=3.15
    The plugin has not been loaded; please find or compile a newer version.
    (Plugin's API version: 3. Expected: 6)

ERROR: API version mismatch: /home/dlm/.local/share/SuperCollider/Extensions/OversamplingOscillators/OscOS3.so
    This plugin is not compatible with SuperCollider >=3.15
    The plugin has not been loaded; please find or compile a newer version.
    (Plugin's API version: 3. Expected: 6)

As a user, what is really of interest to me is the directory, not the specific plugin, and of course, I do not need the complete message to be repeated for every plugin.

E.g., OversamplingOscillators contains 23 plugins, but I will fix them by rebuilding one package. So that’s 4 non-blank lines of output times 23 plugins = 92 lines of output, for one useful piece of information.

I realize that in C++, it’s painful to collate data like this, but I imagine that my tolerance for sifting through redundant messaging may be higher than some other users, and even I’m finding this to be annoying.

hjh

2

The Server has no notion of a plugin “package” in the sense of a directory containing individal plugin files. Internally, the Server just recursively iterates over the folders in the extension path(s) and tries to load everything that looks like a SC plugin.

OversamplingOscillators could have just packed all their plugins in a single binary, which is exactly what the core plugins are doing. (There is hardly any reason for shipping SC plugins as individual binaries.) Then you would only get a single error message.

You’re right that we don’t have to repeat the full error message over and over again. But this would only save us 2 of 4 lines. We have to include the first and last line because these are specific to each plugin.

In conclusion, I think the problem is really the OversamplingOscillators. I think the author has been new to SC plugin development and probably just wasn’t aware that a single plugin binary can contain multiple UGen classes. I would suggest to file an issue on their repo.

3

Ok, that’s fair, thanks for the clarification.

hjh

4

I don’t necessarily think it’s worth the effort, but I think we could theoretically gather all messages in the scanning phase and post a summary at the end instead. Something like:

The following plugins are not compatible with SuperCollider >=3.15 (API version 6) and have not been loaded:
(Plugin's API version: 3)
<path>
<path>

We’d need to group plugins from potentially different API versions as separate lists for clarity.
Again, it’s probably more work than it’s worth, but may be more readable.