22 Jun
2015
22 Jun
'15
10:54 p.m.
On 06/22/2015 08:54 PM, Robin Gareus wrote:
On 06/22/2015 08:48 PM, Rui Nuno Capela wrote:
one word: automation
automation of what?
hi,
allow me to stand by Robin, well, almost...:)
likewise :)
On 06/22/2015 05:55 PM, Robin Gareus wrote:
[..]
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?
If we allow plugins to change their own input, that opens a can of
worms: From conflicting values, feedback loops to potentially different
host behavior and unreliable output.
are you sure? VST2+ can and allows to ever since. iow. it provide a
plugin->host communication mechanism.
i'll be damned if AU won't allow, probably command it, as well either by
law or spec (API) sake.
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.
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.
examples are a plugin's own controllability
and configuration (midi cc,
osc, etc.), its own private state, preset and programs and what not.
Hence I made the case for simply not exposing *all* controls parameters
(as some people have asked) as standard float control ports.
It's as simple as: no control-input, no cry :) The plugin can do as it
sees fit.
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 >:)
maybe. A float pointer is perfectly fine for many plugin controls, and
it also provides backwards compatibility to LADSPA.
What I think is wrong, is LV2-users and LV2 host-authors expecting all
plugins to export all their controls as POD float. LV2 offers much
better mechanisms.
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:).
As far as I know, all major plugin standard have that restriction.
It's important for being able to reproduce the
same output, given the
same input. A Plugin is a Mealy machine (output depends on input and
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?
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.
It has, hasn't it?
Just don't use old LADSPA-like float-pointer control-ports, but use
messages to set/modify the internal state.
The most common denominator for messages is currently
MIDI, but as is
OSC is up and coming as is LV2:Patch.
See recent LV2:Patch:Set file-name support in liblilv-SVN, jalv and
Ardour4. That allows hosts to tell plugins to load some specific file
(eg an IR or a sample) at a given time. If and how that happens is left
to the plugin. It only took 3 years from the first plugin that
supported it until host support showed up :)
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 might be something else, but the case is to do
something with a named file-system entity, given its pathname as a
string. iow. the semantics there is one and only: get the plugin to load
and parse a blob.
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" !
hth.
--
rncbc aka. Rui Nuno Capela