One thing I find so frustrating is when I want to move up and down when navigation inserts/sends etc in mix console, if mouse is over eg a send, it affects the send…which is correct, but I dont want to keep moving my mouse to eg scrollbar to simply move the window up
Please allow a qualifier to be held so that scroll will affect window scroll only and ignore widgets
I was wondering what you were talking about.
Replace the term qualifier with modifier, then it makes more sense.
There are some things that are helpful regarding the scroll behavior.
If you move the mouse over an area title or an empty area, the window scrolls with the mouse wheel.
Yeah depends who you are coding for/country. Ill replace with modifier if thats what is usual around this forum but its semantically correct. A target key must be held (qualifier) to execute a modified action…but none the less
My frustration is that there isnt really any empty area and I have to go looking for it and generally move the mouse for no reason, to a scroll border for consistent operation, which is bad ux. Im speaking specifically in the op about the mix console/insert area. If you are over an empty slot it doesnt work either. You have to be on the small join in the grid which is…like I said, far from user friendly
An empty area, is actually the small joins in the grid…so its much easier to use universal left hand action to balance the load on brain and limbs. Load balancing is pretty important UX as well.
Im not sure but scrolling over the title area (assuming we are talking about the same thing) doesnt do anything either.
On C12 here, it only scrolls reliably on the scroll bar.
Cheers
To be honest, if you request a new feature, I think you refer to the latest available version of the software. If not, your request could be outdated already.
It’s the common term in Cubase.
True
But I had such a nightmare from 11>12 Im not doing the upgrade in a hurry…as well there is very little in 13 for m etbh; maybe tap tempo is about it. I dont use any native plugs in Cubase or Ableton after hard lessons learnt over 35 years of use.
I already have miles more than I need to get it done…its just the little things…I have a select client base and rarely use midi anymore…but I still love the mix centred focus.
Perhaps its been addressed but the fact that no one kind of noticed (searching the forum)…would be unlikely but not improbable.
Now if the remote midi was fixed/somewhat finished and had missing features added, I would def go through the pain to have the tactile work as I want it…without anymore coding…that was what lured me to v12 but its pretty well useless excepting the most basic. Generic remote still better
Hehe my last upgrade was from 5-11 just because it worked and prior to that was SX3 so I was actually just making music instead of fiddling and fixing all the time. I still miss the transfer curves from the MBand in SX
Ok, so I did check out v13
V13 UPGRADE DOES NOT SATISFY BEST PRACTICE
There is now a preference to have the old behaviour or the ‘new’ behaviour that seems to remove the ability to scroll when over a parameter.
This is NOT what im talking about
Mouse scrolling over a pararmeter = ideal
Mouse scrolling to move the window = ideal
They are not a persistent choice but a modifier choice based on context
SO
To reiterate; what I am asking for is a ‘modifier’ that is context sensitive but is always an alternate or ‘modifier’ when a qualifying key is held
System consistency is key and its up to the UX engineer to ensure this; satisfy the user feedback with the most fluid amalgamation NOT simply provide exclusive choices.
WHEN
in a project view, ctrl + shift are qualifiers used to modify the mouse navigation for zoom This sets the system precedence based on history/use etc
SO
The mix console is another context as channel widths etc a not temporal but are a persistent state
NOW
the mouse is in the context of the rack window, we need to ordinate the highest use actions
For me, the prime action is
-
Adjust parameters
This should be the unqualified action imho ie as it was -
Scroll navigate
This now needs to be qualified with
ctrl = vertical scroll
shift = horizontal for futher nav actions
The general understanding is that (after 30 years doing UI/UX)
Ctrl = command based variation
Shift = extension of base command
Alt = Inverse action of command
HTH
I find middle-click + drag to be the most intuitive to navigate in a 2D plane.
1 Like
For small pan moves, for sure, I do too…even that would be a step up in function
BUT
I have scroll wheel acceleration on…so I find the scroll action covers a lot of real estate without limb movement. It moves 1 line if slow but exponentially increases speed as you move faster…thanks to AHK for that one.
So good…esp when zooming or moving up and down in project window (also has (alt + scroll as page jump so it can be super fast)
I had a touchscreen ala slate…took me about a day to realise it was actually terrible.
I do a lot of architectural work…where navigation is a lot more tedious I guess.