This can now be used for most common use cases where you previously had
to do a manual `Params` implementation, like arrays of parameter objects
and duplicate parameter objects.
Instead of the previous technically-unsound approach. While it wouldn't
cause any issues in practice, it did break Rust's guarantees. That was a
design choice after adding support for editors in NIH-plug, but this is
probably the better long term solution.
The downside is that all uses of `param.value` now need to be changed to
`param.value()`.
You now need to bring your own buffer instead of the smoother having a
built in vector you would need to pre-allocate. This makes the API
simpler, and also much more flexible when doing polyphonic modulation.
In addition, the new API is much more efficient when there is no
smoothing going on anymore.
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 now is a single vector with all of the information in the correct
order instead of the hashmaps and a vector. This avoids deduplication,
and it especially makes manual `Params` implementations a lot more
convenient since you can't mess up with mismatching IDs between the
methods.
To accommodate exactly this, the persistent fields methods also have a
default implementation and the trait has been marked as `unsafe` since
it's the programmer's responsibility to make sure these `ParamPtr`s will
remain valid.
This may hurt performance in generic UIs a bit, but it will allow you to
programatically generate custom Params implementations for repeated
Parameters structs.
This method is a bit more efficient than converting the string to a
normalized value and then setting the parameter using that but it's not
used right now and it adds a form of redundancy.
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.
