[LV2] [LAU] LV2 control-ports and midi binding -- was Re: [ANN] setBfree v0.8
robin at gareus.org
Mon Jun 22 17:21:34 PDT 2015
On 06/22/2015 10:54 PM, Rui Nuno Capela wrote:
> On 06/22/2015 08:54 PM, Robin Gareus wrote:
>> On 06/22/2015 08:48 PM, Rui Nuno Capela 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?
>> one word: automation
> automation of what?
of the parameter in question.
If you have a manual fader connected to a control input and the plugin
itself changes the value, yes the host could just update the fader.
Would be a fun game to watch, though: Plugin pushes the control down,
the user pushes up. Might be entertaining to make a contest out of it :)
but for serious pro-audio, really?
What should happen if the user specified an automation-curve that the
plugin should follow? ..and now the plugin comes along and /rewrites/
>> As far as I know, all major plugin standard have that restriction.
mmh. maybe I'll have to eat my words..
> are you sure? VST2+ can and allows to ever since. iow. it provide a
> plugin->host communication mechanism.
So does LV2.
IIRC VST uses a setParameter() and getParameter() methods. No shared
memory. Anyway, VST is a mess of 90's engineering. The sooner we forget
about it, the better :)
> i'll be damned if AU won't allow, probably command it, as well either by
> law or spec (API) sake.
AU has a clear separation of Scope. Input, Output and Global which is
usually also an input, but there are additional properties for access:
write/read or In/Out. For the scope: Output is "0" Input is "1" you
can't bit-flag combine them.
However the is the concept of AUDependentParameter: a "parameter whose
value can change in response to a change in its parent metaparameter"
There are also SetProperty() and GetProperty() and GetPropertyInfo
methods in AU, one can set up Listeners (callbacks for changes) and you
can also pass around PropertyList and Dicts..
It's not unlike to passing LV2:Patch (property) messages in an Atom
Sequence around in the LV2 world or a LV2 plugin sending out
notifications to the host.
> 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.
LV2 Atom messages are also using shared-mem.
> 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.
I don't catch that drift.
Nobody suggested to process separate the DSP in LV2. It simply does not
>> 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?
Yes, and that's already part of the LV2 specs.
There are various types available. e.g LV2_Atom_Int. Vocabulary and
semantics already exist.
> 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 can be anything really, including float. and also provides means to
do that sample-accurately (if needed).
> 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" !
It works both ways.
LV2 Midi output is one example where many hosts already parse LV2 Atoms
generated by a plugin and take action accordingly.
It also works for float or ints and vectors, but there is currently no
plugin that uses it that way. Currently the only notifications that some
hosts (Ingen, jalv and Ardour, soon also Carla) intercept is filenames
(eg plugin restores state and notifies host about changed file).
More information about the Devel