<div dir="ltr"><div>Hi all,</div><div><br></div><div>This discussion started in <a href="https://github.com/plugdata-team/plugdata/issues/1034">https://github.com/plugdata-team/plugdata/issues/1034</a>, but David suggested that I bring it up on this mailing list so that we can hash out the details and maybe craft an implementation that will make this kind of dynamic plugin changes work in LV2.</div><div><br></div><div>The dynamic changes in question are the ability to adjust automation parameters on the fly, specifically their names and ranges. This functionality is being used in plugdata, which lets you run Pd patches as a plugin in a DAW, and supports various plugin formats (including LV2) via JUCE. pludata is like Ableton's <a href="https://www.ableton.com/en/live/max-for-live/">Max for Live</a>, but entirely open-source and based on Miller Puckette's <a href="https://en.wikipedia.org/wiki/Pure_Data">Pd</a>. It's a highly dynamic environment which lets you change the name and ranges of automation parameters exposed to the plugin hosts. This is really a necessity, as Pd patches keep changing all the time (in fact, plugdata is a full-blown Pd-like environment which lets you edit the patches right there in the plugin editor), and so frequent changes of the automation parameters (which are represented as as special <span style="font-family:monospace">param</span> Pd objects in the patch) are expected and should be doable without much ado.</div><div><br></div><div>This already works with the AU, CLAP, and VST3 plugin formats, since the corresponding host APIs support these kinds of changes, and they're supported in the corresponding JUCE wrappers as well. (I haven't tested all of these myself, but I did test the plugdata VST3 on Linux and Mac and it properly supports these.)</div><div><br></div><div>LV2 doesn't at present, which is a noticeable limitation of plugdata's LV2 variant, so we'd like to change that. I have to admit right up front that this is not something that the vast majority of plugins needs. It specifically caters to the needs of highly dynamic plugins like plugdata, of which there aren't many. But it's rather important for plugdata, so there's sufficient incentive to make it work; LV2 should be at least up to par with VST3 on that IMHO.</div><div><br></div><div>David suggested that the easiest and most practical way to go about this would be to utilize LV2's patch messages (<a href="http://lv2plug.in/ns/ext/patch">http://lv2plug.in/ns/ext/patch</a>). This should be flexible enough to send messages to the effect of <code class="gmail-notranslate">plugin->rename_param(char *current_name, char *new_name)</code> and <code class="gmail-notranslate">plugin->change_param_range(char *param_name, float minval, float maxval)</code> to the host, which should do the trick. Of course this would have to be implemented in the corresponding JUCE 
method (presumably that's ParameterStorage::audioProcessorChanged() in 
<a href="https://github.com/juce-framework/JUCE/blob/d24c2729268e322f3ba1b5070eb96ab232d7f6ba/modules/juce_audio_plugin_client/juce_audio_plugin_client_LV2.cpp#L210">juce_audio_plugin_client_LV2.cpp:210</a>, which currently doesn't do 
anything), and on the Ardour side in the LV2 host code which needs to 
listen for those messages and then do whatever is necessary to implement
 those changes (we should hopefully be able to snitch this from the corresponding 
VST3 host code in Ardour).</div><div><br></div><div>I'm willing to do the necessary coding myself and embark on crafting corresponding pull requests for JUCE, Ardour, and plugdata, as necessary. But I need help on how to implement these changes using <a href="http://lv2plug.in/ns/ext/patch">http://lv2plug.in/ns/ext/patch</a>. If anyone has any code snippets demonstrating how to utilize these patch messages on both the plugin and the host side, please toss them my way, so that I can study them. Thanks. :)</div><div><br></div><div>Robin, I'll probably need your help as well in order to figure out where I need to make the relevant changes in the Ardour source which still looks like a vast abyss to me. ;-) Or if you'd be willing to add the necessary changes to Ardour yourself, that would be much much appreciated!</div><div><br></div><div>Alright, I think that this should be enough to kick off the discussion. Please check <a href="https://github.com/plugdata-team/plugdata/issues/1034">https://github.com/plugdata-team/plugdata/issues/1034</a> if you're interested in further details on how this relates to plugdata. I'm on vacation for the next three weeks, but I'll try to respond to your replies as soon as I can.</div><div><br></div><div>Best,</div><div>Albert<br></div><div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div></div></div>