I created a plain MIDI track without any third-party plug-ins or instruments.
The issue still occurred.
For the newly discovered behaviour:
I open the MIDI Key Editor in the Lower Zone.
I enter a few MIDI notes in the Lower Zone.
I select one of those notes with the mouse.
At this point, if I use context-sensitive keyboard commands such as Delete, Copy, Paste or Quantize, Cubase executes them on the MIDI Part in the Project window instead of on the selected MIDI note(s).
I then switch the visible keyboard focus to the Inspector/Editor area in the Lower Zone, so that this area receives the grey focus highlight.
Without changing the MIDI note selection, I use the same keyboard commands again.
Now the commands work correctly on the selected MIDI note(s), as if the Key Editor itself had the correct keyboard focus.
The same also applies to keyboard shortcuts for changing editing tools: they work correctly once the Inspector/Editor area has received focus.
In other words, selecting notes directly in the Lower Zone does not seem to give the Key Editor the correct command context. However, explicitly moving the keyboard focus to the Inspector/Editor area of the Lower Zone makes the same shortcuts behave correctly.
The problem is not limited to Delete/Copy/Paste or MIDI editing commands.
I can reproduce the same incorrect focus behaviour using the editing tool shortcuts.
The keyboard shortcuts for selecting/changing mouse tools are context-sensitive as well. Depending on whether the Project Zone or the Lower Zone Editor/Inspector has received keyboard focus, the shortcut changes the tool for the respective zone.
Simply clicking and working inside the note display of the Lower Zone does not reliably establish the Lower Zone as the keyboard-command context.
However, after explicitly moving the focus to the Editor/Inspector area, the same tool shortcuts address the Key Editor correctly.
This seems to confirm that the problem is not related to individual commands such as Delete or Copy/Paste. The Lower Zone note display itself appears not to acquire the correct keyboard-command focus when clicked. I will add a video below to highlight what the issue is.
This specific point follows from the combination of the general issue you’re reporting and the info bar in the arranger pane. The former seems to boil down to, though you have something selected in the lower zone key editor, any commands you apply are applying to the upper zone arranger pane. The latter shows that the info bar in the upper zone says nothing is selected (if something were, there would be data on that something there).
That initially made me wonder how you got the lower zone open with nothing selected but content in the editor, but, just trying a quick test, if I have the lower zone open with record enabled then record something, the clip does not get selected in the upper zone. If you select the clip in the upper zone, I think quantize should work again, but at the clip level due to the main issue you’re seeing.
The big question here is why Cubase thinks the focus for operations is in the upper zone when your screenshots clearly show that the lower zone should have focus (by virtue of the border around that zone instead of in the project zone).
It is at least conceivable that a plugin update could also add some support libraries. I seem to recall one issue (I don’t recall if it was in Cubase) in the past where something had installed. You could try going to Control Panel’s Programs and Features to see if maybe some Microsoft Visual C++ redistributable was installed in the time frame in question, and/or just sort Programs and Features in by the Installed On column, showing the most recent installations first to see if those might provide a clue. I’m don’t think it would be recommendable to uninstall something that showed up as a potential suspect, and I’m not terribly knowledgeable about the advice I’ve generally seen in this area, but I know there are some guidelines people have posted on cleaning things up here. My systems have always accumulated a bunch of the VC++ packges and versions (my latest, and this is on a system I only built last September or October, though I have LOTS of applications and, especially, plugins):
I do wonder a little about the two mice, if perhaps there is some conflict where both are sending signals, but, if so, I’d expect you’d see the border that shows zone focus to change.
It seems crazy to me, as well, but I just tried a quick test, where I selected some notes in the lower zone (of course I’d be able to run the lower zone commands directly at this point), but then I switched focus to the track-level inspector and hit Delete, and it still did delete the notes (I wasn’t sure it should, especially since the clip in the arranger zone was also selected.
Right. This is the one issue I’ve sometimes seen when using the full screen key editor, but where focus somehow is temporarily not there. (I see it much more frequently in going back and forth between the MixConsole to make a quick change while mainly working in the arranger, where, for example, I hit “H” to zoom in horizontally, but tracks in the MixConsole get wider instead. (I always have MixConsole full screen on my second monitor.)
One thing that may be worth trying, “just in case…” I entered the following search into Google:
cubase focus is in upper zone despite lower zone showing focus border
Of course, it shows the AI results at the top, and there were a number of things to try, starting with several to quickly force sync focus, but also followed by some things to try as “long term fixes for UI glitches”. The top ones would be quick to try to see if they help, and you could check if any of the longer-term ones might be applicable to you (e.g. the reset the window workspace).
I’ll get back with more info tomorrow. Thank you for the elaborate reply. It seems there are more similar issues that have occurred before. I have one final thought before I head off to bed: I made a new Windows user and ran Cubase there and the issue did not persist there. Renaming the Application Files and Cubase 15_64 folders in %appdata%Steinberg did not change anything on my main account though. It’s still a real headscratcher. I will check if turning off GPU Acceleration changes anything.
I made a second user profile for the same PC and in that new profile I cannot replicate the error. I guess my temporary workaround is to use a different profile for Cubase. When I get off work I will try the GPU settings in Cubase and maybe update my graphics card drivers to see if it’s down to them. It just seems strange to me that deleting the preferences doesn’t reset erroneous settings on my regular profile.
I did some further troubleshooting and have now been able to narrow the issue down considerably.
Safe Start results:
Third-party plug-ins disabled + current program preferences: issue persists
Third-party plug-ins enabled + program preferences disabled: Lower Zone works normally
Third-party plug-ins disabled + program preferences disabled: Lower Zone works normally
So the problem appears to be related to the program preferences, not to a third-party plug-in.
Additional findings:
The issue also occurs in a completely new/empty project.
The separate Key Editor window works normally; only the Lower Zone Key Editor is affected.
I have reinstalled Cubase 15.0.30.
I previously renamed/deleted the complete Cubase 15_64 preferences folder and allowed Cubase to create a fresh one, but the issue persisted.
Restoring an older backup of my Cubase 15_64 preferences folder also did not change the behaviour.
The problem does not occur when Cubase is run from another Windows user account on the same PC.
The most interesting finding therefore seems to be:
Use current program preferences → Lower Zone keyboard commands are incorrectly routed to the Project Zone.
Disable program preferences in Safe Start → Lower Zone immediately behaves normally again.
For example, with my normal preferences loaded, selecting a MIDI note in the Lower Zone and pressing Delete deletes the entire MIDI Part. With program preferences disabled, Delete correctly deletes only the selected note.
Is there a particular preference stored in Defaults.xml (or another preference component affected by Safe Start) that controls keyboard focus/command routing between the Project Zone and Lower Zone?
I would particularly appreciate suggestions for isolating the responsible preference without having to permanently reset and manually rebuild my entire Cubase configuration.
Very interesting. I’m afraid I don’t know a whole lot about what specifically disabling preferences disables, for example if it goes beyond just what is in Edit/Preferences to include various settings that are accessed from the Studio menu, Workspaces menu, or anywhere else that may be applicable. Perhaps @steve may have more insight on this. (I’ve never even used safe mode or disabled preferences.)
I know the Google search I mentioned yesterday also suggested a possible relationship to workspace corruption (in addition to preset corruption). I’ve never used workspaces, but, if you do, perhaps that could be something to check. (Unfortunately, when I do the same exact search I did yesterday, it doesn’t give me as detailed as results as it did yesterday, specifically missing the more long-term parts, which may be more likely to be relevant here.)
I think you already mentioned moving or renaming the main folder where Cubase stores its preferences, but I also know that not everything is stored there. In particular, I remember looking into this area in trying to figure out what I’d need to migrate to my new Windows 11 system from my old Windows 10 system. One post I saved a link to from the forum is this one, which talks about some other locations (no clue if any of those may be applicable here, though I don’t think they sound likely on the surface):
I did have a quick look through my preferences in Edit/Preferences, but I didn’t see anything that looked like it could be particularly suspect (and I did play with the ones relating to the editor window opening yesterday, trying to better understand the Ctrl-E you mentioned and how it behaved, but nothing I did there caused this problem to show up on my system).
So on the next startup, do it in safe mode and delete prefs.
The voluminous discussion in this thread is not really a proper troubleshooting workflow. There are too many details to wade through, so I have not read most of it.
