Why Are New Tracks Always Added to the End? You Should be Able to Add Them After the Selected Track

The subject line pretty much says it all: I just don’t understand why Audacity forces all new tracks to the end of the project. This is super annoying because (just by its nature) it’s rather difficult to drag a track up to a precise place in a project. You almost always wind up scrolling past where you wanted it, and because of the new track behavior you wind up having to go through this frustrating scroll process every single time you add a new track.

It would super nice if there was a setting (or maybe just the default behavior) to add new tracks IMMEDIATELY AFTER the currently selected track instead.

Thanks, and thanks for all your hard work on Audacity!

Oh. It took me second to get there. Audacity adds a performance to the end of the show, not the current track.

You could use the other Recording option, Shift+R which starts a whole new track on its own line. That may be easier to move around. Plus, you can use the Time Shift Tool (two sideways arrows) to slide the new clean track sideways until it lines up to where you want it. Audacity will try to play (and export) everything including the new track unless you stop it.

That may be easier than what you’re doing.


This may be hard to follow. These three will play and export as one continuous sound. And they’re slightly sticky, so you don’t have to guess where the line-up point is.

Screen Shot 2019-05-20 at 20.25.58.png

Thanks for the reply! However, I think I failed at explaining the problem.

I have a project with 20+ tracks. I want to add a new “track #4”. The problem is, it’s needlessly difficult to do so.

Whether I use R, Shift + R, hit record, or go to Tracks => Add New => Mono Track … no matter what I do, the new track appears at the very bottom of the project. There is no way I can possibly create the new track in position #4.

This doesn’t have to be (and in fact I have vague memories of it working differently months ago). Audacity could simply add the track after my currently selected track … in other words, if I have track 3 selected and I use one of those methods, the new track appears at position #4.

Honestly, I don’t see why changing it to work that way wouldn’t just be better for everyone. If someone wants their tracks at the end all they have to do is select the last track before they start recording. But if they don’t, this would give them the option to start it anywhere in the project desired.

And if that is some strange/bad behavior for most users, at least offering a setting to change the default behavior would satisfy users like myself.

P.S. And again, all this is compounded by how difficult Audacity makes it to drag tracks up. The acceleration is incredibly hard to control, so one second you’re dragging up one track at a time and the next you’re dragging past 5-10 tracks a second … which makes it take awhile to get the track to the position you actually want it in. Even if dragging wasn’t so hard it would still be annoying to have to drag tracks up from the bottom … but the difficult to control drag speed just makes the whole experience even more painful.

P.P.S. Also, I rely on Tracks => Align Tracks => Align End to End to get my tracks together properly after I trim them and such. It is because of this (well, and for my own sanity) that I need the tracks in the proper order. If I didn’t use that feature, I guess I could add “track #4” in position #25 and everything would still work … up until I try to align tracks, at which point it would become both track AND position #25.

Honestly, I don’t see why changing it to work that way wouldn’t just be better for everyone.

No question, but somebody has to program that and that’s the exact point where it gets magic.

Right now, the decision is “put it at bottom of the show at time zero or put it after the last track.”


To create a new track 4, you would have to move everything below that down one. That seems like a piffle, but it’s not. What happens to linked tracks, labels and sync? They all have to move and you know somebody is going to try to slide a new track in the middle between two linked tracks.

So you have to account for error conditions, too.

Nobody said it wasn’t a good idea, though, and we can see what other elves think.


I think it’s a good idea. I made the same request myself many years ago. It’s a very small team of developers.

So, I totally get that other users have concerns (eg. linked tracks) that I don’t, which is why I could completely understand making this a setting rather than the default behavior.

But what I don’t understand is how this could be technically difficult to implement. Currently I can add the track to the end and drag it up manually. Doing this results in exactly what I want: a new track at (say) position #4. No new special logic or behavior for linked tracks or anything else is required. The hard part has nothing to do with the “magic” behind the scenes, and everything to do with the human difficulty of dragging the track up.

In other words, I’m not asking for any new logic whatsoever regarding linked tracks, labels, etc. All I want is some way for the tool to do whatever it does when I drag the track from the bottom to position #4 … but do it for me when I select track #3 and create a new track :smiley:

There’s a note here.

Audacity is widely used by people who want to create simple shows or do uncomplicated work even though they may own larger program licenses. It’s far easier to do simple jobs in Audacity than to fire up a full-tilt-boogie Pro-Tools session.

Sooner or later the two jobs complexities cross and it may be better to use a larger program.


I don’t understand: are you saying Audacity is not the tool for a Linux user who wants to assemble 20-30 audio tracks for a 15 minute presentation? If so can you recommend another that would be better suited?

