22 Jun
2015
22 Jun
'15
8:48 p.m.
hi,
allow me to stand by Robin, well, almost...:)
On 06/22/2015 05:55 PM, Robin Gareus wrote:
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
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:
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.
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.
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.