We now use shared memory to store the input and output audio buffers.
This means that we have to copy less data every processing cycle, since
a single copy to and a single copy from the shared memory object
suffices now. This should reduce the DSP load for VST2
plugins (especially when used in a plugin group) marginally to
significantly depending on the plugins used and the system
configuration.
Every DAW will just send all events in one go (and I think that's the
only way you should do it, but the VST2 spec is a bit leaky so who
knows). It wouldn't make much sense to preallocate more capacity,
because when DAWs do send all of those events individually they might
end up sending more than four of these anyways.
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 fixes Native Instrument's FM7 crashing on MIDI input. The plugin
expects the last received MIDI event to always be alive during audio
processing, even if there have not been any new events in this
processing cycle.
Or technically, two, since the group bridge also does the same loop. We
no longer need special handling for VST2 and VST3 plugins, so we can
simplify things a bit here.
It sort of goes against yabridge's principles to not do these
unnecessary `audioMasterGetTime()` calls if the plugin does that, but it
also hurts the user experience to not have this as a default.
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 way the sockets can be destroyed before the threads, and we can
safely wait for the threads to shut down. I initially had Win32Thread
imitate std::jthread's join-on-destruct, but that was causing group
processes to hang. Now we can safely add that back again, and this will
fix some spurious segfaults during plugin scans when using plugin groups
containing a massive amount of plugins.
Robbert van der Helm