LADSPA UGen error handling/reporting

[jamshark70]

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]

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]

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

[grammoboy2]

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]

Couple of questions:

• https://github.com/supercollider/sc3-plugins/blob/master/source/LadspaUGen/LadspaUGen.cpp#L131 plugins_size = 64; Are we 100% sure that there will never be more than 64 LADSPA plugins on a user's system?

• https://github.com/supercollider/sc3-plugins/blob/master/source/LadspaUGen/LadspaUGen.cpp#L133 Certainly the plugin search should be in a try block, no? (Ok, that's not a question 😆 )

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]

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]

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]

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.