I’m with GhostsonAcid. Ardour used to have scroll bars and they worked fine. This is not scrolling this is jumping and I find it confusing like GhostsonAcid.
Although I see the benefits of the current scrolling implementation, if I had the choice, I’d switch to smooth scrolling too. What bothers me most is when I have a couple of tracks taller than the others. When scrolling past them, the vertical position of the other tracks changes quickly, and it is easy to get lost.
Thanks @GhostsonAcid for bringing this up.
—Exactly!
%
Just look at this example from earlier…
Tracks seemingly just appear and disappear in a, again, unnatural or unexpected (w/respect to our deepest expectations of movement) sort of way:
Thanks for the comments, guys!
I knew I wasn’t alone on this.
…
Sorry, devs, the mob has spoken.
![]()
![]()

Smooth scrolling in Reaper works well, half tracks not an issue there. Having a scrollbar is also helpful, especially when you want to quickly scroll to a specific place.

Why not make it look smooth but always move until the tracks are displayed completly?
To me this would be best of both. ![]()
I fail to see how displaying half tracks could be an issue, if anything it actually tells the container can be scrolled (especially when there’s no vertical scrollbar, another topic that’s been raised several for good reasons I believe).
This kinda makes sense, too. -Like a ‘magnetic’ setting you could turn on (in the preferences) where smooth-scrolling is allowed, but the top lane is aligned to the top if it’s close enough.
…
Because, the fact is half-tracks ARE allowed and present in Ardour, -just not at the top:
…
This is another reason why this blocky-scrolling is kinda silly:
You still have half-tracks visible regardless. ![]()
1000%
Just to add my two cents, I often leave stacks of region visible when I edit but sometime only want the top one of the next track to show underneath the one I edit (for timing reference for instance) and therefor use “half track”. Currently, I resize the height of the track but “smooth scrolling” would make it easier.
Chiming into the chorus of smooth scrolling fans. Not a psychologist, but this jumping detaches the visual focus in a way that makes me avoid scrolling vertically, if somehow possible.
The visual anchor gets lost and my brain is taxed with re-location. This is unnecessary cognitive load, at least for a mouse interface, where movement in space as input, is usually matched by analogous reaction on screen.
It would be different thing if I used key commands. With an up/down 1 track key shortcut or remote control buttons, the current behavior makes 100% sense.
Kdenlive also has really nice smooth scrolling. And you can just hold down the middle mouse button to pan all over which is really nice for one handed operation.

Just to balance things out (and not trying to be contrarian), I see no point in smooth scrolling myself. In my personal opinion, there are so many more important fixes and features I would think should take priority.
But, of course, it is just one person’s opinion…
Exactly.
Currently, the up/down arrow keys (at least on my setup) are for moving the view up and down single tracks/buses. This makes ‘logical’ sense (to me), and I like it!
Again, I’m all for flexibility.
![]()
…
So…
You ~could~ have:
- Option 1: Full blocky/discrete-scrolling (-like it is now).
- Option 2: Full smooth-scrolling (-but still with up/down arrow keys to go up/down lanes or tracks/buses).
- Option 2+: Smooth-scrolling, but with a ‘magnetic’ feel that quickly (not instantly) aligns the topmost lane to the top of the editor when the scrolling comes to a stop (as @erojahn thought of).
Sure, not necessarily a priority, but…
This will remain a fundamental aspect of the program that truly helps define Ardour’s feel, and thus enjoyment level. And if Ardour breaks with a kind of basic, ‘intuitive’ expectation ( … I know Paul doesn’t like that word :P), then I think it makes it less appealing overall.
When using arrows to go up or down a track, if the to-be the top-most or down-most is half-visible, Ardour should then show it entirely.
We could also use the mouse wheel to smooth scroll, and get the actual granular scrolling with something like shift-scroll.
Shift+scroll is a somewhat standard shortcut for horizontal scrolling, it’s extremely useful imo.
I did a quick test on sources and could easily make vertical scrolling ignore track heights, however achieving actual smooth scrolling wouldn’t be as trivial, gtk2 doesn’t provide it out of the box and scrolling at a fixed rate (regardless of gesture speed/inertia) doesn’t feel as natural as one would think. It may still be an interesting option though.
if by this you mean “physically modelled scrolling”, then yes. but i don’t think that’s what most of the pro-smooth scrolling posters here are asking for.
gtk2 is perfectly capable of scrolling at a non-fixed rate in response to scroll events.
But it doesn’t expose the event’s delta_y value, that was only implemented later in gtk3 AFAIK. Needless to say I’m no gtk2 expert :). Also for the record I do like current scrolling implementation, most of the time.
I implemented it in gtk2 more than a decade ago.
The delta, however, doesn’t exist under X Window. I was implementing it for Cocoa on macOS, where scroll events do provide delta information.
Either that, or I am misremembering. There was a reason my code as all #ifdef APPLE …
You don’t need the delta information for smooth scrolling; it just allows the underlying windowing system to send less events. Eg. for X Window, you’ll get 10 events in X msecs based on user scrolling; on Cocoa, you’ll get (maybe 3) in the same time, with delta events for each. It’s really just a compression technique.
What is true is that if your toolkit (e.g. GTK2) doesn’t do deltas for scroll events, then on a system that uses deltas like Cocoa, scrolling behaves poorly. That’s why I implemented it as a patch for GTK2 that we’ve been using since, oh, maybe 2006 or so?
Oh that’s good to know ! Maybe I’ll try to work on a PR this winter if having a preference setting for adjusting vertical scrolling behavior is something you’d consider.
I suspect it’s an afternoon’s work for me. I’m mostly convinced that it ought to be an option, at least.

