Odd Pro Tools plugin behavior with multiple monitors (mac)


We discovered all our Juce Pro Tools plug-ins have an issue if the PT project is saved with a plug-in positioned on a second monitor. The symptoms vary somewhat between Leopard and Snow Leopard but the issue appears on both platforms. The main problem is that our UI doesn’t appear in the same place as the host window. In some cases the UI shows on the second monitor, while the host ‘container’ window appears on the main monitor. Sometimes the UI and host window appear on the same monitor (primary or secondary) but not lined up properly.

I also see the behavior in the Juce demo plug-in. If the plug-in is on the primary monitor, closing and reopening the plug-in fixes teh display issues. This does not work if positioned on the secondary monitor. Also, if the second monitor’s bottom is not lined up with the bottom of the primary monitor, closing and reopening cause the plug-in to change positions vertically when re-opened.

This sounds somewhat familiar to the “Default monitor doesn’t fit me” post from late June of this year where the wrong screen is being used for positioning calculations. I was able to verify this by looking at coordinates in the juce_RTAS_MacUtilities.mm files in the attachSubWindow method inside the WINDOWPOSITION_BODGE #ifdef.

We’re building with Juce v1.51.2 (amalgamated.) I’ve downloaded the current tip and didn’t see any changes in that part of the code. I’m working on getting our code to build with the latest code. In the meantime I posted this because I haven’t found this specific issue mentioned in the forums.

Is anyone else experiencing this issue?


aka: Louis Sinclair

That’s odd, because I remember specifically fixing and testing this problem about a year ago… Can’t remember the reason for it though…

Same bug here…

Thanks for the quick reply, Jules. And thanks Alex, for confirming the issue.

I have more information on reproducing this behavior. I built the Juce Demo plug-in (RTAS) using the tip (downloaded on July 8) and in both Leopard and Snow Leopard, I can reliably reproduce the problem under the following conditions:

  • Primary iMac monitor: 1680 x 1050

  • Secondary monitor: 1280 x 1024, positioned to the left of primary with the bottom edge lower than the primary bottom edge (-219 pixels in my last test.) I don’t see the problem If the bottom edges of the two monitors are aligned in Display Preferences.

  • Save a Pro Tools project with the demo plug-in positioned on the second monitor. (Pro Tools 8.0.3)

  • Quit Pro Tools, restart and open the project. The plug-in UI appears above and totally outside the host frame window.

  • Closing and reopening the plug-in UI results in the plugin moving further down the screen each time it is re-opened.

Hopefully this will help locate the source of the problem.


aka:Louis Sinclair
Minnetonka Audio Software, Inc.

Thanks. I’ve not got a functioning PT setup at the moment so can’t try this, I’m afraid… Will have to wait a while unless someone else can do a bit of digging. It’ll just be something that needs tweaking in juce_RTAS_Utilities.mm, line 82ish.

Thanks, Jules. I’m playing with the code in that area now. If I find a fix I’ll post it.

I’m finding that the symptoms vary depending on the relative resolutions of the monitor, so my statement about aligning the bottom edges turns out to only work if the screen resolutions match the specs I was testing with.

aka:Louis Sinclair
Minnetonka Audio Software, Inc.

OK, I believe I have a working fix:

In a nutshell, the height of the main monitor needed to be used rather than the secondary monitor in calculations, and the bottom coordinate of the secondary window wasn’t needed.

The following code is from the middle of attachSubWindow in juce_RTAS_MacUtilities.mm. Lines ending with “// masi fix” show my changed code, and the old code is commented out to show the difference.

I applied the same change to juce_AS_MacUtilities. The only difference with AS is the additional subtraction of 32 to account for the space below the plugin that contains the ‘Process’ button.

I tested these changes with Snow Leopard running PT LE 8.0.3, Leopard running PT LE 7.4, and Tiger running PT LE 7.5.

NSRect hostWindowScreenFrame = [[hostWindow screen] frame];

int mainScreenHeight = [[NSScreen mainScreen] frame].size.height;	// masi fix

Rect winBounds;
GetWindowBounds ((WindowRef) hostWindowRef, kWindowContentRgn, &winBounds);
NSRect w = [hostWindow frame];
w.origin.x = winBounds.left;
w.origin.y = mainScreenHeight - winBounds.bottom; // masi fix
//w.origin.y = hostWindowScreenFrame.size.height + hostWindowScreenFrame.origin.y - winBounds.bottom;
[hostWindow setFrame: w display: NO animate: NO];

NSPoint windowPos = [hostWindow convertBaseToScreen: f.origin];
windowPos.x = windowPos.x + jmax (0.0f, (oldWindowFrame.size.width - f.size.width) / 2.0f);
windowPos.y = mainScreenHeight - (windowPos.y + f.size.height);	// masi fix (for AS, subtract 32 at the end of the calculation.)
//windowPos.y = hostWindowScreenFrame.size.height  + hostWindowScreenFrame.origin.y - (windowPos.y + f.size.height);

