Allow configuring mouse wheel to scroll horizontally


Currently the mouse actions are not configurable.
However, I’d like to scroll horizontally with the mouse wheel and use control+mouse wheel to zoom in and out.

Thanks in advance!

“Shift + Mouse wheel” to scroll horizontally.
“Ctrl + Mouse wheel” to zoom.

Most users find these bindings to be useful, and with a little practice, easy to use. Although it should be “possible” to change these key bindings, doing so could have unwelcome consequences because scroll behaviours are bound to multiple actions. For example, mouse wheel scroll is bound to scrolling the track window up down (when there are multiple tracks), and scrolling numbers up and down (in time controls), and scrolling choices up and down (in multi-choice controls), and probably other things up and down.

First of all, thanks your response.

I am aware of shift-key modifier, but in my use that remains cumbersome. I rarely ever have projects where I need vertical scrolling, because usually I’m working with no more than 5 mono tracks. That makes the default scroll wheel functionality literally useless to me.

The reason I italicized in your quote is a purely technical one. From my own programming experience I understand this will make implementing my request more time consuming, but then again from a user perspective this feels arbitrary. In more general terms, from a user perspective it’s strange (and mildly annoying) that none of the mouse button configurations are rebindable, but horizontal scrolling is the one that most stands out to me.

I fully understand you have to make a trade off in how you invest your resources (including time), but having the option to scroll sideways without shift would be incredibly appreciated by me.

In closing, thank you for your consideration. I’ll rest my case, unless you happen to appreciate the discussion or have any further questions about my perspective.

OK, I just wanted to ensure that you were aware of the modifier key options.
I’ve logged your interest in configurable mouse bindings on the “Feature request” page of the Audacity wiki.

It seems like it would be a fairly simple matter to have Audacity pick up the mouse settings from the audacity.cfg file, as it’s already picking up the keyboard redefinitions from that file.

Re: “For example, mouse wheel scroll is bound to scrolling the track window up down (when there are multiple tracks), and scrolling numbers up and down (in time controls), and scrolling choices up and down (in multi-choice controls), and probably other things up and down.”

It should be a fairly simple matter to decouple these mouse behaviors, by adding these abstractions (as an example):





Audacity is open source software. Is this a feature that you can develop yourself?

I have a client for whom I make this change with every major Audacity release. Ignoring the code which displays it as a non-standard Audacity, there’s only a couple of lines of code to change. My client doesn’t want a preference but that would only add a couple of more lines of code.

+1 for making mousing and gesturing completely user-configurable.

Anything new on this topic?
I would also love to configure horizontal scroll without a modifier key, just by mouse wheel, even sacrificing the vertical scroll.
And I cannot program it myself, unfortunately. Does it really need to be that restrictive?
Thank you very much in advance.

One workaround for this is to use a Mac with a Magic Mouse

There you can get horizontal scrolling with a L/R gesture on the Magic Mouse


Thank you for the workaround proposal, unfortunately I don’t have a Mac.
Apart of that, I am much and frequently switching between Kdenlive (scrolling by wheel) and Audacity (Ctrl-wheel), and it takes an unjustified amount of attention. Still - does it need to be that restrictive? Just why?
Again, I’m absolutely delighted by Audacity and the effort put by the team in its development.

Audacity uses (unmodified) mouse wheel scrolling for vertical scroll (like most other apps), hence the use of a modifier key (“Shift”) for horizontal scrolling, (and “Ctrl + mouse wheel” for zoom).

If you need to scroll a long way, you can drag the scroll bar below the tracks.
If you need to scroll a short way, you can click on the waveform and drag a selection beyond the edge of the tracks window.

Dear Steve, dear Waxcylinder,
Thank you for your proposals, I did read the explanations and workaround proposals in the thread above, and I am aware about what I can do when i need to scroll.
But I also read in this thread, that I am apparently not the only one, who would like to have this flexibility, and one can read the reasoning about it in the thread. It is not about changing a feature, but rather about adding flexibility, because I (along with some others, apparently) am not perfectly happy with the things that I can do now.
It seems, that an implementation might be not as difficult, because apparently Edgar (in this thread above) does it.
I would do it myself if I could, or I will learn it and do, though, being a chemist I’d prefer to do chemistry and let the programmers program rather than other way around - just for sake of productivity…

