[LV2] [LAU] LV2 control-ports and midi binding -- was Re: [ANN] setBfree v0.8

Robin Gareus robin at gareus.org
Mon Jun 22 12:55:28 PDT 2015

[re-post, forgot to CC lv2-dev ML]

On 06/22/2015 08:48 PM, Rui Nuno Capela wrote:
> hi,
> allow me to stand by Robin, well, almost...:)

likewise :)

> On 06/22/2015 05:55 PM, Robin Gareus wrote:
>> IMHO a plugin host is literally just a host and not an omniscient
>> dictator in control of all parameters. We may have to agree to disagree
>> on that.
> correct. every plugin, more than any host, *should* be in full charge of
> its own parameters aka. lv2 input control port values. why the heell not
> a plugin shall decide to make up its own parameter values?

one word: automation

If we allow plugins to change their own input, that opens a can of
worms: From conflicting values, feedback loops to potentially different
host behavior and unreliable output.

> examples are a plugin's own controllability and configuration (midi cc,
> osc, etc.), its own private state, preset and programs and what not.

Hence I made the case for simply not exposing *all* controls parameters
(as some people have asked) as standard float control ports.

It's as simple as: no control-input, no cry :) The plugin can do as it
sees fit.

> why should a lv2 version of an incredible sounding intrument be
> crippled, in usability features there is, just because the lv2 spec
> doesn't cope (yet) with this simple interface issue? or worse, it
> dictates "prohibition"?
> as a legacy from ugly old ladspa, a lv2 host is in fact responsible to
> give the address to the lv2 plugin port, whether it's an input or output
> control port--that's the original lv2's sin >:)

maybe. A float pointer is perfectly fine for many plugin controls, and
it also provides backwards compatibility to LADSPA.

What I think is wrong, is LV2-users and LV2 host-authors expecting all
plugins to export all their controls as POD float. LV2 offers much
better mechanisms.

> ok. problem is, if a plugin sees fit, to its own purpose, to modify one
> or any of its own parameters, the host won't get notified of the change
> and most probably will override the value of it in just a few jiffies,
> later, or don't even get a clue of the change whatsoever.
> and why does it happen? in my (not so humble) opinion, that's because
> there's a relaxed flaw in the lv2 protocol: saying that plugin
> parameters or lv2 input control ports, are strictly read-only from a
> plugin pov. is just nuisance if not seriously crippling lv2's world
> dominance:).

As far as I know, all major plugin standard have that restriction.

It's important for being able to reproduce the same output, given the
same input. A Plugin is a Mealy machine (output depends on input and
internal state).

> in my (now humble) opinion, the lv2 spec should address the specific
> mechanism or interface to notify the host when the plugin wants or has
> already modified some or all of its own parameters.

It has, hasn't it?

Just don't use old LADSPA-like float-pointer control-ports, but use
messages to set/modify the internal state.

The most common denominator for messages is currently MIDI, but as is
OSC is up and coming as is LV2:Patch.

See recent LV2:Patch:Set file-name support in liblilv-SVN, jalv and
Ardour4. That allows hosts to tell plugins to load some specific file
(eg an IR or a sample) at a given time. If and how that happens is left
to the plugin.  It only took 3 years from the first plugin that
supported it until host support showed up :)


More information about the Devel mailing list