This took me a few hours of non-stop headaches to figure out. Apparently
deep inside of Wine's headers having __MINGW32__ defined will cause some
GUIDs to be defined slightly differently. This normally wouldn't cause
issues, but when including `shellobj.h` or `objbase.h` this results in
multiple definition linking errors that are basically impossible to
diagnose.
There were already similar warnings on 32-bit winegcc, but now it also
happens on the 64-bit version. Instead of adding
`-Wno-ignored-attributes` we'll just sprinkle some warning ignores here
and there to prevent any other surprises.
This will also cause plugins to update their editors at 60 FPS. This was
kept at a lower value for performance reasons, but since the message
loop now no longer blocks event handling we can safely increase this.
This will double the amount of resources spent on drawing, but since
audio processing in a real world scenario almost never utilizes all
cores anyways this should not be an issue.
This will require more testing of course, but I think it should be safe.
This would increase the potential maximal throughput in group hosts
significantly.
std::function does not allow non-movable lambdas, so capturing by move
doesn't work there. And the old solution of course has issues with
dangling pointers (but because this is C++ the compiler still thinks
it's A-Ok).
When the message loop is active and we get an incoming dispatch() event,
we'll just handle it directly. In practice this would only be needed
when the event is a response to an `audioMaster()` call made during the
event loop, but we can't know that. This allows the `getProgram()`
during `audioMasterUpdateDisplay()` in REAPER and Renoise to work
correctly. Hopefully this doesn't cause random rare breakage.
Robbert van der Helm