This allows plugins to migrate old state, for instance when parameter
meanings change, new parameters are introduced, or parameter IDs have
been changed.
This is needed to be able to support modulation events in CLAP. There an
offset gets applied to the parameter's actual current value. That way
GUIs don't have to move around when parameters are being modulated and
save states cannot get influenced by modulation.
This is a breaking change requiring a small change to plugin
implementations.
The reason why `Pin<&dyn Params>` was used was more as a hint to
indicate that the object must last for the plugin's lifetime, but `Pin`
doesn't enforce that. It also makes the APIs a lot more awkward.
Requiring the use of `Arc` fixes the following problems:
- When storing the params object in the wrapper, the `ParamPtr`s are
guaranteed to be stable.
- This makes it possible to access the `Params` object without acquiring
a lock on the plugin, this is very important for implementing
plugin-side preset management.
- It enforces immutability on the `Params` object.
- And of course the API is much nicer without a bunch of unsafe code to
work around Pin's limitations.
This may hurt performance in generic UIs a bit, but it will allow you to
programatically generate custom Params implementations for repeated
Parameters structs.
Now it no longer needs to do any unsound type punning. The internal
parameter that the wrapper has access to has been completely type
erased, and only the outer parameter knows about enum T. This also gets
rid of strum and replaces it with a custom trait.
On second thought, this is much better. The resulting file size will be
much smaller because only double quotes need to be escaped. It's also
easier to read at a glance.
This still takes up more space than plain JSON would, but I don't know
if serde_json would allow inlining that JSON. Presumably not. It would
get hairy quickly as a regular embedded JSON string due to the encoding.
