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

[Rui Nuno Capela]

hi,

allow me to stand by Robin, well, almost...:)


On 06/22/2015 05:55 PM, Robin Gareus wrote:
> Hi Filipe et al,
>
> Maybe we should continue this lv2-dev (CCed) or LAD. You raise some
> interesting points.
>
> On 06/21/2015 11:16 PM, Filipe Coelho wrote:
>
>> You're trying to do things in the plugin side that should have been the
>> host's job in the first place.
>>
>> Loading a midi program should be a hosts job, not the plugin.
>
> In an ideal world, yes, but it is unrealistic to demand from all host to
> manage complex one-off plugin specific relations.
>
> For simple synths fine; but understanding which parts and aspects of a
> synth specific state can be part of a [midi-]program, perform atomic
> reloads and manage transitions is not the hosts job.
> I think it's a geeky pipe dream, but a nice one, I admit.
>
> Only the plugin "knows" what happens if the state changes and hence only
> the plugin should change it if asked to do so by the host.
>
> The same also applies to simple things such as "Bypass" as we've
> discussed at LAC.
>
> 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?

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

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

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

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.

this "mechanism", which is somewhat similar to current lv2_state's but 
kinda granular or per port basis, should be provided through (in)direct 
plugin-to-host interface, maybe some lv2 atom+schedule/worker 
asynchronous messaging, whatever...

take note that i'm talking about communication between host and the 
plugin core which some call it the "dsp part", and actually in the 
plugin-to-host direction--nothing to do with UIs whatever, although they 
are involved as far as it should be also notified whenever visible of 
course.


>> If you export all your control ports and presets as proper lv2 data, the
>> host can map incoming midi-bank/program events to the appropriate plugin
>> state.
>
> Exporting all control ports is not an option for the case at hand.
>
> Check how many floats pointers one reasonably use on a modern machine
> without significant overhead compared realtime processing (say 128 audio
> samples). As opposed to audio-processing, you can't unroll loops nor use
> SIMD, MIMD instructions there:
>
> Set value in host; dereference pointer in the plugin; check if it the
> value has changed and is within bounds.
>
> Then compare that to the fixed cost of parsing a 3 byte MIDI message or
> a 32 byte LV2 Atom which conveys the same information.
>
>> (LV2 introduced preset banks a few weeks ago)
>
> indeed. There's been great progress on the LV2 front.
>
>> Of course if you try to handle midi-bank/program or midi-cc in the DSP
>> side you won't be able to behave like a regular LV2 plugin.
>
> Regular as in "all float control ports"? no.
>
> Regular as in "using LV atom messages"? yes.
>
>> You either expose *all* the data as LV2 or none at all.
>> Currently you're at none at all. :(
>
> right, except via http://lv2plug.in/ns/ext/midi/
>
>>> As you already mentioned a plugin cannot modify its own control inputs
>>> and a host cannot reasonably manage [plugin specific] programs (partial
>>> subsets of the whole config). So the way forward is to use meaningful
>>> messages.
>> NO.
>> I do NOT want plugins changing their own input parameters, ever.
>
> Nor do I.

again, why the hell not?

as said and repeating myself, what's really missing is to let the lv2 
host "know" that its own version of the plugin's parameter values is 
outdated and should get a better look again ie. dereference the input 
control port that, in fact, is in its own address-space.

nuff4now.
-- 
rncbc aka. Rui Nuno Capela