comp->setTopLeftPosition ((int) windowPos.x, (int) windowPos.y);

aka:Louis Sinclair
Minnetonka Audio Software, Inc.

hmm - that’s almost exactly the same code that I replaced in november, under the GIT comment “fixed an RTAS dual-monitor window position problem”. I can’t remember any more details about exactly why it didn’t work though…


  Some of our users report the same incorrect behaviour using RTAS and dual monitor setup.


Hi Jules. Do you have a PT setup running nowadays? PT9 is available - you need an iLok2, but otherwise it should be a free download for Digidesign RTAS developers.

I’ve had the same bug reported for my RTAS plugins on a dual-monitor setup.

Sean Costello

No, I need to sort one out, actually… It’s on my to-do-list.

No, I need to sort one out, actually… It’s on my to-do-list.[/quote]

It would be greatly appreciated. :mrgreen:

The good news is that plugins compiled with the PT_80 SDK seem to work fine in PT9. And I love the fact that PT9 only requires the iLok, which is a much smaller dongle than the MBox Pro I’ve been using.

While were talking Pro Tools, any idea how much effort it would be for an AudioSuite target? A customer asked so I might as well pass on the request. To be honest, my guess is that it is a MUCH smaller target/need for the Juce audio plugin framework than 64-bit VSTs for OSX will be in the future, but it doesn’t hurt to ask.

Sean Costello

No, sorry, ain’t gonna happen!

No, sorry, ain’t gonna happen![/quote]

That’s what I figured. That one guy is going to be disappointed.

Had the same bug here, but the suggested fix totally worked.
This should be integrated into the current tip, since up to now (2011 May 27) it still has this bug.
Thanks to rundio!

Ok, but don’t ignore my comment above! The change that rundio suggests is actually a roll-back to the way I used to do the calculation, but that had some other problem that made me change to the current version… I seem to remember it maybe involved the main PT window being positioned on the second monitor… Or perhaps different versions of PT need different solutions for this. Anyway, please don’t assume that the suggested fix is without problems!

Ok, thanks for the hint. I could not produce any errors with the suggested code, but I’ll do some further testing with other monitor setups and keep you informed if there will be bugs.
My current setup is:

  • Pro Tools 9
  • OSX 10.6
  • Pro Tools SDK 9.0 (The 9.0 SDK works without problems with your existing wrapper, both on Win and Mac. I just had to change the “ePlugIn_StemFormat_7dot1” to “ePlugIn_StemFormat_7dot1SDDS”)

I tried the code above, but unfortunately it did not work for me…

My setup:
External monitor 1920x1080px on top, with Mac OS X menu bar on top
Macbook 1280x800px on bottom, with dock on bottom.

X-alignment of windows is always right, but I still have some Y-alignment issues.

My Pro Tools setups is having the transport window (the one where you edit the audio) on the big screen on top, and the mixing window on the Macbook on the bottom. When I instanciate one of my plugins, it first displays on the top screen, with (sometimes) the GUI offseted to the top from the window. When I close and open the window again, the GUI completely separates from its window, and at each opening they move down a bit more.

By the way, I checked the variables in this part of the code, and I noticed the following:
[]According to MacOS, my external monitor is the “main” monitor (it’s there I have Spaces displaying when activated, the menubar, my desktop icons).[/]
[]According to the code, the mainScreenHeight is 800px (that’s the Macbook then).[/][/list]

Maybe the problem is due to the fact the code is considering the native screen (the one on the primary video output port) as the main, and the external (on the auxiliary video output port) as the secondary display, instead of following Mac OS’s configuration…


According to Mac OS Documentation about NSScreen, the main screen (the one with the apple menu and the icons on the desktop) is not always the one returned by mainScreen, but it can be found at the first position of the arrays available in the system, by calling [[NSScreen screens] objectAtIndex:0].

I’m trying with this code:
int mainScreenHeight = [[[NSScreen screens] objectAtIndex:0 ] frame].size.height;

It seems to work! I’ll let our beta-testers run some more tests, but it sounds promising :slight_smile:

Hum there are still some problems…

When the ProTools window is not on the main display, the whole plugin (window & GUI) still appears on the main screen, this is quite annoying. The best thing to do would be to get the screen ProTools is being displayed on as a reference. I posted this to the Digidesign dev team, see if they can help.

I just tested applying rundio’s patch and Franky’s mainScreenHeight calculation and things seem to work much better in PT8 - opening, resizing several plugin instances works fine on the secondary monitor, and also loading a project works as intended and the plugins show up at their right location.

Even though there’s a risk some obscure bug will re-appear, I’d vote for including that patch (or revert to your previous version) until you find the time to check this out yourself with a PT setup.