Disable mouse fader movement in the mix console

The feature is the bomb. It works very well, it even works when I don’t want it to work! I don’t want the feature tampered with, it’s fine, really. The way I see it, we have a conflict of philosophy here of whether the scrolling in the mixconsole is vertical or horizontal.

Because, in the project window, scrolling horizontally is done with a modifier. Shift + mousewheel. Vertical scrolling, or rather, scrolling through the tracks is done by mousewheel only.

Now, I can see how from a tech perspective one would find it elegant and intuitive to say “scrolling through the tracks/channels is done by mousewheel whether in the project or in the mixconsole” and let the user figure out that in the first case it’s in the up/down direction, and in the second case it’s in the left/right direction.

But isn’t it equally intuitive to say “To scroll left/right in any window, use Shift + mousewheel”? In my opinion it is, but then we stumble upon the problem of fine parameter change that is performed by shift+wheel over a value field. Instead of making huge unintended changes, we would only be making very small ones.

It’s not an easy problem to solve. Speaking only for me, my preference would be if Shift+Mousewheel was always reserved for horizontal scrolling, and fine parameter increase/decrease was done by Ctrl+wheel instead of the current Shift+wheel. (Since Ctrl+click also resets the default value). Completely separates the functions of scrolling and editing, guards against accidental tweaks (because Shift+wheeling over a value wouldn’t work), it’s easy to remember since we’re already doing it in the project window and editors. Now, if someone complained that their finger slipped off the wheel, crashed on the left button and reset a value they didn’t want to, well ok, that’s the achilles heel.

Sorry for the long post, I know you are busy.

2 Likes

Hello Matthias, thanks for the information.

I’d like to say, I’m evaluating Cubase at this time coming from Studio One for a few years. Studio One has the same behaviour with the mouse wheel on the mixer and, believe it or not, it’s THE top reason why I’m considering Cubase. You can imagine my disappointment when In this thread I find that Cubase has exactly the same behaviour and the problems associated with it.

This might seem like an exaggeration, but this mouse wheel behaviour causes in me a very starnge feeling of tension every time I scroll around the mixer in Studio One. Moving around in the DAW fast and comfortably is one of my number top priorities and this simple detail totally destroys things for me in Studio One. I can’t tell how many times I noticed something weird just to realize that my faders (or pans or even colors) had been changed accidentally by the mouse wheel. Imagine you are scrolling through your Cubase code in Visual Studio and there’s the possibility that some lines of code have been changed. I find the idea pretty stressful. At the end of the day, it seems that adding a preference that doesn’t diminish the current functionality but that adds comfort to a lot of users is a reasonable trade-off, even considering the disadvantages you mention.

The more I work with DAW’s the more I realize that it’s the small details that make a big difference. On the surface, they’re all pretty good and I’m reasonably satisfied with Studio One, but this small thing (and maybe a few others) make it an unpleasant experience to work with it for hours on end, and though it might seem an exaggeration it’s so important to me as to be considering taking the step and changing my DAW - probably my most useful tool in music.

So, in the end, I respect the points you made, but it seems to me, given the number of requests (to which I’m adding mine), something would be better than nothing at this point. A preference, while not ideal, would be a sensible solution at this point, leaving it unchecked by default so that it wouldn’t confuse current users used to this behaviour. I can assure you that in the Studio One forums similar requests have been made for years by a lot of users, so it seems to be an issue that bothers a significant number of users.

Lastly, I’d like to mention that while evaluating Reaper (which has the same behaviour by default) after 2 minutes I found a preference to disable the mouse wheel changing mixer parameters and just like that life was beautiful (on that regard).

Thanks for the attention, I’m a (very) newbie here, but as I’m really looking forward to switch to Cubase, I really hope you guys have a second thought about this.

2 Likes

That’s why it should be a preference

Imagine you are scrolling through a Word document and sometimes it changes the text.

4 Likes

Good example :grin::+1:

1 Like
2 Likes

I absolutely agree with you. I set up my sessions, Autohotkey macros included, so that I NEVER accidentally move anything (I also disabled Event volume change by mouse wheel i.e.). On the other hand I heavily rely on my mousewheel, when working in Cubase, so much, that I created my own mousewheel macros within AHK.

So I would like to have a solution, where I don’t accidentally change anything in the mixconsole, but also am able to scroll around fast in there.

Its one of the top reasons I don’t use the mixconsole. Scrolling in there is just a nightmare.

Out of all suggestions I heard, Shift+Scroll to move horizontally anywhere in the Mixconsole (suggested by @ggmanestraki ), seems the best solution to me, as it works identically for the project window.

I see no problem using CTRL+Scroll for fine parameter changes in return for future versions. Would be a step in the right direction to make Cubase more consistent and to rework, what should have been reworked long time ago. Hopefully this is something the Dev team considers. @Matthias_Quellmann

1 Like

I found a good solution, I just now simply, on the left side track panel, hid the ‘parameter’ value option.

Just good enough for me :slight_smile: since I have extra monitor for console view anyway :slight_smile:

But yea… this could get extremely painful for larger project engineers… especially these subtle 0.23dB or 0.02dB random moves volume/pan could ruin your mix… :slight_smile:

