AU x86 plugin hosting carbon 32 bit plugin

I have the case here, where my plugin (it exposes both Carbon and Cocoa interfaces) is hosting 32 bit carbon plugin.

Everything works OK in Reaper x86 OSX, but if i load it in Logic 9.1.7, i get black window. The same happens with Tracktion 4.56 32 bit.

Now, if i disable Cocoa interface in my plugin, Logic works ... haven't got a chance to try it with Tracktion, i guess it will work as well.

Jules, can you maybe elaborate on this regarding Tracktion ? Does 32 bit Tracktion uses plugin's Cocoa interface ?

So, in this case, Is it possible to host Carbon based plugins inside Cocoa interface - i think i read somewhere this is not possible at all, so disabling Cocoa interface is the way to go ?? I hope i understand things correctly ...


Yes, IIRC only 64-bit binaries can have cocoa support for AU.

But still, it looks like Logic 9 and Tracktion detect Cocoa interface of my plugin ... ?!?


Sure, some hosts might handle that, but it's not standard.

ok, by now it is clear that 32 bit hosts support Carbon interface much better than Cocoa inteface, which is now disabled, but still ...

I've done some additional tests ... here are some facts (we are talking about AU x86 plugin wrapping VST2 x86 plugin)

- 32 bit Logic 9 Pro and Reaper are working correctly

- but i have a lot of GUI problems when using 32bit versions of Tracktion 6, Mixbus 3, Vienna, DP etc.

GUI problems are similar in these hosts - sometimes white screen is shown instead of wrapped plugin editor and Tracktion exposes heavy flickering when moving plugin, followed by a white GUI when mouse is released. Mouse click on a title reveals GUI back. In Mixbus, GUI is revealed after minimize/restore window operation. 

I am attaching links of two LICEcap animated  gifs, which show misc issues.


Jules, if you would be so kind and take a look at them ... do you have any idea, what could be the reason for this, maybe a hint where in JUCE code should i look ???

I am a bit lost digging deep down into JUCE code, i can see this Carbon stuff i really tricky.

Thank you!!!

Hard to say exactly, but this looks like either the window is getting stuck at the back, behind the others (the white one is just the juce window that's used to hold the carbon one), or it's not being given a repaint message when it gets exposed (repaint invalidation was a total nightmare in carbon, and never worked very well).

The place where it all happens is JuceAUView::ComponentInHIView - there's a lot of voodoo involved in there to get things working, and it's pretty fragile, but feel free to suggest changes if you spot something that could be done better!


What is, by your opinion, the cause for flickering when moving window (it is much more intensive than it looks in video) ?

Looks like repaint is happening all the time ...

Could either be repainting, or the window jumping backwards/forwards. Again, hard to tell.

Hm, I suspect it is window jumping ... i remove call to attachWindowHidingHooks and it stops.

It doesn't work properly (while dragging only black window in the background is moved), but flickering is gone.

I've made some progress and i am happy to say that now my plugin is working with the majority of 32 bit OSX AU hosts.

Still, i have one problem specific to Vienna Pro, which is not present in any other host.

Strangely, Vienna doesn't actually close/delete editor (deleteEditor is not called), when plugin GUI is closed (except when plugin is unloaded). To my understanding,  it only hides it, not sure about it ?!?. So, GUI of the wrapped plugin remains on the screen, regardless of my plugin not being visible.

Attaching animated gif.

I've investigated further and major problem is also that my plugin's editor's visibilityChanged() is NOT triggered when plugin window is closed by Vienna.

Any ideas, hints what could be wrong here ? Again all other tested hosts work, except Vienna Pro.



maybe "non-detection" of window close operation is the key ... but how is this possible ?

Sounds like a bug or non-standard behaviour in Vienna Pro to me. Maybe try reporting it to them, it may be easy for them to either fix it or offer some advice on how a plugin could work around it.

OK, thanks, i'll do that !

I think Musitek Smartscore (which loads only 32-bit Carbon audiounits ) has the same issue (I wrote them about that but got no reply) . I fixed it by adding a function that deletes the ‘JuceAUView’ instance (if created) at the end of JuceAU::deleteActiveEditors() . Not sure if that’s a correct fix, but it seems to work.

Vienna Pro has fixed this issue with the latest major version (i think version 6) - behaviour is now optional, by default editor is properly deleted. You can choose old behaviour, as well.