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 properly support polyphonic modulation, since the
modulated value may still be automated in the meantime and the
polyphonic modulation must act as an offset for that value. This does
mean that the plugin must add the normalized value and normaliezd offset
by itself. The `PolyModulation` event now also contains a description of
how this can be used. It would have been nicer to be able to send
polyphonic automation-style events instead (like the PolyModulation was
doing before), but that's sadly not feasible without NIH-plug being
involved in the voice management.
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.
