Positioning Improvement in Key and Tempo Editors

[dmbaer]

This is a refinement on a request I submitted a few months ago – I’ve come up with a much more specific statement of the feature improvement. This one would improve my workflow efficiency more than anything else I can imagine and it’s at the top of my wish-list.

The background is that when in the key or tempo editor, Cubase is sometimes tasked with determining a new range of data to display, such as when zooming in/out with a shortcut key. The resultant position is rarely what best serves the workflow demands.

When I am in the key editor (which I am about half the time I’m in Cubase), I am almost always interested in only manipulating the data to the right of the current song position. I spend a fair amount of time in the tempo editor as well, and there it’s not “almost always” but just “always”.

Yet when I zoom with a shortcut key, the current position always ends up in the dead center and I need to mouse down and scroll right to see more of the data I am interested in manipulating, that data being to the right of the current position. This is extremely frustrating and wastes a lot of time. Zooming is not the only case for which positioning could be improved. When position is reset after an auto-scroll, it is rarely the position that suits the editing situation.

I am suggesting an option that would bias the display placement so that we’d see ~80% of the data to the right of the current position any time Cubase must determine a new range of data to be displayed. In other words, the current position would be placed about 20% from the left margin of the editor view. When the option is enabled, it would govern the editor position any time Cubase needs to make a change in the range of data displayed, not just when zooming.

I’m not sure what to call the option - maybe “Right-hand Edit View Bias”, although there’s probably a better name.

[suntower]

I love the concept. Although the 80% deal violates a pretty basic UI design axiom: “don’t do things that have to be explained.”

Perhaps there’s a way to do what you suggest by ‘zooming’ from the current mouse or cursor position? IOW: the zoom would maintain the position relative to where the current screen position is. I believe Google Maps used to work this way… you’d zoom in and out but yer pointer would stay in, eg. the lower right corner of the map, if that’s where you had the pointer before zooming.

This method is intuitive as well as doing what (I think) you want. I certainly would like this.

[dmbaer]

@suntower

I love the concept. Although the 80% deal violates a pretty basic UI design axiom: “don’t do things that have to be explained.”

Perhaps there’s a way to do what you suggest by ‘zooming’ from the current mouse or cursor position? IOW: the zoom would maintain the position relative to where the current screen position is. I believe Google Maps used to work this way… you’d zoom in and out but yer pointer would stay in, eg. the lower right corner of the map, if that’s where you had the pointer before zooming.

This method is intuitive as well as doing what (I think) you want. I certainly would like this.

Yes, this would serve equally well to promote efficient workflow … and you’re right: it’s a whole lot easier to explain. But it would only cover the case of zoom-in.out, not that of return-to-starting-position after auto-scroll. However, if Cubase would just remember the friggin’ start position and return to that after auto-scroll, then there’d be no problems there either.

So, yes, I like your idea and would enthusiastically accept it as an alternative to my proposal.

[suntower]

@dmbaer

However, if Cubase would just remember the friggin’ start position and return to that after auto-scroll, then there’d be no problems there either.

Since many apps -can- do this already (I’m thinking Adobe CS and various mapping programs) it’s definitely plausible.

Great idea.

—JC

@dmbaer

@suntower

I love the concept. Although the 80% deal violates a pretty basic UI design axiom: “don’t do things that have to be explained.”

Perhaps there’s a way to do what you suggest by ‘zooming’ from the current mouse or cursor position? IOW: the zoom would maintain the position relative to where the current screen position is. I believe Google Maps used to work this way… you’d zoom in and out but yer pointer would stay in, eg. the lower right corner of the map, if that’s where you had the pointer before zooming.

This method is intuitive as well as doing what (I think) you want. I certainly would like this.

Yes, this would serve equally well to promote efficient workflow … and you’re right: it’s a whole lot easier to explain. But it would only cover the case of zoom-in.out, not that of return-to-starting-position after auto-scroll. However, if Cubase would just remember the friggin’ start position and return to that after auto-scroll, then there’d be no problems there either.

So, yes, I like you’re idea and would enthusiastically accept it as an alternative to my proposal.

[dmbaer]

I have made some interesting discoveries that pertain to the issue spotlighted in this thread.

First, I have discovered that cntl+mouse-wheel does zooming and shift+mouse-wheel does horizontal scrolling. If this is in the manual, then it’s well-hidden. The interesting thing about zooming with the mouse-wheel is that the cursor stays pretty much in the same place. Just what I was hoping for with a key-initiated zoom! So, if using the mouse wheel to zoom, you no longer get that annoying centering that you get with key-initiated zooming. Progress!

Mouse-wheel scrolling does about a 10% shift of visible data (gain 10% more on one end while losing 10% on the other) for a wheel movement of one “notch”. The cursor, of course, stays at the same song position when doing this. It turns out that clicking on the arrow buttons on either end of the horizontal scroll bar gets a 20% movement. So, two mouse-wheel notches = one click on the partial-scroll button.

While this discovery constitutes an adequate workaround to the originally described problem, it would still be nice to get the behavior of key-based zooming improved (make it work like mouse-wheel zooming LR-position-wise) and/or to have Cubase provide commands for horizontal scrolling that do either a mouse-wheel one-notch movement or a scrollbar partial-scoll-button action. That way we could fashion macros to do intelligent zooming/positioning. Without equivalent commands to mouse-initiated scrolling, macros are not an option.