C++ would always construct an `std::string` from the string constant
every iteration. Since this also happened when `YABRIDGE_DEBUG_LEVEL` is
not set to 2, this ended up causing unnecessary allocations.
Since that makes it much clearer what we're actually doing. With old
`cache_time_info` was actually caching the response, but now we're
querying it before the plugin has even requested the information.
This can be useful when plugins have (broken) host-specific behaviour
that you want to avoid. I'll later add a list of host/plugin
combinations where this may be useful to the readme.
We'll periodically copy the scheduling priorities from the host's audio
threads to the Wine plugin host's audio threads. The overhead of doing
this is about 1 microsecond on my system, so doing this every cycle
really adds up. But getting the Unix epoch time and comparing some
timestamps has a neglegible overhead, so this should give you the best
of both worlds.
Next we'll do the same thing for VST3 plugins.
As suggested by @jhernberg
Although it hasn't shown up, this will get rid of the possibility of
off-thread effEditIdle calls causing issues. And since we need some way
to run call this function while the event loop is running anyways, doing
it entirely from a timer similar to how hosts on Windows would do it
seems like the best solution.
To account for the differences in VST2 plugins and VST3 modules we had
to wrap most of our old functions from `src/plugin/utils.h` in a new
`PluginInfo` struct that gathers all of this information while taking
into account the differences between VST2 and VST3 plugins.
With this change things are also a lot more organized. We can just query
the plugin information we need rather than having to store things
separately or having to recalculate things. This also moved the
responsibility of all the weird `WINEPREFIX` behaviour to a single place
instead of having it spread around `utils.pp`, the initialisation
message, and `host-procoess.cpp`.
Robbert van der Helm