64-bit VST eats keys in Ableton Live

On Mac OS 10.8, latest JUCE, Live 9.0.6 and 9.1. 

To reproduce, build the JUCE demo plugin as a 64-bit VST. Put said plugin in Live. Open the plugin window, and click directly on the plugin content to give it focus.

The plugin begins stealing important keys. Neither the musical keyboard keys nor the space bar nor the tab key make it through to Live while the window has focus.

The stealing does not happen until the actual plugin content is clicked on. Just showing the window, or giving the window focus by clicking its title bar, do not cause the problem. 

Changing JucePlugin_EditorRequiresKeyboardFocus to 0 does not change the behavior. 

The 32-bit and AU plugins do not have the problem. 

This problem was reported with the last update of my plugin in February of this year, so it's not a brand new thing. 


I found a topic here: http://www.juce.com/forum/topic/keyboard-handling-live-os-x-108 reporting the same problem, that did not receive any attention at the time. The poster has a workaround of forcibly losing the window focus. It works for me, but it's not really a good solution. 

In a 64-bit build the plugin window is an NSView so should pass key events the same way a normal component would behave if it was embedded in your app. Have you made sure that none of your components grab focus and return true from their keyPress callbacks? Because I'd expect that if all those return false, the event will be passed on to the host.

Have you made sure that none of your components grab focus and return true from their keyPress callbacks?

Are you suggesting that some of your components are doing this in the JUCE demo plugin? I don't see how I could reproduce this with the demo plugin, as I described above, unless this were the case. 


No idea, but I wouldn't be surprised if the components in the juce demo will grab focus.. The combo-box certainly will do. And even the midi keyboard might get focus, I can't remember.

As far as I remember, juce::Button grabs some key by default and others as well


Just look for setWantsKeyboardFocus(true) in juce source code

Im not talking about clicking on any of the components, but on any blank area of the window itself so that, one would think, no component has focus and keys are not stolen. But the keys are indeed stolen. 

Because this happens with the 64-bit VST, but not the 64-bit AU, or the 32-bit VST, it looks like there could be a compatibility problem with the 64-bit VST code. 



I think you're misunderstanding there. When you click the parent component, it'll probably find a suitable sub-component and give it focus. Instead of speculating and asking us about what's happening, why not just stick a breakpoint in, and watch what actually happens to the keypress event when it arrives? That's very easy to do!

What I'm trying to do is report a bug. When I compile the JUCE demo plugin as a 64-bit VST and run it in Live, it behaves in a way that is both obviously wrong, and different from the 32-bit version.

Before writing I tried to look at the underlying issue, but debugging (even via printf) has never worked properly for me in Live, which makes it hard to look into.

In my own plugins I can turn off JucePlugin_EditorRequiresKeyboardFocus to fix the problem. Having done that, I have to move on to other issues. 


Sure, understood - I'll look at it next time I'm doing some debugging/testing in Live, but in the meantime, I just meant that any clues you can add might help me or someone else think of a suggestion. It sounds like the kind of thing that'd take me hours to investigate, which is why I'm not able to immediately get on the case with it myself.

It's only the 64 bit version that has this behavior, the 32 bit version works as expected and does not steal the keys. Looks like a bug. I will update to the latest tip to see if the problem still exists.

I noticed this while i tried to reproduce the good old ableton key bug that i never could reproduce on my system but still happens from time to time on some systems:

0   ch.toguaudioline.talunolxv2       0x000000011c1b348f void juce::ListenerList<juce::Button::Listener, juce::Array<juce::Button::Listener*, juce::DummyCriticalSection, 0> >::callChecked<juce::Component::BailOutChecker, juce::Button*>(juce::Component::BailOutChecker const&, void (juce::Button::Listener::*)(juce::Button*), juce::TypeHelpers::ParameterType<juce::Button*>::type) + 79
1   ch.toguaudioline.talunolxv2       0x000000011c152449 juce::Button::sendStateMessage() + 81
2   ch.toguaudioline.talunolxv2       0x000000011c16a551 juce::Button::updateState(bool, bool) + 129

Maybe the bug is related.

The difference is that the 32-bit version will use the old Carbon HIView/WindowRef hackery, so the host may use a hook or other hacks to get the keystrokes from it, so may bypass the focus. The 64-bit version will use a modern NSView, so its keystroke handling will be more integrated into the host's view hierarchy, and it should behave more like you'd expect it to in terms of forwarding the events.

I just saw that i have enabled EditorRequiresKeyboardFocus . I don't really need this. Maybe disable this fixes both issues, the crash and the focus issue.