LADSPA volunteers wanted!


#1

For reasons that some of you may be able to guess, I’d like to add a LADSPA plugin hosting class to JUCE…

Linux is the OS I know the least, and I’ve actually never done any audio work on it, so I’m a bit out of my depth when it comes to how plugins work on there. If I was to start the ball rolling with a half-finished LADSPA class, would anyone be interested in helping me get it working?


#2

FYI, I’ve quickly thrown together a basic LADSPA class, which seems to vaguely work, but I’ve not yet had chance to look at how to do the GUI stuff… Any insight from experienced linuxers would be welcome!


#3

Should be fast, there is no gui in ladspa ! dssi plugins are ladspa + gui + midi , though. And then there is LV2, you will certainly get requests for that if you do ladspa. You may want to check http://www.anticore.org/jucetice/?page_id=4 and https://github.com/falkTX/Carla I guess.


#4

… thanks. Well, I guess that illustrates how much I know about linux plugins!


#5

Seems to work fine. The ladspa plugins that load work fine, does that don’t bring down the entire plugin host with a seg fault. A restart will show the bogus plugins in the plugin window.


#6

Here’s a minor fix, simply checking if the handle returned in instantiate() call is valid or not:
https://github.com/falkTX/DISTRHO/commit/c6f9de8e4a6e8b70db95bb258e60b50029cfa89b

Some plugins still crash when closed, not sure what’s going on there…


#7

Another one, now to check LADSPA_PATH variable and use it if set:
https://github.com/falkTX/DISTRHO/commit/c340f62557a1a4a0aa80f48bae3bbe84ce62e9fa

It’s very weird that Juce wants to use “;” as directory separators on non-Windows systems though.
Both Linux and MacOS should be using “:”.

EDIT: we might as well fix the default path per spec too:
https://github.com/falkTX/DISTRHO/commit/eb62d6ecc9d0ef3011ed057eca9cb549ed373e90


#8

I did the same “fixes” for linux VST hosting:
https://github.com/falkTX/DISTRHO/commit/35b9910b28226648b6f16717ca226d6d83891956

Because I don’t want to make this thread full of my commits, I’ll be doing some fixing and you can grab the changes here:
https://github.com/falkTX/DISTRHO/commits/master


#9

This is great falkTX. Thanks for sharing your work.


#10

Cool stuff, many thanks! Will merge…


#11

Here’s another fix:
https://github.com/falkTX/DISTRHO/commit/808aac2afdc43a5b546c79c89db010972de03973

Someone forgot to call activate/deactivate on those plugins…
Also, to make some of them not crash, we force-call those when initializing them. This fixes most of the plugin crashes (but not all).


#12

Fix for that last commit:
https://github.com/falkTX/DISTRHO/commit/c047b3921acf22108a16fdbd39af974f4fe7bf36

This one fully fixes the crashes while looking for LADSPA plugins! :smiley:
It will take a bit more time to complete the search, but it’s surely better than crashing.


#13

Here’s my final fix for today:
https://github.com/falkTX/DISTRHO/commit/f54c9ff11839ab021462e7cba214827e3c48332b

Some LADSPA parameters are “control-outputs”, and should not be changed by the host.
Those will be set as not automable in juce code and the GenericAudioProcessorEditor will not show them.


#14

Thanks!

Though your change to the generic editor doesn’t make much sense: all parameters need to be visible on there, not just ones that are marked as automatable. The idea behind the automatable flag just is that it indicates which params a host should be allowed to vary over time. If a param should not be changed by the host at all, then it shouldn’t appear in the plugin’s parameter list.


#15

I know, but i didn’t find any easy way to do this without modifying either your LADSPA code (needs a little bit of changes) or Juce AudioProcessor class.
Anyway, those control-outputs should NOT be modified by the host. If the host decides to show them, they need to be updated frequently.


#16

ok, thanks. I’ve checked in the changes as-is; can revisit the parameters at some point…


#17

Out of curiosity and because I need to write a LADSPA plug: does the introjucer have a LADSPA target in the plugin builder?
If not, what are the required steps to get things rolling for a LADSPA version of a plugin?

  • bram

#18

[quote=“bdejong”]Out of curiosity and because I need to write a LADSPA plug: does the introjucer have a LADSPA target in the plugin builder?
If not, what are the required steps to get things rolling for a LADSPA version of a plugin?


#19

Not even if I don’t need a UI?

LV2 isn’t any good for me right now, it needs to be LADSPA as I need to integrate it as an ALSA PCM device…
Afaik there is no LV2 plugin for ALSA.

  • bram

#20

[quote=“bdejong”]Not even if I don’t need a UI?

LV2 isn’t any good for me right now, it needs to be LADSPA as I need to integrate it as an ALSA PCM device…[/quote]
I guess it’s a matter of anyone willing to do the work.

LADSPA has no timePos, UI, state, presets, non-automable parameters, and maybe even more stuff missing (It’s supposed to be the simplest API after all).
With LV2, we can simply add currently non-existing things as extensions.