View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006722 | ardour | bugs | public | 2016-01-03 02:52 | 2016-02-17 00:16 |
| Reporter | don3 | Assigned To | timbyr | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | Linux | OS | Fedora | OS Version | 21 + CCRMA |
| Product Version | 4.4 | ||||
| Summary | 0006722: ctrl+mousewheel zooming in track area ignores zoom focus setting | ||||
| Description | Tested on 4.4.0, 4.4.463. While writing bug 0006721, I discovered that zooming in the track area always seems to use "Mouse" zoom focus, ignoring the setting in the Zoom Focus field. I hadn't noticed it before because Mouse is almost always what I want. :-) However, zooming in the ruler area appears to use the Zoom Focus setting. | ||||
| Steps To Reproduce | 1: Set Zoom Focus to something other than Mouse - eg, Playhead. 2: Arrange edit screen such that the playhead and mouse cursor are in distinctly different places. (One toward the left of the screen, the other toward the right, say.) 3: Zoom using ctrl+mousewheel. Expected: Zooming in and out should be centered on playhead's position in this case. Actual: Zooming is centered on the mouse cursor position. 4: Move mouse straight up to the ruler area. 5: Scroll using ctrl+mousewheel (or, uhh, just mousewheel ;). Zoom is centered on playhead, as expected. Window also jumps to playhead location, which is (I guess) expected as well. (It just adds to the surprise when one is expecting mouse focus. :) | ||||
| Tags | No tags attached. | ||||
|
|
I can confirm what you have observed. In version 3.5 the mouse is used as the focus in the track area and the ruler area so there has been a change in behaviour since then. I think the bug is the inconsistency and I would agree that scrolling on the track area should follow the zoom focus setting. It could be argued that using the mouse scroll wheel should always use the mouse cursor position but it seems to go against the point of having a focus mode. It look like the change was intentional(commit f23490bd3), so you would need to get some feedback as to the reason for the change. It is fairly trivial to revert the change and maintain consistent zoom focus behaviour. |
|
|
track-canvas-zoom-follows-zoom-focus.patch (1,891 bytes)
diff --git a/gtk2_ardour/editor_canvas_events.cc b/gtk2_ardour/editor_canvas_events.cc
index 77cfde0..eb394d2 100644
--- a/gtk2_ardour/editor_canvas_events.cc
+++ b/gtk2_ardour/editor_canvas_events.cc
@@ -77,11 +77,15 @@ Editor::track_canvas_scroll (GdkEventScroll* ev)
switch (direction) {
case GDK_SCROLL_UP:
if (Keyboard::modifier_state_equals (ev->state, Keyboard::ScrollZoomHorizontalModifier)) {
- //for mouse-wheel zoom, force zoom-focus to mouse
- Editing::ZoomFocus temp_focus = zoom_focus;
- zoom_focus = Editing::ZoomFocusMouse;
- temporal_zoom_step (false);
- zoom_focus = temp_focus;
+ if (Profile->get_mixbus()) {
+ // for mouse-wheel zoom, force zoom-focus to mouse
+ Editing::ZoomFocus temp_focus = zoom_focus;
+ zoom_focus = Editing::ZoomFocusMouse;
+ temporal_zoom_step(false);
+ zoom_focus = temp_focus;
+ } else {
+ temporal_zoom_step (false);
+ }
return true;
} else if (Keyboard::modifier_state_equals (ev->state, Keyboard::ScrollHorizontalModifier)) {
direction = GDK_SCROLL_LEFT;
@@ -106,11 +110,15 @@ Editor::track_canvas_scroll (GdkEventScroll* ev)
case GDK_SCROLL_DOWN:
if (Keyboard::modifier_state_equals (ev->state, Keyboard::ScrollZoomHorizontalModifier)) {
- //for mouse-wheel zoom, force zoom-focus to mouse
- Editing::ZoomFocus temp_focus = zoom_focus;
- zoom_focus = Editing::ZoomFocusMouse;
- temporal_zoom_step (true);
- zoom_focus = temp_focus;
+ if (Profile->get_mixbus()) {
+ // for mouse-wheel zoom, force zoom-focus to mouse
+ Editing::ZoomFocus temp_focus = zoom_focus;
+ zoom_focus = Editing::ZoomFocusMouse;
+ temporal_zoom_step(true);
+ zoom_focus = temp_focus;
+ } else {
+ temporal_zoom_step(true);
+ }
return true;
} else if (Keyboard::modifier_state_equals (ev->state, Keyboard::ScrollHorizontalModifier)) {
direction = GDK_SCROLL_RIGHT;
|
|
|
I've uploaded a patch that changes it so that mouse scrolling in the track canvas area uses the zoom focus setting. As this was changed for Mixbus the patch uses a similar conditional as in the ruler area so the behaviour stays the same for Mixbus. In saying that I think it better to have fewer differences between Mixbus and Ardour and some people may prefer the current behaviour, one way to address this would be to make the behaviour dependent on a config option/preference such as "Always use mouse cursor position as zoom focus when zooming using mouse scroll wheel" or similar. |
|
|
timbyr: I agree with what you've said here. Indeed it was the inconsistency between track and ruler areas that got me started. :-) (Same for 0006721 in fact). I'm still a bit surprised that people would _want_ to deal with inconsistencies like that, even if there's a small benefit, but then I don't know their work flows. (I think) I'd also not be opposed to the idea that the mouse scroll wheel should imply mouse zoom focus (in both areas), since this is what I do the vast majority of the time. I suppose it may not be the same for others. And as you say, in that case I would probably never use zoom focus mode. I also agree with the concept of keeping as much as possible common between Mixbus and Ardour, and if there's no consensus on a single common behavior, I like your config option idea. |
|
|
I've added a configuration option in Ardour master branch as of revision ab292183dd so that scrolling with the mouse wheel always follows mouse cursor position if enabled. Ardour now has the same behaviour as Mixbus by default. Please test and let me know if you think this is sufficient so we can close this issue. Thanks. |
|
|
I liked the fact that I could zoom to two different zoom focus points depending on where I zoomed: Using Ctrl+scroll in the track area would zoom to the mouse, just scrolling in the ruler would zoom to my selected focus point (usually playhead). (In that case I would argue that Ctrl+scroll (vs. simple scroll) in the ruler should also use the mouse (like in the track area).) The way it's now in current git (4.6-98-g01fd887) this versatility has gone, no matter how I set the option. So IMO it would be nice if the option (in that case would have to be renamed) would only apply to Ctrl+scroll behaviour. |
|
|
Tested briefly on nightly 4.6.96. Although I still haven't warmed to the idea of the scroll wheel without a modifier in the ruler area doing anything other than what it does in the track area (ie, vertical scrolling), I'd say this is at least an improvement. If the un-modified scroll wheel action is going to be inconsistent between ruler and track areas, I have no problem with the_CLA's suggestion -- ie, make the new option apply only to "explicit" scroll-wheel zooms (ctrl+scrollwheel), if I can use that term. If I'm _intending_ to zoom in the ruler area, that's what I'd be doing. If it were me, I would also add an option to enable/disable the inconsistency -- ie, unmodified scroll wheel in ruler area does "implicit" zoom, instead of vertical scroll (of the tracks). (Eh, I don't necessarily intend that as the title of such an option, but hopefully you get the idea. :) Since it seems that most people prefer this behavior, it should be enabled by default. -- Following up on an earlier observation, I've noticed that setting Zoom Focus to Playhead, and zooming in or out using the '+' or '-' buttons (or keys bound to them) causes the playhead to move to the center of the screen. This is inconsistent with other Zoom Focus behaviors, such as Mouse, or Edit point with the Edit Point set to Mouse, Marker, or (even) Playhead: none of the others settings cause any movement in the focus point (until one zooms out quite far -- another annoyance (for me), but probably beyond the original scope of this bug). -- Also, while testing I noticed that the size of the horizontal scroll increment is different when doing shift+scrollwheel in the ruler area vs the track area -- it's much bigger in the ruler area. I prefer the smaller size in the track area. I can open a new bug report for this... |
|
|
This issue was about the inconsistency of ignoring the zoom focus setting in the ruler area. I think mouse zoom focus should be used by default because it maintains consistency with Mixbus but perhaps more importantly because using the mouse pointer position as the focus when zooming(using the mouse) is the default for at least two other major DAW's that I'm familiar with(Ableton Live and Cubase). The zoom focus options really only seems relevant when you are using a controller that doesn't have a positional indicator for the zoom focus such as a keyboard or control surface but as some people may still want to use the non-mouse focus options with the mouse scroll wheel I added the option. I don't see much merit in adding a way to disable the mouse focus temporarily using a keyboard modifier with scroll wheel, when you can just use the '+' or '-' keys to achieve the same thing. Less hand movement perhaps. Using ctrl+scroll in track area and ctrl+scroll in ruler area for mouse zoom focus implies unmodified scrolling in the ruler area uses the zoom focus option which I don't think should be the default for the reasons already stated. What I think would be worth trying would be to replace zooming in the ruler area using the scroll wheel with the zoom drag behaviour found in Ableton and Cubase(and probably other DAW's) where clicking the left mouse button and dragging the mouse vertically increases or decreases the zoom. I don't think using the scroll wheel in the ruler area should scroll the track area vertically, it is a separate area with different intended usage and interaction, it is not part of the track canvas(even though it looks like it is) and doesn't scroll vertically. It seems acceptable in the summary area as that is basically a controller for the main track canvas with visual feedback. I agree that the horizontal scroll increment should be the same in the ruler and track canvas areas. I will fix that shortly. |
|
|
timbyr: I'm not sure I follow everything you've said there, so I'll have another go when I've had a little more sleep. :-) Perhaps I can clarify one thing though... "I don't think using the scroll wheel in the ruler area should scroll the track area vertically ..." FWIW, I was comparing unmodifed scrollwheel action in the ruler area with shift+scrollwheel action in the track header area (if that's the right term - the tracks' left-most area), as I see a kind of symmetry between them. The track headers don't move horizontally, yet shift+scrollwheel in that area scrolls the track contents horizontally - quite reasonable I think. Transposing H and V, it seems logical (to me) for unmodified scrollwheel in the ruler area to scroll the tracks vertically, even though the rulers don't move vertically. In any case, I agree these are smaller details, compared to the main point of the bug report. I think I can live with the behavior you have now, possibly modified by what the_CLA suggested. Just thought it might be good to think about a bigger picture here, if there is one. Thanks for looking into the horizontal scroll increment. Have you seen my other "OT" behavior -- ie, zooming with '+'/'-' buttons/keys with Zoom Focus set to Playhead causes the playhead to be re-positioned at the center of the screen, unlike all the other modes? |
|
|
I've made the horizontal scroll increment consistent in Ardour master as of revision 452e39f8 I forgot about shift+scrollwheel in the track header area as I don't think I've ever used that feature. I agree then that your suggestion makes sense in that context but as using the scroll wheel in the ruler area has been in place for quite some time I will not be changing it unless there is a lot more consensus. I have not noticed any issue with Zoom Focus set to playhead. It seems fine to me after a short amount of testing. |
|
|
Thanks for your work on this, timbyr. I'll wait for 452e39f8 to be included in the next nightly before I test again - looks as though the last one missed by 1 commit. Understand about (unmodified) scroll wheel in the ruler area. I certainly wouldn't propose changing that unconditionally, since the current functionality is expected (and appreciated) by some, perhaps most (everyone but me?)... At most I was proposing an option which would default to the current behavior. Anyway I think this would be more appropriate for bug 0006721. I submitted a new bug for the Zoom Focus thing: 0006750. There are some steps to reproduce it there. |
|
|
I feel that this issue has now been addressed and if there is no more negative feedback after a couple of days I will mark this issue as resolved. |
|
|
Sorry for the delay coming back on this. Just tested nightly 4.6.350 - quite a bit later than the commit with your last change for the consistent horizontal scroll increment (.109) and it looks fine for me -- thanks timbyr! Were you intending to address the_CLA's concerns as well? |
|
|
I think I justified my reasons for the current behaviour in http://tracker.ardour.org/view.php?id=6722#c17827 Basically I think simplicity and consistency with Mixbus is more important than versatility(that has not been lost as the '+' and '-' buttons on the keyboard will zoom using the zoom focus setting). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-01-03 02:52 | don3 | New Issue | |
| 2016-01-05 05:09 | timbyr | Note Added: 0017766 | |
| 2016-01-06 03:52 | timbyr | File Added: track-canvas-zoom-follows-zoom-focus.patch | |
| 2016-01-06 04:05 | timbyr | Note Added: 0017769 | |
| 2016-01-06 19:45 | don3 | Note Added: 0017771 | |
| 2016-01-21 02:48 | timbyr | Note Added: 0017813 | |
| 2016-01-21 02:48 | timbyr | Assigned To | => timbyr |
| 2016-01-21 02:48 | timbyr | Status | new => feedback |
| 2016-01-22 17:15 | the_CLA | Note Added: 0017820 | |
| 2016-01-22 21:04 | don3 | Note Added: 0017822 | |
| 2016-01-22 21:04 | don3 | Status | feedback => assigned |
| 2016-01-24 12:47 | timbyr | Note Added: 0017827 | |
| 2016-01-25 00:59 | don3 | Note Added: 0017831 | |
| 2016-01-25 10:25 | timbyr | Note Added: 0017833 | |
| 2016-01-25 16:46 | don3 | Note Added: 0017834 | |
| 2016-02-16 02:30 | timbyr | Note Added: 0017947 | |
| 2016-02-16 02:30 | timbyr | Status | assigned => feedback |
| 2016-02-16 23:01 | don3 | Note Added: 0017957 | |
| 2016-02-16 23:01 | don3 | Status | feedback => assigned |
| 2016-02-17 00:16 | timbyr | Note Added: 0017958 |
