In Windows DLL builds we inject operator new/delete definitions into
classes with a leak detector. This requires that all inheritance from
such classes must be public, and classes inheriting from multiple such
classes must disambiguate between the base's operators.
The VST3 spec disallows adding/removing parameters at runtime.
As far as I can tell, there's no way for a plugin to signal to the host
that the unitIds of one or more parameters have changed, so I suspect
these are not allowed to change at runtime either.
Given this, I can't think of a good reason for refreshParameterList to
have any effect for VST3 plug-ins.
Previously, the bus layout was considered invalid if the host provided
an unexpected number of channels on a disabled bus. Specifically,
Acoustica 7 would prepare sidechain input buses with a non-zero number
of channels, but provide a zero-channel bus during processing.
Given that the plug-in doesn't attempt to read from disabled buses, it
should be safe to process as normal in this scenario.
According to the VST3 spec, activateBus and setBusArrangements shall not
be called when a plugin is in the 'activated' state.
Previously, if prepareToPlay was called twice in a row on a hosted VST3
plugin, during the second call the plug-in would already be activated,
but its bus layout would still be adjusted. Now, we always ensure that
the plugin is inactive before the bus properties are adjusted.
This avoids repeating the 'fallback' values in the case that the
AudioPlayHead or PositionInfo is not available.
As a side-effect of this change, when an AudioPlayHead is available but
does not supply a valid BPM value, a fallback of 120 will be used,
instead of 0. This fixes an issue where the Microtonic sequencer failed
to play in the AudioPluginHost.
