<div dir="ltr">> If you expose the real (physical) value directly to the control ports in your<br>
LV2 wrapper, I think your issues (as you explained them in the above example)<br><div>
are gone, imho <br></div><div><br></div><div>I'm only started to feel what is the real thing making me wary about exposing every internal.<br></div><div>I have posted bad examples to understand this, for sure some of the issues do not exist.</div><div></div><div></div><div><br></div><div></div><div>To me this issue has the same "shape" than silent input and bypass parameter.</div><div></div><div>It turns out inside the plugin is the best place to implement bypass parameter and silent input.</div><div>
I guess that's why VST3 introduced a special parameter that is a bypass (whose implementation is left to the plug-in)</div><div>and a special flag for silent buffers (implementation is left to the plug-in too).</div><div><br></div><div>It seems to me that upgrading chunks is <b>arbitrary</b>, so why would the host be able to do arbitrary things that cannot be described by LV2? It seems you are trying to describe everything that may happen which expose every internals of the plugin. (#1).<br></div><div><br></div><div>
The issue is also social (#2), if the plugin maker receive a support request
to improve upgradeability (beyond easy things like remapping floats), she cannot do anything if she's not in
control of state is handled with a particular lv2 type in a particular host.
</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 30 mars 2019 à 15:06, Hanspeter Portner <<a href="mailto:dev@open-music-kontrollers.ch">dev@open-music-kontrollers.ch</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">On 30.03.19 12:18, Auburn Sounds wrote:<br>
> <br>
> Opaque blobs are, IMO, a bad idea, so the state extension encourages<br>
> transparent state so it can be portably saved in whatever way makes the<br>
> most sense for the host, easily investigated by the user, and so on,<br>
> but you *can* save blobs if you really want to.<br>
> <br>
> <br>
> <br>
> I've argued several times on IRC about the use case where opaque blogs are<br>
> useful. Maybe I'm not clear enough, so let me sum up again.<br>
<br>
I guess I've partially been involved in this conversation trying to help you.<br>
<br>
Your initial arguments were that with LV2 you cannot (from one plugin version to<br>
another)<br>
<br>
* rename ports<br>
* reorder ports<br>
* add ports<br>
* change control port ranges<br>
* remove ports<br>
<br>
Well, it turns out you can do all of them but the last (as long as the port<br>
symbol stays the same).<br>
<br>
[x] rename ports<br>
[x] reorder ports<br>
[x] add ports<br>
[x] change control port ranges<br>
[ ] remove ports<br>
<br>
Then you've brought up this example here:<br>
<br>
2019-03-29 10:11:16 p0nce let me take an example<br>
2019-03-29 10:11:36 p0nce say a customer use Bablinator 1.0 with a cutoff<br>
parameter of 400hz<br>
2019-03-29 10:12:10 p0nce in Bablinator 2.0, me the GentleAudio developer have<br>
remapped cutoff to extend up to 500hz<br>
2019-03-29 10:12:27 p0nce but cutoff is mapped logarithmicatlly<br>
2019-03-29 10:12:56 p0nce with my custom serialization to EnterprisePresetXML, I<br>
can remap that parameter when loading a Bablinator 1.0 chunk<br>
2019-03-29 10:13:16 p0nce if I'm the LV2 host though, I cannot do anything apart<br>
from saying "this is not the right Bablinator version"<br>
2019-03-29 10:13:48 p0nce because GentleAudio didn't said to me how exactly the<br>
parameter was mapped, the format couldn't express this s-curve<br>
2019-03-29 10:14:00 p0nce BUT<br>
2019-03-29 10:14:24 p0nce say this upgrade doesn't work, either GentleAudio or<br>
PoorLV2Host doesn't manage to do it<br>
2019-03-29 10:14:39 p0nce I, the AngryCustomer write to GentleAudio to have my<br>
session back<br>
2019-03-29 10:14:58 p0nce if the host handle the save/restore, then they cannot<br>
do anything, and the host either<br>
2019-03-29 10:15:06 p0nce if the plugin handle the chunking, they can<br>
2019-03-29 10:16:02 p0nce the manufacturer of the plugin, because the host<br>
developer will be busy doing proper software<br>
2019-03-29 10:16:10 p0nce that's the heart of my argumentation<br>
2019-03-29 10:20:11 p0nce (ok my example require that cutoff is not mapped in a<br>
known way)<br>
<br>
The problem as I've understood it (may well be that I've misunderstood it) is<br>
that you use fixed control port ranges [0,1] (because other plugin specs force<br>
you to) and do some internal mapping to e.g. cutoff frequency.<br>
<br>
In your plugin v1 you map control port range [0,1] to internal range [0,400] Hz.<br>
User sets cutoff in the host to 200 Hz and saves a preset (control port value 0.5).<br>
<br>
No dev released plugin v2 which maps control port range [0,1] to internal range<br>
[0,500] Hz. Previous user's preset from plugin v1 is loaded in plugin v2 with<br>
control port value 0.5, which now maps to 250 Hz (assuming linear mapping for<br>
simplicity).<br>
<br>
That's (one) reason you want to be in control of how your control port values<br>
are saved, right ?<br>
<br>
I've tried to explain to you on IRC (and obviously failed), that with LV2 you<br>
don't have this problem, because you don't need to map from a (silly) [0,1]<br>
control port range to the real (physical) internal parameter range [0, 400] Hz.<br>
<br>
You just use the latter directly for your control ports.<br>
<br>
Here exemplified with some metadata.<br>
<br>
plugin v1<br>
---------<br>
<br>
lv2:port [<br>
a lv2:InputPort, lv2:ControlPort ;<br>
lv2:index 0 ;<br>
lv2:symbol "cutoff" ;<br>
lv2:name "Cutoff frequency" ;<br>
lv2:default 200 ;<br>
lv2:minimum 0 ;<br>
lv2:maximum 400 ;<br>
lv2:portProperty lv2:logarithmic ;<br>
units:unit units:frequency ;<br>
] .<br>
<br>
User sets cutoff frequency to 200 Hz and safed a preset in the host, the preset<br>
contains the following chunk of metadata:<br>
<br>
preset for v1<br>
-------------<br>
<br>
<><br>
a pet:Preset ;<br>
lv2:prot [<br>
lv2:symbol "cutoff" ;<br>
pset:value 200<br>
] .<br>
<br>
Now the dev decides to reorder the control port from index 0->2, renames it from<br>
'cutoff frequency'->'Renamed cutoff frequency' and changes the range from<br>
[0,400]->[0,500].<br>
<br>
Any LV2 host will be fine to load the preset from v1 into an instance from v2<br>
(and vice versa).<br>
<br>
plugin v2<br>
---------<br>
<br>
lv2:port [<br>
a lv2:InputPort, lv2:ControlPort ;<br>
lv2:index 2 ;<br>
lv2:symbol "cutoff" ;<br>
lv2:name "Renamed cutoff frequency" ;<br>
lv2:default 220 ;<br>
lv2:minimum 0 ;<br>
lv2:maximum 500 ;<br>
lv2:portProperty lv2:logarithmic ;<br>
units:unit units:frequency ;<br>
] .<br>
<br>
> "If the host does state saving, there is no way to have upgrades over the<br>
> lifetime of a plug-in.Because the host know much less about the plugin semantics<br>
> than the plugin itself. **Some plug-in parse blobs to upgrade state to a<br>
> seemingly incompatible plug-in version.**"<br>
<br>
If you expose the real (physical) value directly to the control ports in your<br>
LV2 wrapper, I think your issues (as you explained them in the above example)<br>
are gone, imho.<br>
<br>
> I think it's a good idea for the format acceptance, and for backwards<br>
> compatibility for a product existence. Such "chunk parsing" I've seen as an<br>
> intern in plugin company.<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.lv2plug.in" target="_blank">Devel@lists.lv2plug.in</a><br>
<a href="http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in" rel="noreferrer" target="_blank">http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in</a><br>
</blockquote></div>