As a workaround, you could create a Nyquist Macro (https://manual.audacityteam.org/man/nyquist_macros.html) to move the bottom track up to below the selected track. I’ve not tried this, but I think it should work.

This is where the forum format comes in handy. Users helping each other.


Unfortunately I’m not fluent in parentheses-based programming languages (ie. Lisp or whatever Nyquist is based on), so I’m not able to write such code.

Look, ultimately the devs behind Audacity either want to improve it or they don’t. If they do, they have the capacity to deal with the top ?% of feature requests, and either my request makes the grade or it doesn’t. If the developers aren’t interested in making this aspect of the program better for users like me (say, because there aren’t enough users like me) that’s completely reasonable, and we can just close this ticket/forum thread.

I just wanted to point out that it could be better in case the devs did care to improve it (and again, as far as I can tell, this can be improved without any “new magic” required; all that’s needed is leveraging the existing functionality).

But regardless of the outcome of this feature request, I’m still extremely curious: am I using the wrong tool? Should I be using something other than Audacity for my use case (again, Linux user, 20-30 tracks per presentation with each presentation being about 15 minutes total)?

How about Python?

Pretty obviously they do want to improve Audacity, since they volunteer countless hours of their “spare time” doing so.

I’ve logged your feature request on the Audacity wiki (along with my “vote”).

parentheses-based programming languages

That’s good. Can I use that?

devs behind Audacity either want to improve it or they don’t

As you said at the beginning of this thread, you’re using Audacity now and it’s just inconvenient. The developers have a hierarchy of advances and changes starting with the show-stoppers that cause major problems and lost work.

That and there’s the organization size. This is Audacity’s World Headquarters in Land’s End, Cornwall.

You can drop by and say hello. Park in the visitor’s center. Call ahead and pick a nicer day. We’ll make some tea.


By all means :smiley:

Again, if this issue isn’t significant enough to enough users to be worth fixing I completely understand. I wasn’t asking for my pet issue to be bumped to the head of the line or for any special treatment; all I wanted was:

Thank you very much Steve! And also:

I am fluent in Python; I just didn’t realize that Nyquist macros could be written in Python!

Not exactly “macros”.

Let me tell you the catch first before you get too excited. As yet, no mainstream Linux distributions ship Audacity with this feature enabled. It is being shipped for the first time with Audacity 2.3.2 for Windows and Mac. For Linux, we only provide source code and it’s up to the package maintainers for each distro to provide binaries, OR, Linux users may build Audacity from the source code (which is not massively difficult).

The feature I’m referring to is called “mod-script-pipe”. It’s an optional module for Audacity that allows any scripting language that supports “named pipes” (this includes Python) to communicate with Audacity.

As you’re fluent in Python, this example Python module will probably give you a good idea about it, in addition to the “Scripting” section of the manual (link below):


Thanks for the info. That does sound very promising … but building from source and writing my own plug-in currently seems like several orders of magnitude more work than just dragging every stupid track up as I add them :smiley:

Maybe when this makes it into the repo version of Audacity though I’ll take a crack at it.

I’m sorry but I can’t reproduce your problem.

I tried 2 use cases

a) one with 4 mono tracks of varying lengths - with Audacity set to mono and selecting each track in turn Audacity recorded at the end of each track

b) the other with 4 stereo tracks of varying lengths - with Audacity set to stereo and selecting each track in turn Audacity recorded at the end of each track

It gets a bit more complicated when say you have a few monoi tracks and the try to record in stereo - Audacity captures the two channels and tries to second-guess which two mono tracks to use {one per channel) - recording starts at the end of the longer mono track and the shorter mono track is silence-filled to the length of the longer track.


machineghost is talking about the “vertical” position of new tracks.

Example: If you have a project with 20 tracks, and you import an audio file, the file is always imported as the bottom (final) track in the project. In large projects it is good to organise tracks in a logical order, which frequently means dragging tracks a long way up (or using the track context menu), which soon becomes quite tiresome.

It would be much more convenient, and conducive to a smooth workflow, if you could import files at a specified (vertical) position, such as directly below the track that currently has focus.

I totally understand :smiley:
Nevertheless, if you enjoy Python, then you’ll probably love mod-script-pipe when it reaches the repos. The power of Python takes Audacity’s macros to a whole new level.

Yes, Nyquist is a form of LISP (an extension of XLISP). It was developed by Professor Roger Dannenberg, who is also one of the co-founders of Audacity.
“Nyquist Macros” are quite a new feature in Audacity. As yet, there’s not much in the way of examples / tutorials, but I thought this idea of moving the bottom track up to just below the current track was an interesting challenge, so I’ve written a plug-in.

This plug-in requires Audacity 2.3.2 or later.
I’ve only tested this plug-in on Linux but it “should” work on Windows and Mac as well as Linux (provided that Audacity is new enough).

When installed, the plug-in appears in the “Tools” menu.
trackmove.ny (1.12 KB)