On 06/22/2015 08:48 PM, Rui Nuno Capela wrote: > 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? one word: automation 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. > 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). > 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 :) best, robin _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
