supercollider/sc3-plugins

LADSPA UGen error handling/reporting

jamshark70 opened this issue · 7 comments

jamshark70 commented

A mailing list thread on sc-users recently revealed that the LADSPA UGen (running in Linux) can prevent the server from booting, without posting any error messages:

https://www.listarc.bham.ac.uk/lists/sc-users/msg62057.html

Not sure what I broke to cause this error (I have been spending some time trying to get Windows VST's to work on my Ubuntu Studio system) but when I try to boot a server it fails and the only thing in the post window is this:

"
-> localhost
RESULT = 0
ERROR: server failed to start
For advice: [http://supercollider.github.io/tutorials/server-failed-to-start]
"

Because of the remark about VSTs under Wine, I hazarded the guess that LADSPA might be trying to get info about one or more VSTs and aborting the server in the attempt (with, incorrectly, a 0 result code). So I asked the user to rename the LadspaUGen.so files to prevent them from loading, and then the server booted normally.

Suggestions:

  • Our LADSPA UGen should ideally catch exceptions and continue without access to the specific plug-in.

  • If that's possible impossible for whatever reason, then there should be some output so that the user has some idea what the problem is. (Sorry for typos.)

  • If that is it possible impossible for whatever reason, then we should make it possible to disable the LADSPA plug-in as a build switch. (This isn't the only problem with LADSPA [#23] -- if it has bugs that render it unusable and it isn't going to be maintained, then it should be possible for users to do away with it in their own environment.)

nhthn commented

man, does anyone even use LADSPA anymore? it's kind of a dying project and the plugins i've seen for it aren't even that good...

dvzrv commented

There are some few projects (that are even still maintained), but LV2 definitely is all the rage now :)

grammoboy2 commented

I can confirm this issue in version 3.11.2 and disabling ladspa solves it. I would argue though that LADSPA is still useful especially as long as you can't run LV2 plugins in SuperCollider, but even then the simplicity of LADSPA could be a advantage.
Probably the best plugins on Linux are made by Fons Adriaensen and they're all available as LADSPA.

jamshark70 commented

Couple of questions:

A try would prevent the crash on boot. What I don't know is: If we allocate insufficient memory for the plugin search and the search segfaults because of that, would it then mean that no plugins would be accessible?

mossheim commented

plugins_size = 64; Are we 100% sure that there will never be more than 64 LADSPA plugins on a user's system?

it looks like this is just an initial size; the array is reallocated with more space later as needed: https://github.com/supercollider/sc3-plugins/blob/master/source/LadspaUGen/LadspaUGen.cpp#L116-L123

A try would prevent the crash on boot

i thought the crash is due to a segmentation fault?

jamshark70 commented

Ok, I misread and misunderstood.

So the only way to probe plugins 100% safely is to spawn them into a separate process? I think Christof's VSTPlugin does something like that.

mossheim commented

So the only way to probe plugins 100% safely is to spawn them into a separate process? I think Christof's VSTPlugin does something like that.

yes, as far as i know. i don't think it's possible to recover from a segfault signal, at least on Linux.