64 bit plugins -what support is available in Juce?

[CPB]

Hmm, that sounds odd. I've been using 32-bit and 64-bit Universal Binaries for my Audio Units for a year or so on 10.5, and have never had that problem. It may be something different...

[peteatjuce]

Just my luck then.

[CPB]

I've still had no luck fixing the remaining two Mac 64-bit VST issues (ie, No UI in Studio One, and partially obscured UI when resizing), but after a little exploration with fscript, I think both issues may be related.

In both cases the NSView frame rectangles have the incorrect origin : for Studio One, the Juce NS View UI is located at (0, 1800); when resizing, the origin moves into the negative, placing the view at for example (0, -100). Using fscript to inject Cocoa messages, you can setFrameOrigin on these and place them correctly, but I can't see where things are programatically going wrong in the VST Wrapper.

[peteatjuce]

Hopefully that is a good clue for Jules.

Good luck!! Pete

[CPB]

I have a fix for the Mac OS X 64-bit VST resizing issue. I've tested this in both Cubase and Reaper, and confirmed it works in both.

The problem arises because, apparently, Cocoa NSView frame origins are based on the lower left corner, which means that if you want to resize an NSView and keep it aligned along the top, you'll also need to move the origin.

Add this to juce_VST_Wrapper.mm

Code: Select all

void setNativeHostWindowOrigin (Component* component, int newWidth, int newHeight)
{
   JUCE_AUTORELEASEPOOL
   
#if JUCE_64BIT
   NSView *childComp = (NSView*)component->getWindowHandle();
   if (childComp != nil)
   {
      NSPoint frameOrigin = [childComp frame].origin;
      frameOrigin.y += (newHeight - component->getHeight());
      [childComp setFrameOrigin: frameOrigin];
   }
#endif
}

In juce_VST_Wrapper.cpp, declare it with the other Mac exclusive function definitions:

Code: Select all

extern void setNativeHostWindowOrigin (Component *editorComp, int newWidth, int newHeight);

and call it in resizeHostWindow

Code: Select all

void resizeHostWindow (int newWidth, int newHeight)
{
      ....
    if (editorComp->getPeer() != nullptr)
         editorComp->getPeer()->handleMovedOrResized();
#if JUCE_MAC
        setNativeHostWindowOrigin (editorComp, newWidth, newHeight);
#endif



[jules]

Ok.. but I don't understand why you've added a new function... Wouldn't it have made more sense to change the existing setNativeHostWindowSize() function, rather than calling and then making another call to move it again? (I guess that when it calls setFrameSize inside setNativeHostWindowSize, it's that function that's anchoring it at the bottom corner?)

[CPB]

No: setNativeHostWindowSize is only called if the host canHostDo("sizeWindow") returns false. Because most (all?) 64-bit VST Mac hosts seem to support "sizeWindow", setNativeHostWindowSize is never actually called.

[jules]

ok, but if the host handles the resizing, then surely it's the host's job to make sure the view ends up in the right place!

[CPB]

The parent NSView view is in the right place: it's the JUCE NSView's origin that gets incorrectly placed due to Cocoa annoying "origin is at the bottom left" feature, which means that when you resize an NSView, you also need to change the frame origin.

From http://forums.macrumors.com/showthread.php?t=1064329
"In Cocoa, the origin is the bottom left. So when you adjust the view's height, the bottom of the view will stay the same and the top will change. To do what you want to do, you need to adjust the frame height and origin at the same time."

[valhallasound]

The parent NSView view is in the right place: it's the JUCE NSView's origin that gets incorrectly placed due to Cocoa annoying "origin is at the bottom left" feature, which means that when you resize an NSView, you also need to change the frame origin.

From http://forums.macrumors.com/showthread.php?t=1064329
"In Cocoa, the origin is the bottom left. So when you adjust the view's height, the bottom of the view will stay the same and the top will change. To do what you want to do, you need to adjust the frame height and origin at the same time."

Has this issue been fixed in the tip?

[CPB]

No, not yet. I think Jules is still in the middle of his big library reorganization, and the tip hasn't been updated since this fix was posted.

[friscokid]

I'm experiencing the same problem as CPB with 64 bit VST in Studio One. The host creates the container of the plugin window and the size is set correctly, but the plugin component itself does not show up. Maybe the same placement bug that was mentioned before?
With Reaper 64 bit it works.

Has anyone an idea how to fix this?

[valhallasound]

Just a quick bump to ask: What is the current state of 64-bit VST on OSX? Will the code modifications in this thread allow me to get things working? I'm not running the tip - the Jucequake fills me with fear when I get this close to the release of a new product.

Thanks,

Sean Costello

[ke20]

I have a 64 bit Mac VST running for several month now (since my last post on this thread).

[CPB]

I've had 64-bit Mac OS X's released for a while now, and the only issue I'm aware of is the 'no GUI with Studio One 64-bit'; a problem for which I generally suggest users instead use the Audio Unit. Other than that, I've had no reports of problems.

(I'm also using the pre-Juce-quake tip: my branch is dated June 10th 2011, but I've applied several patches from this thread to it.)