“Horizontal scrolling” has been changed, according to the Cubase 14.0.20 release notes, to be “more consistent”, but now it is messed up for me.
See, on MAC, I actually have toggled my “natural scrolling” setting set to OFF (see image below), so when I scroll down on the trackpad, the scrollbar also moves down and the content moves up (revealing more of the content below.)
Also, when I scroll right on the trackpad, the scrollbar also moves right and the content moves to the left (revealing more of the content to the right.)
And in the MixConsole, things do behave this way, VERTICALLY… and the behavior changes based on my MAC OS setting above… BUT with this new 14.0.20 change, HORIZONTAL SCROLLING is now oddly fixed in the “natural scrolling” mode, regardless. (If I scroll right, the scrollbar now always moves left, etc.)
Yeah, this is messed up. That’s not how other apps behave in MAC OS.
Yeah, it’s broken, but not only with the trackpad. It’s broken with the mouse as well. Scrolling up scrolls the mixer to the right and scrolling down scrolls it to the left. Unlike in Steinberg’s own Dorico where mixer scrolling works in the opposite way.
Not to mention that mixer scrolling in the lower zone doesn’t work at all and that normal scroll and shift-scroll do not work like in the project zone. So it’s a complete mess…
Scrolling up = Right seems the most logical to me?
Perhaps a toggle in the preferences for direction would resolve this, as a switch would confuse me. Scroll up for left doesn’t make sense to me personally
When talking about scroll directions you always have to look at both, horizontal and vertical scrolling.
The switch “Natural Scrolling on/off” in macOS affects both in unison. For a mouse wheel that would mean that either the wheel will move the scroll bar (wheel down = scroll bar down/right) or the wheel will recoil from the current view, ie. the screen will move in the direction opposite of the finger movement (wheel down = scroll bar up/left).
Why is down associated with right? And up with left? I assume that has to do with a lot of the hardware and software development in the 60’s, 70’s, and 80’s happening in countries where people were used to read the page of a book from the top left to the bottom right. This cultural impregnation got transferred into the way computers and their software works. The first pixel on a screen “0,0” is the top left pixel. The last one is the bottom right pixel.
From this point of view moving from left to right means progression, the same as moving from top to bottom means progression. Just look at all the websites, the hardly start on the bottom, do they?
So, the most common way to prgram scrolling is to set left = up and right = down and then implement a switch whether mouse wheel up equals up or whether it equals down. Left and right will follow suit.
This is how macOS and Windows work, as well as any web browser I have used so far. In fact, only Cubase and Reaper seem to behave differently.
However, you are the living example that there are human beings who would like to have a down = left scheme.
Now, my question is: do you want mouse wheel down = left only for the timeline (project view, editors) or for all windows (e.g. MixConsole)?
Shift-scroll in the project zone works as expected (i.e. follows standard conventions) - Down=Right, Up=Left. MixConsole window doesn’t work with Shift-scroll, but it has two zones - racks that scroll vertically and faders that scroll horizontally. I expect horizontal scrolling of faders here to behave like Shift-scroll does in the project zone. Not only that Cubase’s mixer scrolls differently from almost anything else, it also contradicts other parts of Cubase itself.
The best solution would be totally configurable scrolling and zooming in each part of the program. If that’s not possible, then standard conventions should be followed.
Yes, something in the Cubase prefs to set it the way you want it, for both mouse-wheel scrolling AS WELL AS using a trackpad where you can literally move your fingers left or right.
It’s instinctive to me if I want to see what’s down below, I use my mouse-wheel or trackpad to scroll down, or I grab the scrollbar and pull it down… and if I want to see what’s to the right, (skipping the mouse-wheel here) I use the trackpad to scroll right or I grab the scrollbar and move it to the right. Now, however, if I want to see what’s to the right, I have to move my fingers LEFT on the trackpad… as if I’m touching the screen and moving the content with my finger to the left WHEN I’M NOT ACTUALLY TOUCHING THE SCREEN for goodness sake.
Apple decided to flip the script on this scrolling bit years ago by making content on a MAC, by default, scroll in a “natural” way, similar to using a phone, touching the screen and scrolling… but that is not natural at all to me when I’m using a mousewheel or trackpad. Using an input device like those, I instinctively know I’m not actually touching the screen. However, when I’m using my phone, I can easily translate the movements I need to make since I’m actually, yes, physically touching the content and moving it in the direction I need it to go.
Natural scrolling is turned off because it’s not natural to me at all when using mouse.
Horizontal scrolling for me should be in that case the same as it is on Windows: scroll up = to the left, scroll down = to the right. Because for me up (scroll) = to the front of the project.
These are opposite actions, though. The “natural scrolling” is basically a switch between “content and context,” or better put, “content or scroll bar” logically. If you have natural scrolling on, then movements follow the content; but “scroll bar” movement is always the opposite of “content movement.” Grabbing the scrollbar and moving it up always moves the “content” down - you just get to choose whether you want the mouse/trackpad to move the scroll bar in the same direction, or opposite direction. “Natural scrolling” makes the scrollbar move counter to the mouse/trackpad movement.
The “problem” to me is one of “development context.” I personally like “natural scrolling” which moves the content down/scrollbar up as if I was touching the screen. This works great inside Nuendo in all cases (that I’ve found) OTHER than “event volumes and fades.” When I click inside an audio event, my brain tells me “OK, you are in the content now. As such, trackpad gestures should follow the content.” But it doesn’t; event volume acts as if there is a “hidden scrollbar” and moves the opposite direction. If I move my trackpad up, the event value decreases. This would only make sense if there was a scrollbar, but of course there’s not.
The challenge is for SB to communicate to me where they decide to act on content, or on a container. This would require that they put a wee checkbox next to “Use Mouse Wheel for Event Volume and Fades” to “Invert.” Which could work, but now you’ve got a counter of logic between the OS settings and the application settings. To ME, clicking on the event should follow the “content” rules and they should reverse this. Or just follow development rules of “if there isn’t a scrollbar in the object, then treat object selection as content.” My opinion, but yes, hopefully there will be some forward development movement on this going forward.
Also, if possible (or maybe we already can do this?), I would prefer to be able to turn the hover and scroll thing off in a lot of places in the application where I accidentally change values. Couldn’t it be that we first have to click on a field before we’re able to scroll it? Like, a single click to select the field and then be able to hover and scroll to a value, and a double-click to highlight the actual value in the field to be able to type in a new one?
Yeah, and on that same subject, gosh, if there could be some consistency between all 3rd party apps too - whether to double or single click or hover - that would be so much easier than having so many plugins behaving uniquely. Perhaps the industry could define some standards here? …like maybe even just a stipulation that certain behaviors always need to be user-definable?
It is actually very simple. This topic is about scrolling, which is moving the displayed content of a window so that other content gets displayed. (Well, I guess there is a slicker definition of it out there.)
The rest is changing values.
Yes, different things, but both are bound by the same OS-based setting to control behavior. In the Event Volume example, its behavior is defined by the same mechanism, so it seemed relevant (to me, anyway).
Not really. When it comes to value changes Steinberg will just do whatever they deem to be the best solution. When it comes to scrolling Steinberg will try to follow whatever the OS is doing.
Even if you use the same hardware controller for user input, from a design point of view these are different things.
Take the horizontal volume fader of an audio track in the Inspector.
This is not scrolling. This is “changing a value”. I assume everybody would want mouse wheel down to lower the volume setting. I also assume the same applies to track pad users, swipe down ot lower the volume. This should work independent of any OS settings that governs scroll behaviour.
The Pan slider of the same screenshot is a good example of how tricky it is to get it right. Mouse wheel down will move the slider to the right.
Two sliders directly underneath each other and that also look alike - yet the mouse wheel will move the sliders in opposite directions.
For me, mouse wheel = right feels normal. So I don’t have an issue with the Pan Slider moving right, especially since the panner is also found elsewhere without a horizontal volume slider next to it.
But I talked with one person who feels that panorama moves in the wrong direction when using the mouse wheel or a track pad. On my PC mouse wheel is ok for me, but the trackpad it actually does move the slider in the opposite direction.
In essence: there are defintely areas in Cubase where the effect of the mouse wheel or a track pad needs to be looked at.
I think we may be saying the same thing in different ways, but arriving at the same conclusion of:
The reason I used the Event Volume example is precisely because of your statement “When it comes to value changes Steinberg will just do whatever they deem to be the best solution.” The difference is that the “horizontal volume fader of an audio track in the Inspector” value change behavior doesn’t change with the MacOS “Natural scrolling” setting. Neither does the “Pan slider” below it. But the Event Volume DOES (EDIT: Meaning, behavior of the value change of Event Volume via mouse/trackpad scroll will change with the “Natural scrolling” setting).. That’s all I was trying to identify when I (rather poorly) tried to make the point of SB being consistent in the way they’ve made those decisions.
Yeah, which was what I was trying to explain about Event Volume value changes being “invisible scroll bars” because (just my luck) my preference for “Natural scrolling” means that Event Volume is backwards - you scroll down to increase the volume and scroll up to decrease it. I could have taken more time to better explain that.
And that’s the main issue here. Steinberg shouldn’t be trying to follow anything. Developers generally don’t make custom scroll views and don’t even think about mouse scrolling direction. Ideally, we either use a native UI framework or a cross platform framework that uses native scroll views under the hood. Those frameworks then take care that everything scrolls appropriately on each platform.
Steinberg probably uses their own UI framework for Cubase, and their own custom scroll view. Possibly even multiple different scroll views for different parts of the application. That’s very difficult to maintain and make any changes while staying consistent, following platform conventions and not introducing weird bugs.
