PLEASE for sanity sake, fix the horizontal zoom when dragging up/down on ruler

[talustalus]

The problem: zooming horizontally via up/down drag on ruler does offer a very smooth and precise zoom function. BUT, the entire horizontal position SHOULD be fixed at the point at which you click your mouse to drag. It should not skip as it pleases left or right of your mouse location, catching you off guard.

It is no good having the ruler move across either side of where you clicked the mouse at the drag point. It's like having the rug pulled from underneath you. Zoom should occur With Respect To the click point.

This is equivalent to using your fingers to pinch your smartphone for zooming, only instead of zooming directly to the point between your fingers, the screen zooms in or out but you land a little to the left or right of the point at which you pinched in or out.

In Reaper, the only exception is when: the very limited and small range as you begin the drag up or down. Once you zoom in or out past a certain point, the ruler gets a mind of its own and it's 'c ya later' point of reference. "Oh there's the point I was interested in, to the left/right of where it ought to be"


For reference to correct behavior: See how 'Bitwig' treats the ruler drag horizontal zoom function - it works the way it should.

Thanks.

[talustalus]

Bump. Does it bother anyone else?

It is counter-intuitive.

It's a shame because the ruler drag up/down provides the smoothest and most precise horizontal zoom functionality in Reaper. It would be so convenient if it didn't do that self-imposed shift of your reference point (the point at which you drag).

[clepsydrae]

Unless I'm misunderstanding you, the only time I see the behavior you're describing is when it's not possible for reaper to zoom out any farther because "0:00" is now visible on the left side of the screen; if you keep trying to zoom out, the only choices are to stop allowing farther zoom out, or to slide the center to the left to allow more project visible on the right side. Cockos chose to implement the latter, and I think it's the wise choice.

However I would consider one thing: if I zoom out, causing this "slide", if during the same zoom I then say "oops, didn't want to go out this far" and zoom back in, it should maybe remember the old zoom center point, rather than establishing the new location of the mouse on the ruler as the new zoom in point. Not sure about that. Maybe as an option.

[talustalus]

Originally Posted by clepsydrae

Unless I'm misunderstanding you, the only time I see the behavior you're describing is when it's not possible for reaper to zoom out any farther because "0:00" is now visible on the left side of the screen; if you keep trying to zoom out, the only choices are to stop allowing farther zoom out, or to slide the center to the left to allow more project visible on the right side. Cockos chose to implement the latter, and I think it's the wise choice.

However I would consider one thing: if I zoom out, causing this "slide", if during the same zoom I then say "oops, didn't want to go out this far" and zoom back in, it should maybe remember the old zoom center point, rather than establishing the new location of the mouse on the ruler as the new zoom in point. Not sure about that. Maybe as an option.

Thanks. I think there is still 'some' slip or slide away from the zoom reference/center point even when it's not zoomed out all the way.

I completely agree about your idea that it should remember the old zoom point, and this is fundamental to the counter-intuitive behavior I'm describing.

If anyone wants to see the way it should behave, just download Bitwig demo for free and have a go at the ruler zoom, and compare with Reaper.

Reaper's is flawed by comparison and by principle.

[clepsydrae]

Perhaps what you are noticing is that when you are zooming reaper is dynamically updating the zoom center based on the current mouse position, as opposed to remembering the original position (which of course causes the behavior described previously). I can see how this would be frustrating if you're used to the other behavior (zoom center is established only at the beginning of the drag) but I actually find reaper's method to be nice, and intuitive -- as long as you are aware that it's happening, you can fine-tune the zoom as you zoom in. E.g. if you are full-out on a project and start to zoom in deep, you're bound to be off a little bit (since the original zoom will have been too coarse a resolution to accurately pick a point) -- you can slide the mouse left/right as you zoom in and go all the way to a single sample location without having to re-center.

The only time it throws me is when the left-edge of the screen causes an unintended slide... if I'm rapidly zooming out and in, it can catch me off guard.

