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!!
To reproduce:
open a Drum Editor window
with that window having input focus, hit keys 0, 1, 5 ,6, 7, and then 0 and 1 again.
Behavior:
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.
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.