Using the Windows mouse settings, I disabled “Scroll inactive windows when I hover over them” for maximum compatibility.
While this still allows the foreground application (Cubase) to receive wheel window messages, it prevents those wheel messages from being delivered to other applications.
Up until Cubase 12, I was able to scroll inactive windows such as the Project window, even though the Key Editor was the active window, regardless of the mouse settings above.
Cubase 13 broke this, and I have to explicitly activate the project window to scroll.
This may seem like a small thing, but it really messes with my workflow. I might go back to Cubase 12 just for this regression.
Please let me know if there’s a Cubase setting that brings back the Cubase 12 behavior.
Steps to repro:
Create an empty project
Add instrument tracks (enough tracks that require scrolling)
Add a MIDI part to an instrument track
Open the Key Editor window for the MIDI part
Resize and position the Key Editor window and the Project window side by side
Make sure that the Key Editor is the active window
Move the mouse cursor to the Project window
Rotate the mouse wheel
**Result: The project window does not scroll.
Windows 10 Pro/64, Core i9 10900K, dual monitor, 128GB RAM, >4TB SSD
Cubase 13.0.41 Build 256 (x64), Jun 5 2024
If this is the case, (I have the option turned on, that’s my workflow) then the reverse happens to be the case. Cubase 13 fixed this. You’re asking for a Windows program to ignore system settings.
The explanation of the Windows option is for the end user; what it really means is that the mouse wheel routing follows the keyboard focus.
(The explanation of the option is not really accurate, but a simple explanation for end users who do not necessarily have a technical background.)
Mouse wheel messages were originally considered keyboard-centric messages.
Therefore, these messages follow the " keyboard focus" model for message delivery.
That is, a foreground queue is acquired and the wheel message is posted to that queue. Just before the message is retrieved by the application, it determines who has the current focus in the message queue.
This is very different from other mouse messages, which do hittest and non-client things.
The keyboard focus model is fine for most applications, but it didn’t make much sense for non-keyboard-centric applications, such as drawing applications and DAWs.
These apps implemented their own routing, which was necessary for the apps to work naturally. The Windows system did not prohibit these applications.
At some point in the development of Windows, someone figured that since the rest of Windows was changing so radically, and no one was likely to notice the difference, they might as well change the delivery mechanism.
A beta version was quietly released, but complaints actually poured in, forcing Windows to make the new wheel routing an option.
In other words, there was no need for DAWs to change because they were not meant for DAWs. So, as before, DAWs should be free to do their own wheel message routing.
Actually, it is not just DAWs. The most popular web browser, Chrome, is a good example: Chrome still does its own wheel message routing, no matter what the system settings are. UIX looks good, and no one complains.
If for some unfathomable reason the DAW wants to make changes that might break the user’s workflow, the DAW should at least provide a way to work as before.