What is the reason for VST3PluginInstance::reset() calling setActive()?
According to the VST3 docs, setProcessing() should be fully sufficient.
In some plug-ins, setActive() triggers massive memory allocations, which heavily impacts performance when starting playback when using a lot of instances of such plug-ins.
This issue is even noted in comments in prepareToPlay(), which has extra code to avoid unnecessary calls to setActive().
Any chance to remove the offending calls to setActive() from reset()?
Well, as in a lot of cases like this, it might be that some plug-ins require that to function correctly (even though the VST3 spec says otherwise). Have you tried removing those calls? If so, does everything continue to function correctly?
It works fine with those plug-ins I’ve tried, but we’re doing plug-ins not hosts, so I only have a limited set of 3rd party plug-ins installed, and am using only the sample JUCE host.
The issue came up because it really hurts performance with our plug-in, particularly when ARA mode is used, which increases the number of instances dramatically because it’ll be one plug-in per region/clip, not per track, so heavy-duty per instance adds up much more.
Further, in hosts that call reset() from the render thread (e.g. Mixcraft), this causes setActive() to be called concurrently from various threads (albeit for different plug-in instances, but if the instances share any resources there will be lock contention issues, making the issue even worse).
I fully understand your concern about outdated plug-ins that may be bugged, but this is seriously hurting well-behaving plug-ins in otherwise well-behaving hosts. As more and more hosts and plug-ins are adopting ARA, this will become even more of a headache.
If you really want to keep the old behaviour, why not limit it to old plug-ins? For example, you could test whether the plug-in supports ARA, in which case it must be reasonably new and if there really is an issue there will be a near-time fix. There may be other interface that can be tested to reasonably determine whether or not a plug-in is under active development, for example ChannelContext::IInfoListener which Steinberg added in one of the rather recent VST3 SDKs.
