We can use this to detect which plugin formats are supported by a
plugin. Otherwise the bundler would be very awkward to use when
supporting multiple formats.
This makes the API much, much nicer (especially consuming the egui
wrapper), and it also avoids having to lock the plugin instance which is
obviously very bad if the plugin is also supposed to be processing audio
on another thread.
This needs a lot of work. We need widgets that know how to deal with our
parameters, and also basic widgets for things like meters. Egui-baseview
also has a couple quirks left. Most notably it only updates when
actively moving over the GUI (which means VU meters look pretty janky)
and it randomly panics.
There are a lot of locks needed now here, but none of them should be
contended. This is much better than potentially having RefCell's blow up
due to simultaneous mutable borrows, and the Arc is needed for the event
loop.
On second thought, this is much better. The resulting file size will be
much smaller because only double quotes need to be escaped. It's also
easier to read at a glance.
This still takes up more space than plain JSON would, but I don't know
if serde_json would allow inlining that JSON. Presumably not. It would
get hairy quickly as a regular embedded JSON string due to the encoding.
I much prefer kebab case, but snake case is better here since Rust would
convert it to snake case when used as an identifier anyways and you also
can't use snake case modules without explicit module path attributes.
These atomics make things more difficult and they don't solve the main
problem: storing the parameter objects in an easy to use struct while
still allowing hash based access to them from the plugin wrapper. Going
through this new Params trait makes a lot more sense, and with pinning
this should be safe.
