LADSPA RDF Support

[tresf]

I think the TAP plugins explain this the best, so I'll simply quote the author:

"The [TAP] plugins have been developed with Ardour as a primary host in mind, but they should be usable within any LADSPA-capable host. The main issue here is that LADSPA plugins don't generate their own GUIs, but the GUIs are generated by the host. Therefore the arrangement and appearance of the controls may vary using another host. In particular, Ardour displays drop-down lists instead of pure integer inputs in LADSPA plugin GUIs, if and when appropriate RDF metadata of the plugins is available. TAP-plugins makes use of this feature, see the screenshots of TAP Dynamics and TAP Reverberator for example.

On other (non-RDF-aware) hosts, it is very likely that only numerical input fields will appear in place of drop-down lists. In this case, the mapping is simple: 0 means the first item in the list, 1 the following and so on. However, no audio processing ability is involved, so the plugins should perform the same way even with a somewhat lacking GUI."

The RDF file format (wikipedia.com):

"The Resource Description Framework (RDF) is a family of World Wide Web Consortium (W3C) specifications originally designed as a metadata data model. It has come to be used as a general method for conceptual description or modeling of information that is implemented in web resources, using a variety of syntax notations and data serialization formats. It is also used in knowledge management applications."

So it turns out the author of the swhplugins (Steve Harris) and Taybin Rutkin wrote a lightweight RDF reader called LRDF which Ardour uses.

I'm having some trouble figuring out exactly how the rdf is loaded and then used to populate the GUI though... Perhaps someone else can help find the relevant code...

https://github.com/Ardour/ardour/blob/master/libs/ardour/ladspa_plugin.cc#L646

[badosu]

Now that's a nice issue report here :-).

[pbella]

Maybe I'm misunderstanding but it looks to me like what you're looking for is in liblrdf https://github.com/swh/LRDF/blob/ae3276710d5d813ac34f9978949b755b8a3234b1/src/lrdf.c#L759
which in turn appears to query the plugin (via loopback on localhost by default)

[tresf]

via loopback on localhost by default

Thanks for the find. From what you observe, do the RDF enabled LADSPA plugins invoke this automatically? I'm still a bit perplexed as to how we invoke the library on our end.

[pbella]

Well that's what I get for making a comment based on a quick glance at unfamiliar code. My previous statement appears to be just plain wrong. I'm going to do some more digging and see if I can find an answer that's actually correct.

[pbella]

OK, a little more digging shows that this library is a (somewhat) ladspa-specific wrapper around libraptor2 (the actual rdf parser) It appears that the rdf files would need to be processed by calling lrdf_read_file or lrdf_read_files for each of the rdf files (on my system located in /usr/share/ladspa/rdf) I don't see anything that would provide a platform independent way to locate these files so, unless I'm missing something there would probably need to be a setting to help LMMS in locating them (though they are likely to usually be in the same place on a given platform and could have sane defaults that would work in most cases)

Getting lrdf to build as a standalone library (i.e. not requiring the rest of Ardour) was pretty trivial. If I can find the right place in LMMS to try to plug in some test code, I'll proceed a bit further.

[tresf]

@pbella The Ladspa data/model seems to be managed here:
https://github.com/LMMS/lmms/blob/master/src/core/LadspaControl.cpp

The gui seems to be constructed here:
https://github.com/LMMS/lmms/blob/master/src/gui/widgets/LadspaControlView.cpp#L58

There are probably a few approaches (shim the view with the RDF display just-in-time) although I assume a proper implementation puts both the data/model and the RDF calls in their appropriate (refactored) classes.

[pbella]

It's questionable how much value the rdf data could provide...

LADSPA plugin implementations in LMMS appear to have significant differences across plugin groups (i.e. TAP, CALF...) but the existing hard coded metadata in LMMS appears to be of higher quality vs what is available via rdf.

i.e.

lmms/plugins/LadspaEffect/tap/tap_eq.c

Line 534 in 1cd8c0e

/* Parameters for CH0 freq [Hz] */

vs /usr/share/ladspa/rdf/tap-plugins.rdf
"Band 1 Freq [Hz]" vs "band_1_freq"
"Band 1 Gain [dB]" vs "band_1_gain"

I was not able to find metadata for the CALF plugins... it's possible that 'CALF Vintage Delay' is one of the generic 'Delay' plugins. But http://linux-sound.org/plugins.html indicates that the CALF plugins are actually LV2. So I'm not sure at this stage which answer is correct.

It also appears that the CALF Vintage Delay plugin already has the Stereo, Ping-Pong, etc. metadata (https://github.com/LMMS/lmms/blob/master/plugins/LadspaEffect/calf/src/metadata.cpp#L145) but it is not exposed. (the screenshots from #1713 shows a knob used in the LMMS plugin vs a drop down in the LV2 GUI. The rdf metadata available does not appear to be sufficient to drive GUI widget selection)

Finally, it appears that LADSPA (v1) is a legacy approach that is being replaced by LV2 (i.e. LADSPA v2) so it's probably worth asking how much effort does enhancing v1 plugins warrant? (though the number of available LV2 plugins does appear more limited)

[tresf]

Agreed. Closing this out for now as wont-fix. Feel free reopen at a later time if needed. 👍

[badosu]

@tresf @pbella So, is it impossible to extract the metadata for the knobs? 😢

[pbella]

@badosu from the rdf files, that appears to be the case. So really all I'm suggesting and I think @tresf is agreeing with is that spending a lot of effort reworking the LADSPA v1 plugins isn't a great use of time.

The good news is that the metadata for the example you provided is already in the plugin (hard coded), so what you'd need in that particular case is an enhancement request to modify the GUI. I think either switching the knob to a drop down or to add the capability to display the metadata labels for knob values would be doable, but some thought would want to go into it rather than just doing it for this one case. If it was decided that either of these changes could be done in such a way that the effort could also be reused for other (non-LADSPA v1) plugins, it would probably be worth considering as I agree the current 'knobs with numbers' UI isn't very user friendly.

[badosu]

@pbella @tresf Thanks for digging all this information. Since this is something that originated from me, I'll try to look at this myself when I'm able, but please don't close this issue.

[tresf]

but please don't close this issue.

No problem, we'll leave it open. 👍

[dead-claudia]

BTW, TAP Reverberator ships with LMMS, and so it kinda feels like a broken feature. Thankfully, in that case, I can just cross-reference the mode select value with the source code's RDF, but that is far from the ideal.