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

From: Rui Nuno Capela <rncbc@email-addr-hidden>
Date: Mon Jun 22 2015 - 23:54:05 EEST

On 06/22/2015 08:54 PM, Robin Gareus wrote:
> 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
>

automation of what?

>
> 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.
>

are you sure? VST2+ can and allows to ever since. iow. it provide a
plugin->host communication mechanism.

i'll be damned if AU won't allow, probably command it, as well either by
law or spec (API) sake.

the debate re. LV2, it's all about its legacy from LADSPA and assuming
that host and plugin (core, dsp, whatever) is running in same
address-space, in-process all the way.

a very old debate i say, something that lurked from dang old host vs.
plugin-UI dilemma--now's about host vs. plugin-core/dsp one.

> 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.
>

and what message would that be? being POD or else, concrete messages
format and semantics *must* be known to the host, beforehand, don't they?

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

that is for telling plugins to work with a very specific,
non-scalar/float value, ie. a string which just happens to be a file
pathname, hopefully; it might be something else, but the case is to do
something with a named file-system entity, given its pathname as a
string. iow. the semantics there is one and only: get the plugin to load
and parse a blob.

otoh. what i've been saying is about plugins telling the host that "this
particular thing of mine has changed and you, the host, must do
something about it" !

hth.

-- 
rncbc aka. Rui Nuno Capela
_______________________________________________
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