Plugins always on top

I am working on a plugin that can host other plugins.

I think I already pointed out, that it is was (with the Carbon JUCE version) impossible to have a plugin in a window that always stays on top because of some strange JUCE bug that made the plugin “jump” a few pixels down when one clicked outside of it.

Maybe this is now gone with Cocoa, but the problem is that there are still many Carbon hosts out there and my plugin will only work in those hosts if it is also Carbon (is that correct?), so I still have to compile using Carbon JUCE.

But then - using Carbon JUCE - the problem of not being able to have the plugins hosted in my plugin “always on top” is extremely frustrating.

What should I do?

I think the only remaining possibility seems to once for all fix JUCE in Carbon and get rid of this bug.

No, the new cocoa stuff lets your VST work in a carbon host too.

The only exception is for AUs, where I took out the carbon UI, and left it only able to generate a cocoa UI. But despite this, a carbon host should still be able to load an AU with a cocoa UI - there’s an apple paper explaining how to do so, and you’d hope that the host makers would have implemented this.

Cool, that’s good news! I thought it wouldn’t work because somebody wrote in the “Cocoa!”-Thread:

Ah, well maybe those hosts don’t actually support the cocoa UIs…

Ok, could you please answer my initial question then?

Well, if it becomes a real problem with hosts not supporting cocoa UIs, it’s possible to write a carbon UI that wraps the cocoa one. It’s a PITA though, and I’d rather avoid doing it if possible.

Why don’t you just fix once time and for all those bugs that cause this? I mean, this is not a Carbon issue, it’s a JUCE bug that should have been fixed since a long time ago. I’m sure it’s just 1 or 2 lines of code that are wrong for causing this. It’s not a Cocoa/Carbon question.
I am sure, if you take one hour, you can do this, and it’s gonna be a big plus for all JUCE users out there that write plugin hosts.

Please try to host Camel Phat in the Plugin Host, it will only show you the controls, but the main GUI is missing!? Very bizarre.

Well, I fixed the old Carbon code for me to work (JUCE 1.46). Plugins UI’s now don’t do any bugs now, and the plugin window always stays on top.

If anybody’s interested, it’s just 2 lines:

in RepaintManager::createNewWindow() replace the line

if (!getComponent()->isAlwaysOnTop()) CreateNewWindow (kDocumentWindowClass, attributes, &pos, &newWindow); else CreateNewWindow(kUtilityWindowClass, attributes, &pos, &newWindow);

You will have to call setUsingNativeTitleBar(true) and setAlwaysOnTop(true). Non-native JUCE windows still do the weird bug where controls of the inside AU or VST jump down.

Example (from JUCE’s PluginHost distributed with JUCE 1.46):

[code]PluginWindow::PluginWindow (Component* const uiComp,
AudioProcessorGraph::Node* owner_,
const bool isGeneric_)
: DocumentWindow (uiComp->getName(), Colours::lightblue,
DocumentWindow::minimiseButton | DocumentWindow::closeButton),
owner (owner_),
isGeneric (isGeneric_)
{
setSize (400, 300);

setUsingNativeTitleBar(true);
setAlwaysOnTop(true);

setContentComponent (uiComp, true, true);

setTopLeftPosition (owner->properties.getIntValue ("uiLastX", 20+Random::getSystemRandom().nextInt (500)),
                    owner->properties.getIntValue ("uiLastY", Random::getSystemRandom().nextInt (500)));
setVisible (true);

activePluginWindows.add (this);

}[/code]

Here’s another bug I found in JUCE’s AudioUnit hosting code. It’s the bug that made AU GUI’s controls jump down and also caused AU crashes.

The third parameter used by AudioUnitCarbonViewCreate() in openPluginWindow() must not be HIViewGetRoot ((WindowRef) getWindowHandle()) as it is now, but should be “rootControl”, which must be found this way:

ControlRef rootControl; OSStatus err; err = GetRootControl((WindowRef) getWindowHandle(), &rootControl);

From an Apple technical note:

[quote]GetRootControl/CreateRootControl vs. HIViewGetRoot
Regardless of whether the kWindowCompositingAttribute is set on the window, HIViewGetRoot always returns the Root View of the window which represents the total structure of the window and which is where all the standard window widgets (close, minimize, zoom buttons, resize control, and so on) live.[/quote]

I think this bug still affects the new Cocoa code.

Interesting… I can’t find anywhere in the cocoa code where it might apply at the moment, but if I put back support for carbon au view, then it’ll probably be needed there!