We are in the process of porting plugins from SDK 2.4 to 3.7. Everything is perfect, but we have a critical doubt in our case.
When we initialize in AudioProcess, we use :: initialize (FUnknown * context), to create memory for lookup tables, many of which depend on the sample rate. At that moment of initialization, we see that :: setupProcessing (ProcessSetup & newSetup), has not been called and does not necessarily contain the sample rate of the session or project where the instance is inserted. That is, even though :: initialize seems like the ideal place to create tables and possibly the kernel (dsp process), we may not have the correct sample rate. We see that when :: setupProcessing is called, it is when the rate corresponds to the real one of the session. There is a possibility to know the correct sample rate at init time ( at :: initialize, for example). Perhaps the host can be “interrogated” to get the sample rate in :: initialize.
you should use IAudioProcessor::activate(bool) instead of IAudioProcessor::initialize(FUnknown*) to create your dsp kernels/objects.
You can use initialize for stuff that does not depend on sample rate or sample size.
I don’t see the IAudioProcessor :: activate (bool) method in the interface of the IAudioProcessor class.
The closest thing is IComponent :: setActive (TBool), in IComponent.
But simulating initialization failures in that method by returning kResultFalse, or kInvalidArgument, or kNotImplemented, kNotInitialized … etc, some hosts swallow the result as good and continue without problem .
Either way you were referring to IComponent :: setActive (TBool)?
Ah yes, I meant IComponent::setActive().
If a host start to process your plug-in when you return anything else than kResultTrue from setActive() is a bug in the host and should be reported to the host developers.