AudioProcessor::wrapperType is undefined for AU on certain machines

I ran into an issue that I cannot quite explain.

In a member function of my plugins processor, I check for wrapperType == WrapperType::wrapperType_AudioUnit.

Running the plugin in Logic 10.4.4 on two different macs makes this operation to evaluate to true on the one machine and to false on the other one, further debugging shows that it’s set to wrapperType_undefined on the machine where it compares to false.

However, the return value of PluginHostType::getPluginLoadedAs() returns wrapperType_AudioUnit on both machines. Is this expected as the public wrapperType member not intended for what I’m doing here or is this unexpected behaviour?

This sounds like unexpected behaviour. AudioProcessor::wrapperType is set in the constructor of the AudioProcessor, using whichever type is passed to createPluginFilterOfType. It looks to me like this should always be wrapperType_AudioUnit for an AU plugin.

If you’re able to debug the plugin, I’d suggest sticking a breakpoint in the AudioProcessor constructor, on the line wrapperType = wrapperTypeBeingCreated.get();. Is this line executed at all on the machine where the comparison fails? If it is, what is the value of wrapperTypeBeingCreated at this point? If it has the correct value, then that would indicate that wrapperType is being incorrectly modified after construction. You may then be able to use a memory watchpoint to find the point at which the wrapperType is incorrectly modified.

Okay, turns out this was simply a bug on our side. Long story short: We have three inheritance levels here, Plugin ProcessorIn House Processor Base Classjuce::AudioProcessor.

A non-static function was defined in the Plugin Processor and was invoked to create an argument passed to the In House Processor Base Class → the wrapperType member was read at a point where the juce::AudioProcessor had not even been constructed :man_facepalming:

So in the end it was pure luck that reading this uninitialised variable returned the expected value on one machine.

But when going through the juce::AudioProcessor implementation I wonder why the wrapperType is not const – I quickly tried changing it that way and found no obvious problems with that. Although this was not the source of our bug here, this would at least prevent unintended write access to that variable for others :slight_smile:

Yes, it does sound like a good idea to make that const, given that the wrapper type can’t change after construction. I’ll try that change out and see if it causes any issues.

2 Likes