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/ that curve? >> >> 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? 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). best, robin _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
