what the title says – make scrolling in the mixconsole possible using the middle mouse button; just the way navigating around the arrange using the middle m. button is possible.
1 Like
Yup, still an issue for Cubase 12. AFAIK, the only way to scroll horizontally in MixConsole is via the scroll bar at the bottom!!!
It’s not like C12 doesn’t understand the H Scroll and V Scroll input gestures; the problem is that both Horizontal and Vertical Scroll are mapped to vertical scroll.
Even worse (and I’m still hoping someone can tell me I’m wrong) is that Scroll is overloaded everywhere such that if your mouse pointer just happens to be over a control, Scroll changes that control’s value! Gaaa! I’ve accidentally broken more things that way - precious EQ settings, etc., and depending on what it was, I might not even notice for a long time, and then have a very difficult time figuring out what changed and how to undo it. For dog’s sake people, for each gesture one and only one behavior!!! (I’d surely use the control-changing behavior iff I could assign it, say, Ctrl-Scroll, but it’s sure maddening as is, being overloaded.)
My relevant equipment: Mac Studio Ultra, MacOS Ventura 13.2.1, Apple Trackpad, Kensington Trackball
One man’s meat is another man’s poison.
You’re describing one of the most brilliant UI features in Cubendo for speedy workflow.
Sorry I was unclear: the feature of using pointing-input devices to change values is, indeed, useful - I use it myself.
My complaint is simply that this one input operation, afaik, is implicitly bound to two very different actions, scrolling AND editing, depending only on pointer location.
In UI design (not just GUI, but all user interfaces) things that cause behavior the user did not intend are called, “user traps.” This one is especially egregious as the unwanted behavior is destructive (a setting or settings get modified) and possibly hidden, e.g., in this case, if you move the pointer before realizing you changed a setting.
Think about it: one pixel this way or that changes the behavior, with no explicit choice by the user - and on big, modern screens, there are a lot of pixels, and they’re very small.
The problems regarding this operator overloading may have not been fully (un)appreciated until recently, as for a long time, the scroll wheel on mice was the only scroller in town, and it is a slightly more intentional action. On Mac, at least, multi-gestures are de rigueur, as the trackpads have gotten so much better. And where the scroll wheel on a mouse has the affordance of 1-dimensional up/downness, trackpads have the affordances of 2-dimensional scrolling/panning. So your experience with this overloaded behavior is likely much different if you use a scroll wheel or a trackpad.
So to be very clear, the only thing I’m asking for here is the option to bind these two very different operations, scrolling and editing, to two different inputs. It would not exclude making them the same input gesture, so adding said feature would not impact you any.
I understand what you are saying and you’re probably right, in essence.
And yes, I use a mouse with a scroll wheel. I can see using a track pad things would get more iffy.
I, as an end user, doesn’t have anything against making it a user preference. Unless of course more resources at Steinberg will be spent due to increased code complexity from adding further user preferences.