I seem to be in a minority in this thread, but I have absolutely no problem with the current behavior and I love that I can change every parameter with the mouse wheel. And I know where to put the mouse pointer if I want to scroll through the mixer horizontally, so that is no problem either.
So from my point of view: please don’t change too much! I agree that using shift+scroll for horizontal movement would make it more consistent with the behavior in the arrangement or editor windows, so that is something to consider, but moving fine tune to Ctrl+wheel would be of course a breaking change that would bother a lot of people who have shift+wheel in their muscle memory…

The question is: is it Okay to let us relearn a single key command in order to render Cubase more consistent and to speed up workflow?

I would say: absolutely yes.

I’m very curious about this, but couldn’t figure out what you meant. Can you please explain in more detail, or maybe post a screen shot of where to find this option? Thanks!

So, I was well aware of mouse movement can cause parameter value changes on ‘CONSOLE’ window and here, I am not talking about 'console window ←

I strictly am talking about the main view, so lets say,
I am on track 100: String (reverb send) print wav, then I want to solo monitor my track 1 piano track…
So I move way up by scrolling right?

So on track view LEFT panel, there used to be volume value appearing for tracks and groups for my case, but now I hid it.
It is no longer there and I can always just adjust on ‘console’.

MAIN window, bottom:
‘OPEN TRACK CONTROLS SETTING DIALOGUE’ <— click this,
you can adjust many features including writing letter numbers upto like 14.

So, now everything is the same, just, volume parameter option is now gone for me because,
I scroll up down so quick that I cannot even double check when I am mixing… so hope I made myself clear.

So, console <— mouse scrolling <— has not been fixed yet I believe. and I am only talking about the main window

Ah, thanks, that explains it, and I know what you mean now!

1 Like

Also, one thing I realised was,

My issue was not solely due to Cubase but also Magic Mouse too because, finger touching sense lags and sustains a bit, so that was the reason why Cubase thought it wanted to move…? I am sure with other mouse, it would not be an issue… but um… I enjoy using Magic Mouse so, I shall just find my way around… :slight_smile:

‘BetterTouchTool’ ← also another great tool on mac to customize with your whatever mouse u have :slight_smile:

Maybe in the minority, but not alone! :slightly_smiling_face:
I utterly love how you can change any value in Cubase using your mouse wheel. It’s consistent and brilliant imho.
That said, I don’t scroll around too much in the Mixer window though. Instead, I utilize multiple Mixer Consoles as well as Channel Visibility Configurations to narrow down the channel count.

I don’t think you are in a minority. We ALL (I hope!) love to use the wheel to change values. The problem is when we think we’re scrolling, which is for me an “unattended” process (I’m fully relaxed and not alert at all when scrolling), but instead we’re changing important values. Just by using Shift+wheel for scrolling and leaving fine parameter change alone, we could ease the problem by a factor of 10, since we wouldn’t be making BIG unintended changes, but FINE ones instead. Of course, the problem would remain, but wouldn’t be as bad.

Changing Shift to Ctrl for fine parameter change, I won’t lie, I’m very used to using Shift too. But for project safety, I would be willing to relearn that. Plus, we could then “CONTROL value” literally. :stuck_out_tongue_winking_eye: :joy:

For everyone that likes the current behaviour, once again guys, I’m talking about a preference. If it’s disabled by default the current behaviour should be exactly the same so that it doesn’t throw people off, but for those of us who don’t like it (I REALLY hate it) it’s there for us to change.

1 Like

Today an idea for a workaround came to mind:

Do any of you guys who are on Windows, use Autohotkey?
I use it for everything inside of Cubase, where there is no easy integrated function.

It should easily be possible to make a script like this:

  1. If MixConsole is the active Window and
  2. If CTRL+Mousewheel is used (you can use your preferred key+mousewheel of course, SHIFT or ALT i.e.)
  3. Then move mouse directly to the scrollbar position at the bottom of the window and scroll
  4. After scrolling reposition mouse where it was before

Like this, you could scroll fast and easy everywhere in the mixconsole, without changing any value accidentally and without sacrificing any of your mousewheel functions.

I might make a script myself, just hit me up if you’re interested.

2 Likes

AHK is good, and you can do much with it, but in the end it requires maintenance as everything else (checking if the scripts still work with each version if you use imagesearch or any raw mouse coordinates). I was using it much on my laptop (mostly keyboard shortcuts because I am very trackpad-challenged) but nowadays I’m mostly on my desktop so it doesn’t offer much to justify the effort.

If you manage to build something good, please post it!

Edit: Since the idea excited me, here’s a quick test using Caps Lock.
image

Note: Anyone interested will have to replace 1911 with their own number. Use the window spy included with AHK to check what’s the height at the center of the scrollbar. Try 1070. ish. If you’re on 1920x1080.

Warning: If window focus is in the mixconsole but your cursor wanders over to the project window, the script will still work and teleport your cursor to the bottom when you keep Caps Lock down.

AHK Caps Lock Scroll

Hey, it’s fun! Didn’t think it would be so easy!

2 Likes

Glad to see it worked!

Yeah, you basically have to rework all parts where you have mouse positions in it. You could automate it somehow, where you check first what your DPI is and your resolution and implement that, but since I am always on a 4k screen with 150% DPI, I’m fine with it!

Instead of Mousemove, xpos, 1911 you could have calculated the height and length of the window, its position and then go from there, but still. Well done!