<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 31 mars 2019 à 13:20, David Robillard <<a href="mailto:d@drobilla.net">d@drobilla.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This is indeed limiting to plugin developers - on purpose.  Even if the<br>
plugin was 100% responsible for restoring its state, it could not paper<br>
over this kind of breakage with parameters, because it does not know<br>
what the host is doing with these values.  You could, for example, have<br>
a session with an automation lane with all kinds of fancy things going<br>
on based on the fact that a parameter is in Hz.<br></blockquote><div><br></div><div>Ha! I hadn't thought about automation lane indeed that is stored by the host. This is a kilelr argument and I remove myself from this embarassing discussion.<br></div><div>So it seems my "chunk parsing" is always misguided.</div><div><br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A plugin's control interface is like a<br>
library API, you just have to be careful about it.<br></blockquote><div><br></div><div>Yes we are dealing with that with a sort of SemVer for releases. It seemed to me it was possible to have compatibility across major changes, but with what you say it seems a pipe dream anyway.<br></div><div><br></div><div>I'm not even sure how high-rated upgradeability is for users.<br></div><div>Going to release an incompatible v2 in six month to one of Auburn Sounds plug-ins, and see how many complaints we get.</div><div>(A user will be able to have the former version coexist with the newer, so it's not compeltely breaking.)</div><div>It has occured in the past that things that you'd think would bring lots of criticism, didn't.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

There are a few areas where LV2 is hostile to developers who want the<br>
lowest common denominator between all the plugin specs, and this is one<br>
of them.  I think it's justified, though.  At the very least, it lets<br>
you do neat things like <br>
<a href="https://drobilla.net/2014/11/03/lv2-plugin-control-units-in-ardour.html" rel="noreferrer" target="_blank">https://drobilla.net/2014/11/03/lv2-plugin-control-units-in-ardour.html</a><br>
which you can't with the meaningless normalized controls of VST.<br></blockquote><div><br></div><div>
<div>In Dplug we're indeed about the absolute lowest common denominator API, and this explains how we got to think like this (bugs like <a href="https://github.com/AuburnSounds/Dplug/issues/308">https://github.com/AuburnSounds/Dplug/issues/308</a> are a bit annoying ).<br></div><div><br></div><div></div><div>From
 what I can tell from more experienced plugin developer, they are more 
supporters of meaningful parameters with units and such.</div><div>I think I see now why LV2 has internal state + control ports in such a way. Well, case closed I guess.</div><div><br></div><div>Cheers,</div></div><br></div></div></div>