23 Jun
2015
23 Jun
'15
2:21 a.m.
On 06/22/2015 10:54 PM, Rui Nuno Capela wrote:
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/
that curve?
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.
[..]
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
>
> 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"
nice, ey?!
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
scale.
[..]
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? 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).
best,
robin