Apple plugins

Not quite sure what to make of this one, but I have always had some issues with almost any of Apple’s AU plugs in juce.

Apple plugs seem to load ok, but if I try and get the editor I get the following error (notice that it’s a cocoa based UI, also):

2010-07-19 05:21:39.755 FlyLoops[1725:a0f] *** Assertion failure in -[AUFilterCustomView parameterValue:], /SourceCache/CoreAudioUI/CoreAudioUI-65.4/Source/CoreAudioUI/AUUI/CocoaCustomViews/EQ/Filter/
JUCE Assertion failure in /Users/aaronleese/juce/amalgamation/../src/application/juce_Application.cpp, line 103

The error occurs when paint is called and so (naturally) resolves if I use GenericAudioProcessorEditor() instead of createEditorIfNeeded(). Otherwise, nothing much I can figure out.

The plug is fine in Ableton, etc … so I’m guessing it’s something to do with the AU-UI wrapper code ? Not sure. I would check the file referenced above, but I’m not sure where it is … never have figured out where macs keep their system included AU files.

Anyway, I’m curious what you make of it … lemme know if it makes any sense to you.

Well, it shouldn’t really be throwing exceptions no matter how the host calls it, but I guess maybe there could be some kind of workaround that’d stop this triggering. It’d be interesting to see a stack trace to find out what the host was calling when it happening.

Yeah, I don’t think you will get much from this, it seems to just be the messageManager crapping out for some reason.

Again, if I step through it, it seems to happen after paint(), and only for Apple’s published AU plugs (most third party AUs work fine).

Yeah, you’d need to get the debugger to catch the exception when it gets thrown - not much point showing the stack trace of the fallback exception handler routine.

ok … here’s a somewhat better one for you:

Again, looks like it comes up after the paint routine kicks in … the error seems to revolve around the name??

Not sure what to make of it … as you can see from the background, the UI seems to have come through ok, but something is still crashing it.

Stepping through it one line at a time doesn’t yield anything illuminating … just the high level event loop running though it’s routines … it’s mostly assembly. Then it hits this.

Like I said before, showing the stack trace of the fallback exception handler is a waste of time - the exception has already been thrown and caught, and you’ve missed it. Enable the “stop on objective-c exceptions” menu option and you might actually be able to catch it when it happens!

Aha!! Genius. Why have I never noticed that option before … I mean, I’m still new to Objective C, but why would that not be enabled by default.

Whatever … here is where it get to now … somewhat more intelligible.

So, going into the setBounds function we have appropriate values for x,y,w,h. However, this line :

 r.origin.y = [[[NSScreen screens] objectAtIndex: 0] frame].size.height - (r.origin.y + r.size.height);

returns 0 for all values. Could that be the issue?

Hmm, that’s pretty strange, it just seems to be crashing inside apple’s code somewhere. Maybe this is just an internal exception that could be safely ignored, but I’ve really no idea. Did it print any helpful messages to the console?

[quote] r.origin.y = [[[NSScreen screens] objectAtIndex: 0] frame].size.height - (r.origin.y + r.size.height);

returns 0 for all values. Could that be the issue?[/quote]

Nope. That line is fine.

No, not sure what it is.

As I said, it’s just Apple’s AU plugs, and goes away if I use generic UI.

After the command I mentioned returns all 0’s it tries to resize the window (to 0,0,0,0) … which seems like it would be the problem.

Ok … looking at this again. There are some plugins that have similar problems but are not Apple. I am certain that I was able to view this plugin UI previously, as well.

So … here is another trace that may be helpful:

Looks to me like the carbon window hasn’t been created correctly? Notice the output in the background … it looks like the closeUI routine was called several times before the openUI … not sure if thats right, but it seems to happen with most plugins.

I can’t see anything wrong with that… It’s crashing in the plugin’s code, but it doesn’t look like the host is doing anything it shouldn’t. Don’t worry about the UI closing messages, that’s not important.

Fair enough. I checked, and this one actually crashes in other hosts as well … so excuse my hastiness.

None the less - Almost all of the Apple plugs, as well as FreeVerb and a few others crash when trying to get the UI.

They do not crash in other hosts … so I am curious what the difference could be? It does look like Ableton might be using a generic view for them though … is this something that could be incorporated into JUCE? Is there an easy way to create a failsafe to test if a plugin can return an appropriate custom UI, and then instantiate a generic one if not ?

Can’t really think of any other ideas, it’s hard to guess why a plugin is crashing if you can’t actually see what’s happening inside it.