A solution reaper could implement would be to allow the "negative side" of 0:00 to come on to the screen (i.e. don't do the sliding) and once the zoom drag is released only then slide the project over to its normal location (since the "negative side" doesn't really exist in the project and shouldn't be on screen.)

Another quirk is that since reaper has a "max zoom out" limit, sometimes the whole project is not in view when you zoom out all the way, necessitating some side-scrolling afterwards to get where you want to go.

That's one reason why I don't use ruler zooming: I bind the action to horizontally zoom to the mousewheel; much more convenient than having to mouse up to the ruler all the time.

[talustalus]

I agree with your ideas, it would definitely be an improvement.

The problem also extends to when the zoom is set to 'at mouse center' mode.

The screen slips around when you want to return to a previous zoom level. That's why I keep that setting as 'zoom at cursor', but I'd much rather prefer zoom to be done at mouse (if it didn't shift laterally).

[mccrabney]

thank you for putting this into words, i've struggled with the "pre-0" zoom for a while. would you mind putting up a licecap of how bitwig does it? i don't feel like installing a demo just to see that.

A solution reaper could implement would be to allow the "negative side" of 0:00 to come on to the screen (i.e. don't do the sliding) and once the zoom drag is released only then slide the project over to its normal location (since the "negative side" doesn't really exist in the project and shouldn't be on screen.)

i agree with the bold, but disagree with the unbold. if i'm zooming in on something, i want that to appear dead center in the screen regardless of when the REAPER project starts. i've taken to starting my songs a couple measures into the project, so that i have that negative space to work in. however, i still have a jerky zoom experience doing it this way when i zoom out far enough as REAPER rushes to left-orient itself - it just doesn't happen as much.

i would love to be able to see the "negative side" of 0:00 expand to infinity if a user moves stuff there, just like the "positive side" of 0:00 does it.

[talustalus]

I was only half-right about Bitwig's way of doing it. Still, it is better than Reaper's and I would settle for it as I still believe the thing that Bitwig does better should be treated as a bug' for Reaper.

The stuff about "negative side" coming would be altogether new ground (for both Bitwig and Reaper).

The thing that Bitwig does which Reaper does not is it always maintains the cursor position exactly where you clicked - until you zoom out too far whereby the timeline collapses to the left and the 'negative timeline' discussion comes into play. With Reaper, the cursor location drifts immediately upon zooming in (dragging up) or zooming out (dragging down). Dragging up is more noticeable, as shown (top gif - Bitwig; bottom gif - Reaper):







The above problem (in Reaper) is made worse the further you zoom in/out.

Why is this frustrating? - because after you complete your zooming operation it's likely that you will want to adjust the horizontal scroll position of your point of interest. This is 100% relative to where your mouse cursor is, so it can trip you up when your brain expects the cursor position to be where you've dragged up and down from.

Edit: almost forgot, the other (probably more) frustrating part is, look at how Reaper's cursor moves in relation to your mouse movement, compared to how Bitwig 'locks in' the mouse position ON the timeline as it recognizes the zooming operation is at play. This FURTHER delays any horizontal scrolling adjustments in Reaper (by dragging left/right) because you need to move the mouse back on to the timeline. You also run out of room in Reaper because the mouse movement will stop as soon as you hit the end of the screen.

[talustalus]

- In Bitwig, you can drag down to zoom all the way out on a project, and as long as you still holding the mouse button down, you can then drag up and the project will neatly zoom back in to your initial click point. In Reaper, you lose the reference point completely if you try this.

[clepsydrae]

It would be nice to have that as an option, as well as the "pre-0" behavior already discussed. But reaper's method has it's benefits as well, like accurate zooming without having to adjust horizontal scroll afterwards: since you can dynamically adjust where you are zooming as you zoom in, you can get arbitrary precision on a single zoom, instead of zoom in, adjust scroll, zoom in some more, adjust scroll, etc. You can go from fully out to sample-accurate in a single zoom, as long as you understand how to work with the zoom center.

I find this easier to do with mousewheel zooming though. I can't be bothered to constantly mouse up to the ruler for something I do so often, and the speed curves on the ruler zoom feel a little touchy to me, making what I just described more difficult than with mousewheel zooming.

[ElDoRado1239]

I agree, sometimes it's borderline unusable.

I think it's essential to lock the mouse while performing the drag-zoom or at least offer locked/non-locked version as an option. Not sure how much work expanding the mouse behaviour options is but the mouse lock itself should be rather trivial.

And there is definitely a lot of unwanted movement, not just because of the 0:0:0 point.
If you make small circles you can wiggle your position left and right. Which should, imho, not be possible at all.

As for the zero point - negative timeline pan is a very good solution. Hard locking the zoom once you hit the zero point is another one. What I would probably prefer the most though is that zooming remembers the initial time position of the zoom anchor point, shift around if forced to by zooming too far but when zooming back in, do not move the anchor point but rather zoom in back to the original time position it had when you started zooming. That's what I think of as intuitive and natural.

I'd be glad if this is fixed too, any mouse or key binding is never going to be as fast, comfortable or precise as fully working drag-zooming and drag-panning. Right now, I cannot call it "fully working".

[mccrabney]

bump. zoom center has been making me particularly seasick lately.

watch how the project jumps all over the screen in this demonstration gif, in which i have shrunk REAPER's window to fit better into the gif. when i zoom all the way out, the whole project moves to the left part of the screen, closer to TCP.

when i zoom all the way out, i think the expected behavior would be that the center would stay at the center so that my eyes/head don't have to move to track it so much.



it's also my opinion that zoom center should stay at center of screen, not center of Arrange window. TCP offset (if TCP is in default position) forces us to constantly have our head tilted slightly to the right.

[talustalus]

Originally Posted by mccrabney

bump. zoom center has been making me particularly seasick lately.

watch how the project jumps all over the screen in this demonstration gif, in which i have shrunk REAPER's window to fit better into the gif. when i zoom all the way out, the whole project moves to the left part of the screen, closer to TCP.

when i zoom all the way out, i think the expected behavior would be that the center would stay at the center so that my eyes/head don't have to move to track it so much.



it's also my opinion that zoom center should stay at center of screen, not center of Arrange window. TCP offset (if TCP is in default position) forces us to constantly have our head tilted slightly to the right.

+1000

This behavior is anti vision-ergonomics.

[preferred.nomenclature]

Oh my god it's awful

[EpicSounds]

This post was referenced in the 6.80 changelog. Can we confirm this is fixed?

[mpi]

It is not fixed. IMHO it's gotten worse because it's connected with the way "hand zoom" works.

It's not a hand zoom problem though, it's a mouse handling one. The problem is still there if you don't use hand zoom and use the mouse wheel (though more controllable).

I don't know why this is an issue. Other apps solved this literally decades ago.

If you want to see how it should work look at Cubase or Vegas or any number of audio or video editors.

[EpicSounds]

Originally Posted by mpi

It is not fixed. IMHO it's gotten worse because it's connected with the way "hand zoom" works.

It's not a hand zoom problem though, it's a mouse handling one. The problem is still there if you don't use hand zoom and use the mouse wheel (though more controllable).

I don't know why this is an issue. Other apps solved this literally decades ago.

If you want to see how it should work look at Cubase or Vegas or any number of audio or video editors.

you didn't post in the thread earlier so I don't know your specific wants/needs for this feature, or what you like about the other apps

I don't have access to those other apps to compare myself

[talustalus]

Originally Posted by EpicSounds

This post was referenced in the 6.80 changelog. Can we confirm this is fixed?

I confirm this is fixed, and a MASSIVE improvement on before. I can't relate to the previous negative post by @mpi (negative in the technical sense).

The experience here is all positive with this fix and I see it as addressing the exact concerns I, and I think others, had.

Great job.

Now for MIDI editor hand zooming to work the same!!

[hotlovedrama]

It seems like the hand drag zoom doesn't take in consideration the horizontal zoom preferences. I have mine set to Edit cursor but it seems to zoom at my mouse when I use a drag zoom...
Am I doing something wrong here ?

[talustalus]

Originally Posted by hotlovedrama

It seems like the hand drag zoom doesn't take in consideration the horizontal zoom preferences. I have mine set to Edit cursor but it seems to zoom at my mouse when I use a drag zoom...
Am I doing something wrong here ?

Hand zoom is for zooming with respect to the hand position only

[hotlovedrama]

Originally Posted by talustalus

Hand zoom is for zooming with respect to the hand position only

Well I think it would be useful to set it to what you want.

Nikola from LKC Tools has found a way but no idea how he did it:
https://youtu.be/7nKLnnJ2MYs?t=3007


I was thinking of a custom action with SWS extension but middle drag can't be set in the action menu.
Basically I just want to use that to zoom in quickly to the edit cursor and my mousewheel to zoom at my mouse..