Issue: When editing in the Drum Editor (i.e, that window is open and has focus), typing the standard number keys to switch tools, e.g., 0=drumstick, 1=object selection does not work; the tool is not selected. The other tool keys, e.g., 5=erase, 6=zoom, 7=mute, do change the Drum tool, but you cannot switch back to Drumstick (0) or Selection (1). A big clue to the problem would seem to be that with both the Drum Editor window and Project window open, one can see that these number keys are also being received by the Project Window and changing the tools there!!
- open a Drum Editor window
- with that window having input focus, hit keys 0, 1, 5 ,6, 7, and then 0 and 1 again.
- Drum tool will change to Erase when you press 5, (and to Zoom for 6 and Mute for 7) but 0 and 1 do not select the Drumstick or Select tool, as they are supposed to do
- Additionally, if you have the Project window visible at the same time as the Drum Editor window, you will see that the tool selection keys are switching the tool in the Project window, which is unexpected.
- Mac Studio Ultra
- MacOS Ventura
- Cubase 12.0.52
I see what you’re saying. They only work in the Windowed editor, not in the lower zone,. Is that what you see?
The two windows, Drum Editor and Project Window, seem to be sent the same keystrokes, regardless of focus. Almost: with both windows visible you can see that some of the keys change to different tools in both, but some keys, e.g., 1, and 7, for example, do not switch to the Select or Mute tool in the other window.
IMHO, the window in focus should be the scope in which the keys are interpreted, at least wrt tool selection Key Commands. At the very least it should be consistent!!
A secondary problem, which I may write up separately, if it isn’t already, is that the Tooltips for the numeric tool selection do not reflect the actual Key Command assigned; they always show the factory default!
As far as I can tell, this problem is consistent whether the Drum Editor is in its own window or in the lower section.
I see a few obvious solutions:
Give the focused window first priority for handling keys. If, in this example, the Drum Editor doesn’t have its own key map for the key (e.g., Transport controls), the key is passed upwards to its parent, i.e., Project Window. This arrangement allows for Drum Editor and other windows to have their own key handling - this is what MixConsole does now: arrow keys, zoom keys, etc., behave differently depending on which has focus. while still having globally-scoped Key Commands, e.g., Transport, to work the same regardless.
Give all* windows the keys, with everyone using the one master Key Command list. This has some advantages, too: I sometimes find it frustrating that some keys are interpreted differently when MixConsole has focus vs. Project Window.
- “All” is of course superseded when a text input control is activated; then keystrokes go to that control, as you’d expect, i.e., in typing in fields.
The keystrokes should work correctly, this should probably be considered a bug.
If you feel like doing this: How to format a bug report it can be forwarded to the dev team, or get in touch with tech support.
Since I don’t see the same behavior, and you’re on Mac I can’t do it.
RE filing a bug: that was my intent with the OP, e.g., “issue” tag, steps to repro, expected behavior. Did I miss something?
- Are you saying that on Windows all of the top-row number keys behave exactly as expected in the Drum Editor & Project Window (simultaneously)?
- If you change the Key Commands for Tool selection, is that new key reflected in the Tooltip, or not?