Site navigation

Command-Q key in Pro Tools RTAS not working

MacOSX and iOS
#1

Hi,

We’ve noticed an issue with all our Juce Mac RTAS plugins that have the JucePlugin_EditorRequiresKeyboardFocus flag set to 1. After clicking in our plugin main view, all command keys are passed properly to Pro Tools except the command-Q key. What’s odd is that you can watch the Pro Tools ‘Quit’ command light up when you press the keys, but nothing happens. If you issue another valid Pro Tools key command such as ‘space’ or ‘down arrow’ first, command-Q works as expected. Probably related is the fact that clicking in the header area in the plug-in’s parent window requires command-Q to be pressed twice before it works.

I found that command-Q does not hit the ‘keyPressed’ method in the wrapper, but all other key commands I’ve tried do. I also tested our plug-in under windows and Ctrl-F4 works regardless of how the JucePlugin_EditorRequiresKeyboardFocus flag is set.

I downloaded Juce version 1.54.27 with IntroJucer and build the sample plugin after converting it to RTAS and it displays the same behavior. I believe this is the same under PT 7, 8, 9, and 10, although my current tests were done using PT 10.

Any ideas what may be going on?

Thanks!

–
rundio

#2

Just ran into this as well… Will do some sniffing…

Strangely enough the AAX version attempts to quit (but crashes before the plugin GUI goes away).

Rail

#3

command-Q does get handled by OSX differently to other key-presses. I think that rather than triggering a key event, it gets turned directly into a shutdown message. No idea what PT might be doing to handle it in the way you describe though…

#4

Yeah, I’ve asked if they have something in the delegate to handle applicationShouldTerminate which could be a problem…

The event isn’t reaching forwardCurrentKeyEventToHostWindow though…

Rail

#5

Has anyone found a workaround for this issue?

#6

In Mac OS X 10.7 & 10.8, We discovered that ProTools will accept command-Q if the plugin component’s native WindowRef is of class kFloatingWindowClass. This can be hacked with HIWindowChangeClass where the component is attached to the native parent window.

#7

Interesting… So would this work, in juce_RTAS_Utilities.mm, line 51 ?

[code]void* attachSubWindow (void* hostWindowRef, Component* comp)
{
JUCE_AUTORELEASEPOOL

HIWindowChangeClass ((WindowRef) hostWindowRef, kFloatingWindowClass);

[/code]

#8

Has anyone else tried adding
HIWindowChangeClass ((WindowRef) hostWindowRef, kFloatingWindowClass);
to the attachSubWindow method in juce_RTAS_MacUtilies.mm as suggested by asomers and Jules?

We’ve tried it with a Juce 2.0 RTAS plugin on OSX 10.7.5 and it doesn’t make a difference. We also have tried on an AS plugin using our own AS_MacUtilities.mm we based on the RTAS file with the same result.

We also discovered that cmd-Z has the same issue as cmd-Q.

Thanks!

#9

Check out http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=10828

Rail