I've been putting this off for a while, but now is finally the day. We
already did this for CLAP a while back. This is both simpler and less
error prone.
This is needed to enable sending and receiving SysEx #54. Because
associated type defaults still are not stable, this requires every
plugin that doesn't need this to set this to the unit type:
```rust
type SysExMessage = ();
```
This will make it possible to run background tasks in a type safe way.
Sadly, this does mean that every plugin now needs to define the type
alias and constructor function since Rust does not yet support defaults
for associated types.
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()`.
The non-mapped version is now split off and the mapped version is much
better suited for array based modulation. Check the breaking changes
document and the new docstring for more information.
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.
Only a couple of these functions would be needed during initialization.
In the next couple commits ProcessContext will get a way to access
auxiliary IO, so this really had to be separated.
