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.
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()`.
Existing instances will automatically be upgraded to these IDs when the
instance gets saved. This makes it possible to rearrange things later
when needed.
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.
We should indeed be windowing twice like we did before. A squared Hann
window doesn't work at 2x overlap, so that option has been removed. The
gain compensation is now also correct.
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.
