The suffix was added to denote that this could do some funny things
because of the snapping to the target value, but in practice that
snapping distance will likely be so tiny that it is likely not
noticeable.
Based on a one-pole IIR low pass filter that reaches 99.97% of the
target value in the designated time before snapping to that value. This
will be less efficient than the linear FIR smoothing style.
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.
Direct initialization was no longer recommended anyways since now you
need to keep the default value in sync. The next couple of commits will
add a normalized value field and two more fields to help with
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.
