A user reported that REAPER was using these on the REAPER forum, but I
have not been able to reproduce that. And they went MIA after posting
about it. But hopefully this helps.
We had to add an even hackier hack now to get Boost.Process to
interoperate with Asio's IO contexts. This will be replaced later when
we replace Boost.Process.
I'm not a fan of Hungarian notation, but C++ kind of needs it with its
implicit `this`. And of all the common options for this, I find
suffixing members with an underscore the least offensive one.
Ardour apparently always calls `effMainsChanged()` with a value argument
of 0 when unloading the plugin, regardless of whether it has actually
initialized audio processing before that point.
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.
I once read years ago somewhere on Stack Overflow that `std::vectors`
with that are preinitialized to a default size would allocate the
initial capacity on the stack. This of course doesn't make any
sense (run time sized stack allocations can cause all kinds of issues),
so we were still allocating with our default 64-byte sized buffers, but
just not as often.
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.
Robbert van der Helm