AUGenericView fails to be created right away

MacOSX and iOS
1

Hi,

I got a problem trying to load MDA plugins in my application:
[list]
[]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): http://web.archiveorange.com/archive/v/q7bubyotq80HVdIPTLW0

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?

2

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

3

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 juce_AudioUnitPluginFormat.mm 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))
{
  @try
  {
    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.

Thanks.

4

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];
    }

[/code]

…?

5

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: