AUGenericView fails to be created right away



I got a problem trying to load MDA plugins in my application:
[]I recover the list of plugins from XML[/]
[]Instantiate the plugin[/]
[]Try to create a default editor window[/][/list]
And then I get a crash inside apple’s methods. When googling it, I found someone who got the exact problem and stack (and who is apparently on this forum as well):

I confirmed that, when first loading another AU plugin, like Apple’s Filters, or just rescanning all my plugins (which will in turn try to initialize those Apple Audio Units), creating a default window for this MDA plugin then works.

This sounded like a Dynamic Loading issue to me, so I tried to use NSBundle class methods to see the difference between before and after loading the Apple plugin:

>     "NSBundle </System/Library/ColorPickers/NSColorPickerPageableNameList.colorPicker> (not yet loaded)",
>     "NSBundle </System/Library/ColorPickers/NSColorPickerSliders.colorPicker> (not yet loaded)",
>     "NSBundle </System/Library/Components/CoreAudio.component/Contents/Resources/CoreAudioAUUI.bundle> (loaded)",
>     "NSBundle </System/Library/ColorPickers/NSColorPickerCrayon.colorPicker> (not yet loaded)",
>     "NSBundle </System/Library/ColorPickers/NSColorPickerWheel.colorPicker> (not yet loaded)",
>     "NSBundle </System/Library/ColorPickers/NSColorPickerUser.colorPicker> (not yet loaded)"

Apparently, the only difference is CoreAudio. But unfortunately, calling

[[NSBundle bundleWithPath:@"/System/Library/Components/CoreAudio.component/Contents/Resources/CoreAudioAUUI.bundle"] load];

before creating the other plugin doesn’t seem to solve the issue… :frowning:

Any idea?


Can anyone at least confirm the problem is reproducible on their configuration? With any MDA plugin, like Leslie for instance (
Just to see if it has something to do with OSX version.


Ok this is also reproducible in juce “Audio Plugin Host” demo.

After tracing all the code, I’m now convinced that it’s not a problem with Juce (who would have doubted? :wink: ), rather either in Apple’s AUGenericView API, or the plugin doesn’t do something it was supposed to do, or both, I don’t know.

Anyways, Jules, would it be possible to wrap the call to AUGenericView in in a @try/@catch statement to ensure such bugs in third party API don’t crash everything?
Something really easy like:

if (createGenericViewIfNeeded && (pluginView == 0))
    pluginView = [[AUGenericView alloc] initWithAudioUnit: plugin.audioUnit];
  @catch( NSException * e )
    DBG("...a message to the developer who wonders why this damn UI doesn't show up...);
    // Maybe some cleanup? My skills in objective-C aren't good enough to tell what happens with memory
    // if the alloc succeeds but the init fails.

would be great.
Then it’s up to the caller to check if the editor Component really was created or is null.



Erm… My version of the code looks like this:

[code] if (createGenericViewIfNeeded && (pluginView == 0))
// This forces CoreAudio.component to be loaded, otherwise the AUGenericView will assert
ComponentDescription desc;
String name, version, manufacturer;
AudioUnitFormatHelpers::getComponentDescFromIdentifier (“AudioUnit:Output/auou,genr,appl”,
desc, name, version, manufacturer);

        pluginView = [[AUGenericView alloc] initWithAudioUnit: plugin.audioUnit];




Well… your version of the code is from the “Modules” branch… I suppose you won’t want to retrofit any bugfix into the Head?

I will switch to the “jucequaked” revision as soon as I can I promise. But my priority for the moment is to work on the things that are supposed to help me pay my bills… :oops: