[LV2] Dplug wrapper for LV2
Auburn Sounds
contact at auburnsounds.com
Sat Mar 30 09:30:42 PDT 2019
Thanks Hanspeter.
I should study how Pianoteq implemented this, it seems it solves most
concerns.
Guillaume
Le sam. 30 mars 2019 à 15:06, Hanspeter Portner <
dev at open-music-kontrollers.ch> a écrit :
> On 30.03.19 12:18, Auburn Sounds wrote:
> >
> > Opaque blobs are, IMO, a bad idea, so the state extension encourages
> > transparent state so it can be portably saved in whatever way makes
> the
> > most sense for the host, easily investigated by the user, and so on,
> > but you *can* save blobs if you really want to.
> >
> >
> >
> > I've argued several times on IRC about the use case where opaque blogs
> are
> > useful. Maybe I'm not clear enough, so let me sum up again.
>
> I guess I've partially been involved in this conversation trying to help
> you.
>
> Your initial arguments were that with LV2 you cannot (from one plugin
> version to
> another)
>
> * rename ports
> * reorder ports
> * add ports
> * change control port ranges
> * remove ports
>
> Well, it turns out you can do all of them but the last (as long as the port
> symbol stays the same).
>
> [x] rename ports
> [x] reorder ports
> [x] add ports
> [x] change control port ranges
> [ ] remove ports
>
> Then you've brought up this example here:
>
> 2019-03-29 10:11:16 p0nce let me take an example
> 2019-03-29 10:11:36 p0nce say a customer use Bablinator 1.0 with a
> cutoff
> parameter of 400hz
> 2019-03-29 10:12:10 p0nce in Bablinator 2.0, me the GentleAudio
> developer have
> remapped cutoff to extend up to 500hz
> 2019-03-29 10:12:27 p0nce but cutoff is mapped logarithmicatlly
> 2019-03-29 10:12:56 p0nce with my custom serialization to
> EnterprisePresetXML, I
> can remap that parameter when loading a Bablinator 1.0 chunk
> 2019-03-29 10:13:16 p0nce if I'm the LV2 host though, I cannot do
> anything apart
> from saying "this is not the right Bablinator version"
> 2019-03-29 10:13:48 p0nce because GentleAudio didn't said to me how
> exactly the
> parameter was mapped, the format couldn't express this s-curve
> 2019-03-29 10:14:00 p0nce BUT
> 2019-03-29 10:14:24 p0nce say this upgrade doesn't work, either
> GentleAudio or
> PoorLV2Host doesn't manage to do it
> 2019-03-29 10:14:39 p0nce I, the AngryCustomer write to GentleAudio
> to have my
> session back
> 2019-03-29 10:14:58 p0nce if the host handle the save/restore, then
> they cannot
> do anything, and the host either
> 2019-03-29 10:15:06 p0nce if the plugin handle the chunking, they can
> 2019-03-29 10:16:02 p0nce the manufacturer of the plugin, because
> the host
> developer will be busy doing proper software
> 2019-03-29 10:16:10 p0nce that's the heart of my argumentation
> 2019-03-29 10:20:11 p0nce (ok my example require that cutoff is not
> mapped in a
> known way)
>
> The problem as I've understood it (may well be that I've misunderstood it)
> is
> that you use fixed control port ranges [0,1] (because other plugin specs
> force
> you to) and do some internal mapping to e.g. cutoff frequency.
>
> In your plugin v1 you map control port range [0,1] to internal range
> [0,400] Hz.
> User sets cutoff in the host to 200 Hz and saves a preset (control port
> value 0.5).
>
> No dev released plugin v2 which maps control port range [0,1] to internal
> range
> [0,500] Hz. Previous user's preset from plugin v1 is loaded in plugin v2
> with
> control port value 0.5, which now maps to 250 Hz (assuming linear mapping
> for
> simplicity).
>
> That's (one) reason you want to be in control of how your control port
> values
> are saved, right ?
>
> I've tried to explain to you on IRC (and obviously failed), that with LV2
> you
> don't have this problem, because you don't need to map from a (silly) [0,1]
> control port range to the real (physical) internal parameter range [0,
> 400] Hz.
>
> You just use the latter directly for your control ports.
>
> Here exemplified with some metadata.
>
> plugin v1
> ---------
>
> lv2:port [
> a lv2:InputPort, lv2:ControlPort ;
> lv2:index 0 ;
> lv2:symbol "cutoff" ;
> lv2:name "Cutoff frequency" ;
> lv2:default 200 ;
> lv2:minimum 0 ;
> lv2:maximum 400 ;
> lv2:portProperty lv2:logarithmic ;
> units:unit units:frequency ;
> ] .
>
> User sets cutoff frequency to 200 Hz and safed a preset in the host, the
> preset
> contains the following chunk of metadata:
>
> preset for v1
> -------------
>
> <>
> a pet:Preset ;
> lv2:prot [
> lv2:symbol "cutoff" ;
> pset:value 200
> ] .
>
> Now the dev decides to reorder the control port from index 0->2, renames
> it from
> 'cutoff frequency'->'Renamed cutoff frequency' and changes the range from
> [0,400]->[0,500].
>
> Any LV2 host will be fine to load the preset from v1 into an instance from
> v2
> (and vice versa).
>
> plugin v2
> ---------
>
> lv2:port [
> a lv2:InputPort, lv2:ControlPort ;
> lv2:index 2 ;
> lv2:symbol "cutoff" ;
> lv2:name "Renamed cutoff frequency" ;
> lv2:default 220 ;
> lv2:minimum 0 ;
> lv2:maximum 500 ;
> lv2:portProperty lv2:logarithmic ;
> units:unit units:frequency ;
> ] .
>
> > "If the host does state saving, there is no way to have upgrades over the
> > lifetime of a plug-in.Because the host know much less about the plugin
> semantics
> > than the plugin itself. **Some plug-in parse blobs to upgrade state to a
> > seemingly incompatible plug-in version.**"
>
> If you expose the real (physical) value directly to the control ports in
> your
> LV2 wrapper, I think your issues (as you explained them in the above
> example)
> are gone, imho.
>
> > I think it's a good idea for the format acceptance, and for backwards
> > compatibility for a product existence. Such "chunk parsing" I've seen as
> an
> > intern in plugin company.
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20190330/33dda8a0/attachment.html>
More information about the Devel
mailing list