Add new param_list method

[Jurrie]

This method can be used to discover the parameters for a specific
plugin.

[odurc]

Is there any special reason to create a new command for this? All param_* commands already implement autocomplete when you provide the plugin instance.

[Jurrie]

Hi Ricardo,

It's available in interactive mode, but not when communicating using sockets.

I'm trying to build my own hardware effects processor using LV2 plugins. It will be a 19" unit with a display and some buttons to control parameters in the LV2 plugins. For this device, I'd like to use mod-host. So I need build some software that controls the display and buttons; and it needs to be able to query what parameters are available. "param_list" is the first command I need, I'll also need something like "param_detail" that can give me the min/max/current values etc. (Maybe even things like "list" to list loaded LV2 plugins, and others...)

To answer your question: there's probably no special reason for this for the moddevices project. But I thought I'd share this anyway :)

With kind regards,

Jurrie

[falkTX]

you should probably do the parsing of plugin data somewhere else.
lv2 meta-data is stored outside of the binary, so using lilv (or python-lilv) you can get all the needed information.

[Jurrie]

Depending on which responsibilities you place on which application (mod-host or my glue-hw-display-to-mod-host), you could be right indeed. However, using a socket connection to mod-host and have it do the lilv stuff is easier for me, as my glue software is probably written in Java.
So this was worth a shot :) However, if you feel that mod-host shouldn't be used to do lilv-library-stuff, then I'll need to think of a way to do this in Java :) It's back to the drawing board for me!

[jofemodo]

In fact, mod-host is doing lilv-library-stuff right now ... why not adding new commands that gives useful information?

[falkTX]

Because it's never enough.
Now it's control ranges, then scalepoints, then presets, then designation and properties, then documentation...
There's a lot of stuff involving ports, range is just the beginning.

Also, it's the wrong way to go.
mod-host is for hosting the plugins, not for discovery.
You have lv2ls and lv2info for that.

[Jurrie]

@jofemodo: I have to say that, on second thought, I think I agree with falkTX. My program is using RDF (via Apache Jena) to discover plugin information, and this proves to be very flexible. I can even use queries. It's far more flexible than programming this all in mod-host.

[jofemodo]

OK. I understand the point and the reasons. Perhaps it's better to implement the "discovery" functionality out of mod-host. Anyway, IMHO, there are some important info that could be given by mod-host, like getting the list of running effect-instances, connections, etc ... This is not discovery info ;-)