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 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.
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 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.
They are now two separate types with slightly different options. I had
these merged initially because they're 95% the same, and I thought it
would be fun to have weird distributions for integer parameters, but
that doesn't really work because hosts and the plugin APIs expect the
steps to be linear. And if you're going to have an unstepped integer
parameter, might as well use FloatParam with rounding.
Because non-linear ranges are no longer possible with IntParam, the
types have been split up to make everything much more readable instead
of adding a parameterizing the range type with another type family.
