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

From: Robin Gareus <robin@email-addr-hidden>
Date: Mon Jun 22 2015 - 22:54:25 EEST

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 :)

best,
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Jun 23 00:15:02 2015

This archive was generated by hypermail 2.1.8 : Tue Jun 23 2015 - 00:15:02 EEST