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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-userReceived 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