I think we’d all like to see customisable mouse bindings, but someone needs to write the code to do that, with the current version of Audacity, and submit it as a pull request. That hasn’t happened yet.

I ended up customizing the audacity source code. You can get my changes via:

$ git clone
$ cd audacity
$ git checkout custom-release-3.0.5   # my 'custom' branch.

Interestingly, even though I branched it off release-3.0.5, the Help->About dialog shows it as 3.1.0-alpha…

I have only compiled and tested this on Linux, but most/all of the changes should be platform agnostic. YMMV.

List of changes:

  • Middle mouse button
    Clicking on middle mouse button sets the Zoom level back to ‘Normal’ (a.k.a. Default Zoom)

  • Mouse scroll wheel

Have mouse scroll wheel directly scroll the current track, instead of requiring a shift to also be pressed. Also, whatever the previous mouse scroll wheel behavior was should now be swapped with the Shift-mouse scroll wheel behavior.

  • Page Backward/Forward

Adding Page Backward (same functionality as PageUp key) and Page Forward (same functionality as PageDown key) to the menu system allows us to customize/redefine keys to have PageUp/PageDown functionality. e.g. you could redefine the keystroke combo Shift-Left to do a Page Backward and the keystroke combo Shift-Right to do a Page Forward. Also, it allows ‘Page Backward’ and ‘Page Forward’ to be used in Macros.

  • Default Directories - default to import path

If default directories are NOT specified (i.e. left blank) for “Open”, “Save”, “Import”, “Export”, “Macro Output”, instead of defaulting to last used, default to the initial import path directory. So, if you imported /home/gino/work/chapter-03/foobar.wav , and you then want to export as an mp3, the export file dialog will use /home/gino/work/chapter-03 as the default directory, for the export. etc… Note that if you DO specify a directory for any of the above types (“Open”, “Save”, “Import”, “Export”, “Macro Output”), that directory will TAKE PRECEDENCE over the initial import path, for that type.

  • Import and UndoManager’s save state

Prevent Imports from changing the save state of the UndoManager (save state of the UndoManager determines whether Audacity asks us if we want to save the project, when we close the project window).

  • Export and UndoManager’s save state

After a successful export, tell UndoManager that we have no unsaved changes (save state of the UndoManager determines whether Audacity asks us if we want to save the project, when we close the project window).

  • Decorating project’s title

Update title of project,using ‘**’ to denote it has unsaved changes. This is similar to how Emacs shows that an edited file has unsaved changes. Note that an unsaved change may occur even if you run a macro that does not actually change the audio file.


I believe the loadable shared library modules, such as are installed into the ‘modules’ subdirectory of: installPrefix +“/lib/audacity”, by ‘make install’, so it makes sense to add this path here, so that Audacity can find the loadable shared library modules, at runtime.

Normally it should be sufficient to use the -DCMAKE_BUILD_TYPE=Release option to specify a release build, but due to a minor error in 3.0.5 you need to also use -DAUDACITY_BUILD_LEVEL=2.
This has been fixed for the next release.

If you think that these changes would be an improvement to Audacity (release version), you could make a pull request to the main Audacity repository.

These are important changes - thank you for taking this initiative :exclamation:

Please separate them out and submit pull requests as Steve suggests. Thank you. :smiley:

This gesture is already used in Audacity to scroll up and down on the window when you have more tracks than can fit in the window - replicates use of the vertical scroll bar.

So if you now use this gesture for scrolling the current track - then perhaps you need to add Shify+moues-wheel-scroll to scroll up and down in the window.


I know why you want this - to avoid the naggogram.

BUT consider that just making an Export does not of itself necessarily remove the need to save the project:

a) the user may have only exported a selection from the project

b) Exports ignore muted tracks on export - but they can form a valuable part of the project (which could then be irretrievably lost)

c) the Export may have been to a compressed format like MP3 or AAC/M4A - and thus re-importing those for further editing would involve quality loss.


That’s fine if you say just import one audio file, work on it and then want to export or save it to the location it came from.

BUT what happens if you make several imports of audio files all from different locations:

a) does the first one dominate, or the last,

b) should this be a user-settable preference?