How to access LV2 atom:Path parameter defined in metadata.ttl

Development
1

I implemented a piano resonance plugin that needs to be configurable to specify the IR file on Zynthian, where the UI is not instantiated.

(Note: on Windows and presumably other more typical platforms, the file is specified using a button that launches a file browser, and that works. This issue is just for Zynthian, because it does not instantiate the UI. Instead it reads the TTL and generates a generic UI.)

There is an LV2-native plugin that takes an IR file as a parameter ( GitHub - x42/zconvo.lv2: Zero Config Convolver · GitHub ) that works on Zynthian, and the manifest.ttl contains:

<http://gareus.org/oss/lv2/@LV2NAME@#ir>
	a lv2:Parameter;
	rdfs:label "Impulse Response";
	rdfs:range atom:Path.

I have no idea why it’s in manifest.ttl rather than zeroconvolv.ttl (or why anything should be in one versus the other.)

My plugin is Projucer-based, but I already have to postprocess the plugin.ttl file to get the parameters in the order I want, and I don’t have an issue with having to postprocess the manifest.tll each time it gets regenerated. (If there’s a solution to this, just mention it and I’ll start another thread for that!)

I can’t figure out how to access the parameter from the AudioProcessor code. I’ve asked Google AI a number of questions, and it gives (a) incorrect answers or code referring to things that might but don’t exist, (b) advice not to do this because parameters should be for live control, not setup.

This is my first nontrivial plugin and also my first JUCE plugin. It’s GitHub - jlearman/PianoRes: Resonance plugin for sampled pianos · GitHub if you’re interested: it uses an IR file built from summing every note on a sampled piano, and responds to the sustain pedal to activate/deactivate the effect (plus an ADSR on pedal release.) It adds nice realism to a sampled piano.

I’m a retired software engineer in networking and embedded systems, but new to the world of audio.

2

This isn’t supported at the moment, as there’s no good way to surface a textual parameter value through the AudioProcessorParameter interface. JUCE aims for compatibility across plugin formats, and parameters with textual values aren’t supported in any other plugin format as far as I know.

1 Like
3

Thanks. I understand the limitations caused by multi-platform (and I really appreciate it being multi-platform!)

I was hoping that there might be a way using lv2 extensions, but I can’t quite connect the dots.

4

I’m new to writing audio plugins, but perhaps I’m missing something.

Many audio processors take files (or filenames) as parameters. For example, IR files for convolution reverbs (which is my case.) Why should coders use anything other than the AudioProcessorParameterto represent them?

Sure, they’re not passed via MIDI CC, but the class description doesn’t say anything about MIDI, just about “parameter objects that can be added to an AudioProcessor.”

Doesn’t an IR filename meet that criteria? If the intent of that API is more restrictive, then perhaps that should be stated, so we can understand why the limitation.

It’d be a shame to not be able to use JUCE for any plugin on Zynthian that needs a file or text parameter.

I suspect the reason that JUCE doesn’t support this for other formats is that those formats are normally used in situations where the editor is instantiated, and their editors don’t use APP `AudioPlugiParameterfor` the parameters that don’t fit. (Which is what I had to do for running on Windows in a normal host.) Not instantiating the editor is the only thing special about Zynthian, as far as I can tell.

I’d also be nice if they worked in APVTS as well, rather than having to make an exception for every non-numeric parameter. That would benefit plugins even where the editor is instantiated.

5

I was not aware of any plugin format that supports parameters that are text strings, news to me that LV2 has such a capability. In other plugin formats, file names and other such more complicated states have to be handled specially and there are no convenient ways to do that with headless plugins, it is assumed the non-numeric states will be entered by the user via the plugin’s custom GUI.

It has actually been bit of a disappointment the CLAP format does not have an official solution for that either. It’s of course possible to add new CLAP extensions and event types but the chances are very low hosts would also start supporting those if they are not part of the official plugin spec.

6

Hi all!

Here jofemodo from zynthian team sending my 2 cents. I would like to lobby a little bit for the LV2 plugin standard. :wink:

And not, it’s not that i think it’s the better plugin standard in the world. Probably not. Or probably not for all use cases, but AFAIK, LV2 is the de-facto plugin standard for embedded devices that use audio plugins. And it’s not a caprice …

ModDevices and Zynthian use LV2 because of very good reasons, but the main reason is that the DSP and the GUI are totally separated. Indeed in LV2, the UI process is something optional, it can run or not. The DSP can run alone or better yet, you can have several UIs controlling the same DSP, like zynthian does. This “feature” makes LV2 very special and totally different to the rest. LV2 has something that makes it unique. Total separation of DSP and UI.

This special feature is normally overlooked or ignored by developers focused on desktop platforms but it’s absolutely needed for embedded systems. And this separation can’t work if we can’t send textual parameters, like filepaths, to the DSP.

There are lot of plugins that can’t work in zynthian / mod-devices / etc. without this feature:

  • Samplers
  • IR loaders
  • Neural Modelers
  • etc.

JUCE’s LV2 support has been a big step forward and has opened the door to integrate a lot of new plugins into devices like Zynthian and MOD devices, but it’s still incomplete because of the lack of support for this critic feature.

We have a lot of JUCE plugins integrated in zynthian, but not IR-loaders, samplers or Neural Modelers because they simply can’t work. It’s a pity!

There is no doubt that JUCE is the best develpment framework for plugins that run in DAWS and desktop platforms. I really would love that JUCE becomes the best framework for developing audio plugins for embedded devices too. Why not?

So please, i kindly ask you to consider supporting textual parameters. We are not talking of sending big texts, just file paths would be enough.

All the best!

3 Likes
7

The GMPI Plugin SDK supports string parameters.

IMHO: Supporting e.g. a filename as a parameter and part of the plugins state is bread-and-butter functionality for audio software, especially things like:

  • sample-based instruments
  • convolution reverb
  • wavetable-based instruments.

These are common, mainstream usage scenarios. So let’s not dismiss the request offhand just because JUCE never supported it yet.

1 Like
8

BTW, I’m a retired embedded systems & networking software engineer who has worked at places like Cisco, AWS, and IBM, and would be happy to help. If someone fluent in JUCE architecture could map out a solution, I’d be happy to do the grunt work.

If that sounds good, open an issue and assign it to me: jlearman (Jeff Learman) · GitHub or jjlearman at gmail.

9

Perhaps the solution would be to support distributed UI/DSP, which is supported by LV2, VST3, and AU, but not CLAP. Not a small project.

My offer still stands to do the detail work if someone does the overall architecture.