<div dir="ltr"><div>Thanks Hanspeter.</div><div><br></div><div>I should study how Pianoteq implemented this, it seems it solves most concerns.<br></div><div><br></div><div>Guillaume<br></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>