AU plugin not passing keypress to Live

I’ve noticed that with the recent git code (21 Apr 2010) that keyboard events aren’t being passed back to Live (8.1.3). Once the plugin has focus (which is needed for tracking the mouse to get mouse enter and exit messages) then if the user presses “space” then the sequencer doesn’t start playing and I get an operating system beep.

  • JucePlugin_EditorRequiresKeyboardFocus is True
  • 32 bit AU plugin
  • Live 8.1.3 (also happened in earlier versions of Live 8.x)

DP 7.11 also gets no keystrokes. The only host I have tested that does get them is Logic 9.x.

I’ve stepped through all the code and can confirm that the NSViewComponentPeer when - (void) keyDown: (NSEvent*) ev , the call to owner->redirectKeyDown (ev) returns false, then [super keyDown: ev] is called which then calls redirectPerformKeyEquivalent and then on to redirectKeyDown again and still returns false. This same sequence happens for all hosts.

Should there be some other listener or other mechanism for manually passing this event on to the host? I tried adding a manual call via adding a keyPressed function to EditorCompHolder with the same type of stuff that was in ComponentInHIView, but to no avail.

Any other ideas?

These are presumably hosts that are still based on Carbon, so will be using the juce carbon/cocoa hack, where it creates a cocoa window and floats it in the right place. That means that the juce NSWindow will eat keypresses, and I’ve really no idea about any workarounds that would let them get passed on up to the host’s carbon UI.

(It’ll work fine in logic because that uses NSViews for the UI, so the juce stuff all integrates nicely with the host’s UI structure)

I remember looking at this a while ago, but couldn’t figure out any sneaky hacks that would push the unwanted events to the host - suggestions welcome!

The VST version is working fine in Live. Both the VST and AU versions look like they are using an overlayed NSWindow on top of a Carbon one. Are there any major differences that would cause one to work and not the other? Can you think of any major problems with me looking at the VST code and trying to bring across anything that looks useful to the AU code?

Also I put a breakpoint in the editor’s constructor when loading the AU in Live 8.1.3 and the entry point is:

  • (NSView*) uiViewForAudioUnit: (AudioUnit) inAudioUnit
    withSize: (NSSize) inPreferredSize

Is this expected? I put breakpoints in all the BUILD_AU_CARBON_UI constructors and they don’t get hit.

I just compiled with


and the plugin still loads and has identical behaviour in Live 8.1.3 - so perhaps it’s not a carbon thing after all in this case?

Ok, that’s interesting… If it’s not carbon, then it must just be something that Live is doing - I’m pretty sure the UI code is doing the correct thing about unwanted keypresses, and the host should be able to catch them.

I’ll contact Ableton and Motu and see what the deal is. I’ll also test in few other hosts as well.

Hi Andrew,

I can reproduce this problem here with Live 8. Did you ever find anything out?

Nope, I got distracted trying to fix a bug that caused a crash when using menus in Live. I’m now in contact with a good person at Ableton, so thanks for the reminder about this key issue, I’ll email them today about it.

Another issue is in Logic the escape key is not making it to the host either, but the space bar and other keys are, very odd.

Thanks for the update. After seeing all the keyboard headaches people were having I decided not to use the keyboard in my interface and just pass all key events to the host. But in Live, I can’t even get that to work properly!

I’ve just tested in Live 8.1.4 and all seems to be working fine. This is what I do:

in JucePluginCharacteristics.h :
you need this to track mouse entered / exit events

in all editor classes:

bool XXXXComponent::keyPressed (const KeyPress& key) { return false; }

and then when you want to accept keyboard input for a text edit operation you need to create a new window and place it on top of the bit of your interface and make it disappear when you are done with it. I’ve already written a class that handles this and given it to Jules for possible inclusion in Juce.

I tried exactly what you have there under Live 8.1.3. It didn’t work-- I still got the system beeps when hitting most keys including letters and the space bar. So I just installed Live 8.1.5. Now the keys pass through just as expected. If I make a dummy event handler as you have there, it works. It also works if I just define JucePlugin_EditorRequiresKeyboardFocus 0.

One complication to what I just wrote: unfortunately the tab key is not passed through to the host in either version I built. Annoying. But for now I’m willing to downgrade this bug to a minor one since people have the option of using the VST, which works correctly. The tab key works in AU Lab, so this is probably not a problem I can fix anyhow.

The Tab key is getting passed through to Live fine here with Live 8.1.4. But I did fiddle a bit with things to try and get things working so I could have possibly changed something else. One thing to try is also overriding this:

bool XXXX::keyStateChanged (bool isKeyDown) { return false; }

In the constructor for every control I override I also call the following just to make sure:

setWantsKeyboardFocus (false);

Thanks for the help. I had tried that with the older Live version. It doesn’t work with 8.1.5 either. The scary thing is, my keyPressed method gets called when I type alphanumeric keys, space bar etc., but not the Tab key. I’m not a Live expert but it looks like Live treats Tab differently from other keys—as far as I can tell it can’t be mapped to do something other than change the arrangement view.

It’s still puzzling why your setup might be different from mine, but I’m going to leave this one be for now. For the record I should add I’m running 10.5.8.

Bumping with a little more info on this situation, and a new experiment to try.

In Live 8.2.1 I still can’t get Live to pay attention to keystrokes from JUCE. The code that sends a key up the chain to live is in NSViewComponentPerr; it looks like

[code]- (void) keyDown: (NSEvent*) ev
TextInputTarget* const target = owner->findCurrentTextInputTarget();
textWasInserted = false;

if (target != 0)
    [self interpretKeyEvents: [NSArray arrayWithObject: ev]];
    deleteAndZero (stringBeingComposed);

if ((! textWasInserted) && (owner == 0 || ! owner->redirectKeyDown (ev)))
    [super keyDown: ev];


I stepped through this in various hosts and saw that the line [super keyDown: ev]; is getting executed in each case. Logic and Garage Band pay attention to the keyDown message. Live and Numerology don’t seem to.

People have complained about this to Ableton with various plugs for years. Andrew, since it’s working for you, did you maybe apply one of the workarounds using Ableton’s config file? Hmm, I guess I should download your plugin and see if it works on my system.
Ooh, nice looking plug and docs. People say it sounds great too. OK, must investigate soon.
Anyhow, it has exactly the same problem on my machine that my plug does. Click on Live, type “a”, Live plays a note. Click on The Glue, type “a”, Live plays no note. So what’s the difference between your machine and mine? (mac OS 10.6.5, Live 8.2.1)

Since my original posts I updated to the latest version of Juce and keypresses are no longer passed to Live. Also the “esc” key doesn’t make it to Logic, even though the other keys do.

Well now. That’s interesting. Can you tell me a rough date on the previous version you were using?

I hope Jules might have some idea about what changed. But if not, I can rewind to a version without the problem and start looking around.

From what I’ve seen I’m not hoping for some keys like tab and esc ever to make it to most hosts properly. But if I can just fix the letters and the space bar in Live it will make a lot of users happy.

I’ve no idea what changed! Presumably it must be something to do with focus, but I don’t remember doing anything that might be relevant…

Do these work in other plugins running in Live, that aren’t based on Juce? For example, does VST GUI have the same Live-related issues that keep popping up in Juce plugins?

Do these work in other plugins running in Live, that aren’t based on Juce?[/quote]

Not necessarily, which is why I’m trying to focus on the keys I know we can fix. The space bar and letters work in lots of plugins under Live.