Why are key commands sometimes unresponsive?

[THE HIPPIE]

Why is it that sometimes in the middle of my work, the key commands are unresponsive? For ex, when i press R for record it won't function, it won't record, same as some other functions as well? So i would from then start to use the mouse to click on the record button. Did i do anything to set this off? How will i make it work again?

[THE HIPPIE]

In the manual, it only teaches about key commands and assigning etc, it doesn't teach about what happens if it won't work or how to make it work back. Thanks for any help.

[ski]

I've found that when key commands don't work, it's usually down to one of three things:

 

1) the command will only work if a specific window or area has focus, meaning that it's selected. A case of a window that has multiple "focal points" is the Arrange window, where, for example, you have the arrange, event list and sample editors visible, some functions may not work if you haven't selected the appropriate area first. In other words, there are some (but not all) situations where you literally have to point Logic's nose in the right direction in order for certain functions to work via key command.

 

2) Plugin windows which steal focus from the rest of Logic: when certain plugins have focus (usually 3rd party plugins but also some Logic-native plugs), some key commands which normally work fine -- and which you should expect would work fine regardless of what window has focus -- just won't work. Here, keystrokes get diverted to the plugin, and if they're not applicable to the plugin, Logic won't respond (or it will flash the screen in the annoying way that it does).

 

3) Logic's inconsistencies (flaws in the design) which make it quite impossible to explain why some key commands will invoke the desired behavior even in windows or areas that don't have focus, as previous described.

[THE HIPPIE]

I've found that when key commands don't work, it's usually down to one of three things:

 

1) the command will only work if a specific window or area has focus, meaning that it's selected. A case of a window that has multiple "focal points" is the Arrange window, where, for example, you have the arrange, event list and sample editors visible, some functions may not work if you haven't selected the appropriate area first. In other words, there are some (but not all) situations where you literally have to point Logic's nose in the right direction in order for certain functions to work via key command.

 

2) Plugin windows which steal focus from the rest of Logic: when certain plugins have focus (usually 3rd party plugins but also some Logic-native plugs), some key commands which normally work fine -- and which you should expect would work fine regardless of what window has focus -- just won't work. Here, keystrokes get diverted to the plugin, and if they're not applicable to the plugin, Logic won't respond (or it will flash the screen in the annoying way that it does).

 

3) Logic's inconsistencies (flaws in the design) which make it quite impossible to explain why some key commands will invoke the desired behavior even in windows or areas that don't have focus, as previous described.

I like the number 3. LOL.

[shivermetimbers]

I've found that when key commands don't work, it's usually down to one of three things:

 

1) the command will only work if a specific window or area has focus, meaning that it's selected. A case of a window that has multiple "focal points" is the Arrange window, where, for example, you have the arrange, event list and sample editors visible, some functions may not work if you haven't selected the appropriate area first. In other words, there are some (but not all) situations where you literally have to point Logic's nose in the right direction in order for certain functions to work via key command.

2) Plugin windows which steal focus from the rest of Logic: when certain plugins have focus (usually 3rd party plugins but also some Logic-native plugs), some key commands which normally work fine -- and which you should expect would work fine regardless of what window has focus -- just won't work. Here, keystrokes get diverted to the plugin, and if they're not applicable to the plugin, Logic won't respond (or it will flash the screen in the annoying way that it does).

 

3) Logic's inconsistencies (flaws in the design) which make it quite impossible to explain why some key commands will invoke the desired behavior even in windows or areas that don't have focus, as previous described.

 

 

"... There were these twin sisters just turning one hundred years old in St. Luke's Nursing Home and the editor of the local newspaper told a photographer to get over there and take the pictures of these 100 year old twin biddies. One of the twins was hard of hearing but the other could hear quite well. The photographer asked them to sit on the sofa. The deaf one said to her twin, "WHAT DID HE SAY?" He said, "WE GOTTA SIT OVER THERE ON THE SOFA!", said the other. "Now get a little closer together", said the cameraman. Again, "WHAT DID HE SAY?" "HE SAYS SQUEEZE TOGETHER A LITTLE". So, they wiggled up close to each other. "Just hold on for a bit longer, I've got to focus a little," said the photographer. Yet again - "WHAT DID HE SAY?" "HE SAYS HE'S GONNA FOCUS!" With a big grin the deaf twin shouted out, "OH MY GOD - BOTH OF US?"

 

[ski]

ROFL!

[David Nahmani]

3) Logic's inconsistencies (flaws in the design) which make it quite impossible to explain why some key commands will invoke the desired behavior even in windows or areas that don't have focus, as previous described.

 

Leaving plug-in windows aside for this, do you have an example of such an inconsistency?

 

