Kudos for the new wrappers added in the 3.6.8 build of the SDK.
I’ve been testing the AAX wrapper recently and I have some questions/remarks:
- The global bypass parameter in my plug-in implementation has to be set to -1 - which isn’t accepted as valid param ID by validator - in order for the AAX Wrapper to actually expose it as the MasterBypass to ProTools. It seems to have to do with this line in AAXWrapper_Parameters::AAXWrapper_Parameters():
mSimBypass = mWrapper->mBypassParameterID == -1;
Is this intended? I see the mBypassParameterID is initialized to kNoParamId in the Vst2Wrapper constructor and later set to the actual bypass param ID in Vst2Wrapper::setupParameters() if applicable. So isn’t the mentioned line supposed to be:
mSimBypass = mWrapper->mBypassParameterID != -1;
Patching the aaxwrapper code as suggested eventually takes me down the if(mBypass) path in the Steinberg::int32 AAXWrapper::Process() function. However, the code there is a little puzzling. It doesn’t actually apply a bypass but create a silent output when the bypass is engaged in ProTools. It also seems like a change in ProTools’ Master Bypass isn’t propagated to the underlying VST3 bypass parameter. Any hints on that one?
EDIT: It looks like the current code needs to change substantially if you’re going to support a synchronization between ProTools’ Master Bypass and a bypass parameter exposed by a given VST3 implementation, anyway. I reckon the mSimBypass mode is in fact supposed to emulate a Master Bypass if the VST3 doesn’t offer any bypass parameter. As pointed out, no synchronization between an available VST3 bypass and the Pro Tools one would be going on in that case.
I observe sporadic CPU overloads, when calling into EditController::setParameterNormalized() during my audio process. I don’t need sample accurate automation and thus process my incoming parameter changes outside of the process call, which I guess is a good idea when some considerable calculus may be going on during parameter changes, anyway. However, I transfer my meters back using read only parameters, which are set during the process loop. Once I remove these, the CPU overloads go away. I can re-arrange things and use a polling mechanism so as to yield some framerate granularity in the UI regarding meters and bigger processing blocks, but I’d like to find about the actual root of this problem before.
I admit this is a rather specific one, but it seems there’s a problem with properly setting the default value of StringListParameter params. Here’s an example. In my overrider of EditController::initialize() I do:
auto powerParam = new StringListParameter(USTRING("Power"), kPowerId); powerParam->appendString(USTRING("Off")); powerParam->appendString(USTRING("On")); powerParam->getInfo().defaultNormalizedValue = 1.f; parameters.addParameter(powerParam);
Which initializes the power parameter to On in VST2 and VST3 builds. However, in AAX this doesn’t work. Any hints?
EDIT: It seems this can be worked around by adding powerParam->setNormalized(powerParam->getInfo().defaultNormalizedValue). However, I don’t think this should be necessary.
It seems that EditController::setActive() is never hit through the aaxwrapper which surely may cause some problems in certain implementations, e.g. pops due to uninitialized buffers which are reset in setActive(). I’d at least expect a call from AAXWrapper::ResetFieldData(). So would you maybe add a sequence of suspend(); resume(); there so my implementation can set itself active properly via the Vst2Wrapper?
Do you plan to add some sort of post build tool that extracts the preset banks in the tfx format into the plug-in bundle in order to expose them in the format expected by ProTools?