I've found that an area does not need to have focus in order for its key commands to be responsive, but it needs to NOT have another area in focus that has that key command assigned to something else.

 

WHAT?

 

OK lemme explain - I'm using the "U.S." factory key command preset here:

 

Let's say the loop browser has key focus.

 

- Press spacebar, and the selected loop will begin to be previewed. That's because spacebar is assigned to "Play/Stop Selection" under "Windows showing audio files".

- Press Enter, and the project will start playing. That's because Enter is assigned to "Play" under "Global commands".

 

If you unassigned the spacebar from "Play/Stop Selection", it is still assigned to "Play or Stop" under global commands, so even if your loop browser has focus, it will start playing back the project.

 

If you assigned Enter to something that the Loop browser can do (for example "Show File in Finder", then it would show you the selected loop in the Finder when the Loop Browser has focus.

 

Does that make sense? Personally, I have found that behavior to be both logical and consistent.

[ski]

Leaving plug-in windows aside for this, do you have an example of such an inconsistency?

 

Absolutely. Will post examples later or tomorrow. But a caveat in advance -- that in most cases my key commands bear little resemblance to the factory defaults.

[popeyepete]

Hey Hippie, I had the same problem as well. The commands were completely unresponsive. It turned out it was a 3rd party plug-in that caused the screen to flash

[ski]

Hey David,

 

After focusing (no pun intended) on this problem, I found that most of the difficulties I'm having with k/commands have to do with when plugin windows are open. However, here's a situation that doesn't make sense to me and has nothing to do with plugins...

 

My command for "new track with same channel strip/instrument" is Shift+T. So let's say I'm displaying the score editor in the Arrange window and that editor has focus. Hitting Shift+T creates a new track in the arrange area, even though it doesn't specifically have focus. But if I open a separate score editor window and it has focus, Shift+T flashes the screen at me. For me, this behavior is illogical, and here's why...

 

Shift+T isn't assigned to anything else in Logic other then "new track...." so as I see it, it should work regardless of what window has focus. BTW, that's how Logic 4 and Logic 7 worked, and the behavior was far superior to what we're forced to deal with now. But editorializing aside, here's one with a native Logic plugin...

 

Open the sample delay on a track. If by chance the cursor is hovering over the numerical value field, stop/start doesn't work! But this behavior isn't true of so many other Logic plugins.

[polo72]

Hello,

 

I'm a french user and had same problem with an AZERTY (french) keyboard. The problem disappeared when I configured my keyboard as a QWERTY one.

 

Regards, Paul.

[David Nahmani]

My command for "new track with same channel strip/instrument" is Shift+T. So let's say I'm displaying the score editor in the Arrange window and that editor has focus. Hitting Shift+T creates a new track in the arrange area, even though it doesn't specifically have focus. But if I open a separate score editor window and it has focus, Shift+T flashes the screen at me. For me, this behavior is illogical, and here's why...

 

Shift+T isn't assigned to anything else in Logic other then "new track...." so as I see it, it should work regardless of what window has focus. BTW, that's how Logic 4 and Logic 7 worked, and the behavior was far superior to what we're forced to deal with now.

 

Well Logic 8 brought us the consolidated Arrange window, with multiple collapsable areas. Logic 8 and 9 do not treat an editor open in an area of the Arrange window the same way as they do treat an editor open in its own standalone window. The area focus is also not handled the exact same way as the window focus. You're assuming those things should be the same, but they're ... just not. My guess is, if you're trying a key command in an area of the Arrange window that doesn't have anything assigned to that shortcut, it's easy to "pass" the shortcut to the Arrange area if it does something there. When you're dealing with several windows, it could quickly become messy with multiple windows open, so the key commands are not "passed" to other windows. That's how I interpret it.

 

Open the sample delay on a track. If by chance the cursor is hovering over the numerical value field, stop/start doesn't work! But this behavior isn't true of so many other Logic plugins.

The sample delay uses the pro app kit for its delay parameter. When you hover your mouse within the field, the value becomes selected but you can still use your key commands. When you hover your mouse over the value itself, you get two vertical arrows, one at the top and one at the bottom. At that point, the pro app kit takes over and expects you to use your mouse to raise/lower the value, and your key commands no longer work. Not all plug-ins use the pro app kit, hence the inconsistency you're seeing.

 

The decision to use the pro app kit comes from the general effort of giving the user a consistent experience across pro applications. The problem, as you're experiencing, is that since it's not implemented everywhere (probably because in certain places it would create problems? - just guessing here), it gives you, the Logic-only user, an inconsistent experience. Which is pretty ironic.

 

Anyway I always try to understand why things work a certain way, that doesn't mean that they should work that way, but that helps understanding why the Logic team made those decisions, which makes the pill a bit easier to swallow at times.

 

HTH swallowing the pill.