Can I open more than 1 audacity 2.1.2 at a time.when recording an album I would like to open up an another audacity and work on an other album.I could do it with the older version audacity.
Yes, you can do: “File menu > New”, or “File > Open” or “File > Recent Files”.
However: DO BE CAREFUL. If you “Play” or “Stop” in the second project, it will abort the recording in the first project without notice. Personally I would NOT recommend working on another project while recording - it’s just too easy to make a mistake and screw up the recording.
We do now “unofficially” support running two instances of Audacity (as opposed to having two Audacity project windows open in one instance), but it does not work on Windows due to a bug.
You can simulate it by running Audacity in separate user accounts, but that may well fail on Windows 8 or Windows 10 because those versions of Windows tend to suspend the audio device in the account that isn’t active.
Or (at your own risk) you can try running Audacity 1.0.0 as the recording device and edit in current Audacity.
You need a fast computer to run two instances of Audacity, but it “probably” isn’t a problem for modern desktops or laptops.
Could you explain that Gale.
That does not appear to be the case on Linux.
and it does not work on Windows.
So it sounds like it is currently an “unofficial feature” on Mac OS X only ?
How do I launch separate instances of Audacity on Mac OS X? isn’t there a “lock file” to prevent that from happening?
Could you tell me who the developer of this feature is so that I can ask them for information about how it should work.
It does work on Linux as well as Mac.
Assuming the same user wants to run two instances of Audacity, the requirements for it to work are:
- At least one instance of Audacity must have a “Portable Settings” folder alongside the executable
- The TempDir pointed to in audacity.cfg must be different in each case.
So if you only have one Audacity executable on the machine, you would launch it, create a “Portable Settings” folder alongside the executable, in the “Portable Settings” folder you would create an audacity.cfg file pointing to a different TempDir than the one in Audacity’s folder for application data, then execute Audacity again.
On Ubuntu 14.04 I have been running two instances of the same copy of 2.1.2 alongside each other, and 2.1.2 alongside 2.1.3-alpha.
If you do try to run two different versions of Audacity pointing to the same temp folder in audacity.cfg, there is no warning on Ubuntu 14.04, nothing happens and there is no terminal output. But there is no “already running” warning even trying to run the same version twice with the same temp folder. I think the “already running” warning appears on Mac, I will have to check.
What you describe is surely just a “side effect” of running Audacity as a portable app rather than an intended “feature” of Audacity. If it really is an intended feature, then I don’t understand why we have code comments such as:
// There is another copy of Audacity running. Force quit.
//<<<< Try to avoid dialogs before this point. // The reason is that InitTempDir starts the single instance checker. // If we're waiitng in a dialog before then we can very easily // start multiple instances, defeating the single instance checker
which strongly implies to me that we don’t want the single instance checker to be defeated. Your ‘steps to make it work on Linux and Mac’ allow multiple instances because they provide a way to defeat the single instance checker.
We also have the message string:
_("Running two copies of Audacity simultaneously may cause\ndata loss or cause your system to crash.\n\n")
Answering some of my own questions:
Back in January 2015 revision 13868, multiple instances of Audacity was specifically prohibited on all platforms. The main issue that the developer (LL) was concerned about was that Audacity would sometimes hang when two Audacity process were started at the same.
Later that same month, he found the reason for the hang and fixed it. At that time he was not aware of any compelling reason to prohibit running multiple instances, so he reverted r 13868 and requested thorough testing of running multiple instances:
So, what needs testing is starting multiple copies of Audacity, either
sequentially or simultaneously. In as many variations as you can think of
and you lot seem to be able to dream them up. >
So really it was left as an open question “why not?” rather than a positive decision “we need this feature”.
I’m personally not yet convinced that allowing multiple instances is a good idea - some reasons why:
- With multiple instances, changes to Preferences apply only to the preferences for the “Audacity profile” that the instance was launched from (the “Audacity profile” being the complete set of “preferences”, pluginregistry, pluginsettings, chains, temp folder, EQCuves, …).
For example, if you have profiles a, b, c and d, and you launch 4 instances of Audacity, one from each “Audacity profile”, and for each instance you “Close” the current project, then you have 4 new projects with 4 different sets of preferences, different plug-in settings, different EQCurve settings etc, and no clear way to tell which project is a member of which profile. Changing preferences, EQ curves, Chains, plug-in settings, installed plug-ins (etc) in one project will change one of the profiles, but there is no friendly way for the user to know which profile has changed.
- Users expect that effect will open with the last used settings. That will only happen if the last time an effect was use, Audacity had been launched using the same profile.
- Crash recovery becomes more complex as multiple instances requires multiple temp directories. Auto-recovery (which generally works very well) will appear to fail completely if the user launches Audacity from the wrong profile.
- On OS X, closing all windows is intended to close all windows but leave one empty instance of Audacity running. This fails if there were multiple instances of Audacity running.
- On Linux, the standard location for an application lock file is as a hidden file in the user’s home directory. To support multiple instances of Audacity we must write the lock file to a non-standard location.
- When exporting files, it is possible that two or more instances of Audacity could attempt to export files with the same name to the same location. This would cause all exports except for the one that completes last to be overwritten without warning. I don’t see a good way round this as the file name must be set before the file writing begins, but the exported files do not exist until the export is complete. We would normally class such data loss as P2 or higher, but if we have multiple instances there may be no way round it.
- When recording “stereo mix”, there is a high risk of damaging a project by playing or previewing in another project. In my opinion the risk is unacceptably high, but (assuming that the system allows the behaviour), I see no way that Audacity can prevent this from happening if there are multiple instances (it “can” be prevented if there are multiple project in the same Audacity instance).
I expect there are many other reasons “why not” to allow multiple instances. How much evidence do we need in order to decide that it’s not a good idea?
In practice, “defeating” the single instance checker is probably a more stable way of recording in one project while working on another than doing it in two project windows in the same instance.
And yes, Leland has been becoming more relaxed to allowing this.
As I understand it, one objection to the “unofficial” method you requested clarification on is that two instances of Audacity could use the same configuration file. This is discussed at http://bugzilla.audacityteam.org/show_bug.cgi?id=840#c0. Leland has a patch there that would store the lock file in the configuration directory rather than the temporary directory, therefore removing that objection.
The objection to two instances of Audacity on basis of resource usage is probably old hat now. Even my 1 GHz netbook managed to record into 2.1.2 and 2.1.3-alpha at the same time without any dropouts, though I would not recommend that on such a machine.
Perhaps you should post your objections on the grounds the user does not know which profile they are using (and other objections) in Bug 840. Personally I would not recommend running multiple instances of the same executable, but I don’t find it confusing if there are two Audacity executables in different locations.
So on that basis we are already using a lock file in a non-standard location, and Leland’s patch in Bug 840 would also be non-compliant.
That seems like a user error to me, to think that they can record a song from YouTube with stereo mix in one Audacity instance then play a song in another Audacity instance without affecting the YouTube recording. Per se, that doesn’t seem a good reason to me to say you can’t run two Audacity instances. Either the user should be using another recording app that can record only from the application producing the sound (like SoundLeech or VB Virtual Audio Cable), or Audacity would need that recording ability.
But safer than either would be to disallow actions in one project affecting another project.
Looking at how other applications behave, as an example, a word processor: I can open two documents (two “word processor projects”). I can switch from one to the other and edit each project in turn. I can even copy from one “project” (document window) and paste in the other. Thus I can safely work in multiple document windows, secure in the knowledge that changes that I make in “project A” will only affect “project A”. When I switch to “project B” I’m not going to find that it is trashed because of something I did in “project A”.
Given that we still see reports of skips and drop-outs in recordings, I’m less confident.
Given that currently we only use one processor core at a time, it is unlikely that there will be recording performance problems due to the CPU, though that is probably not true for single processor machines and will probably cease to be true when we start using multiple CPU cores.
I agree that it is probably reasonably safe at the moment on a modern machine to do a bit of gentle editing while recording an LP, but do we / can we know the performance limits?
Thanks, I’ll have a read through that entire thread.
Yes we are currently non-compliant (on Linux at least), whereas revision 13868 was compliant.
Sure it is. Stepping into a bear trap is invariable user error.
And for the more complex case of Audacity we have the Multiproject Wormcan.
If that was ever solved, presumably multi-threading being part of the answer, then we could simply lock down running multiple instances of Audacity.
As it is, usability conflicts somewhat with a desire for lock down. I think if you know the limits on your own machine it could well be safer to run two instances than risk the “wormcan”.
Or we restrict each Audacity instance to one core if more than one instance? So if single core, we might prevent running another instance for that reason.
We don’t, but the user is more likely to know. If the user does not get dropouts recording with one instance of Audacity, they “probably” won’t do so with two instances running. On Windows 7 or later I have tried several times exporting a track in Audacity 2.x.x with project rate different to track rate (60% CPU, dual core) while recording in Audacity 1.0.0. I never had a problem myself with recording dropouts.
I might expect dropouts on Windows XP (which is not so good at multi-tasking) and probably Vista (which is just a “heavy” OS). But I have not tried it there.
Maybe if you had two recordings in two instances of Audacity and managed to get them writing block files at the same time with an anti-virus scanning the files, there would be a problem. But even with one Audacity instance, people may be editing videos while recording. We can only give general guidance.
Indeed we do. We advise:
“Real-time recording is a very resource-intensive task for computers, which in most settings are not recording studios but multi-task machines with many competing demands on their processor. Therefore it’s important to take steps to maximise available computer resources when recording.”
Promoting running multiple instances of Audacity as a feature, appears somewhat contrary to that advice don’t you think?
I can appreciate some of the frustration for some users in that if they have a quad core processor and see Audacity running with less than 25% CPU load, it gives the impression that they are needlessly waiting around for Audacity. If we make better use of multiple core CPUs, then perhaps the incentive for running multiple instances will be somewhat diminished.
I am not “promoting” except in so far as you made me spell out how to do it. It is “unofficial”.
The fact is that people do ask about running multiple instances from time to time. It could be safer than using one instance, as things are now.
Yes the advice above stands, but was originally written in the days of Windows XP. If you don’t get recording dropouts with one instance of Audacity, you probably won’t with two instances. It is good to suggest alternatives to using two instances, like a hardware recorder or another computer.
I would not recommend recording in an instance of Audacity in a virtual machine. That will likely tax the computer much more than another real instance of Audacity.
Even then, if we just lock Audacity down to the “single project recorder/player model” it will probably encourage more people to look for “unofficial” solutions to record and edit at the same time.
If we are serious about wanting “mult-project” then we need to get serious about resolving the wormcan discsussion paper in the Wiki:
James kicked this off in January 2015 - we suspended active work on addressing it in order to get an earlier release out as the (rightful) priority - but since then very little has happened on it.
For my money in the current situation it is egregious and dangerous that actions in Project-B can affect recording (in particular) and playback in Project-A. the actions should only occur in the project that is active and be seen - so I support the “single project recorder/player model”.
An analogy: when I get in our car on the drive outside when I don’t expect the little sportscar in the garage to fire up.
I’ve read that Wiki page…
While I agree you can do funky stuff like recording in a VM simultaneously with a recording in the native OS, my first thought was that WE can, but the majority of Audacity users can’t.
If you’re careful and experienced, a lot of funky stuff is possible. I you want it to work for everyone, simply don’t enable it. Tell them them it doesn’t work, it isn’t possible. Otherwise the very first user will find a way to screw it up somehow.
The problem isn’t technical, in se, it’s inexperienced users who expect EVERYTHING to work, always. And not only in two instances, but also in 256 instances.
I appreciate that there may be times when a user wants to edit one thing while recording another. The solution that I would recommend is standard practice in studios - do the recording on a different machine. The recording machine does not even need to be a PC as there are many ways to record high quality WAV files.
If the same PC must be used for both tasks, which is less than ideal, then for a Linux machine I’d recommend “Jack-capture”. This has several advantages over using Audacity.
(1) as it uses Jack Audio system, it is possible to configure the audio connections so that Audacity cannot interfere with the recording,
(2) it will log errors if there are drop-outs, which is better than not finding glitches 'till hours, (or even weeks) later.
(3) once running, it will hang onto to its connection, making it very difficult to ‘accidentally’ disconnect.
(4) It can write directly to a WAV file, so no ‘conversion’ is required at the end of the recording, and in the event of a catastrophic crash, the recording up to that point is likely to survive.
(5) it is extremely light on computer resources (less that 1/10 of the CPU usage of Audacity).
There are also lightweight GUI jack recorders available (though probably not quite a lightweight as jack-capture).
I’m not aware of a comparable application for Windows.
Wiki might be a good place to post solutions to this question such as “jack-capture”.
I don’t know if JACK for Windows comes with jack-capture.
You can record from the command-line using Windows Sound Recorder on Windows 7 or Windows 8 in the form
SoundRecorder /FILE filename.filetype /DURATION hhhh:mm:ss.
which I think is a way to get it to record to other than WMA.
I also guess you could record from the command-line using mplayer for Windows or SoX.
I’d expect both SoX and SoundRecorder to be pretty good for minimal processor load, though because of the very limited routing capabilities of the Windows sound system, there’s still a problem of signal routing when recording “stereo mix” isn’t there? Can VB-Audio CABLE / Voicemeeter help in that respect?
Although the Audacity Manual says VB-Audio Cable can grab audio only from the application, I have seen some people say it can’t. Sound Leech definitely can.
Even if VB-Audio Cable picked up new streams playing to it, the solution would presumably be to set the Windows default devices to CABLE and Audacity playback to use the Speakers or Headphones you want. But if you had a second physical sound device you could use that instead of VB-Audio Cable.
According to http://vbaudio.jcedeveloppement.com/forum/viewtopic.php?f=6&t=87#p177 you can’t record at the command-line with VoiceMeeter.
Ah yes, I’d forgotten about Sound Leech. Does that work with modern versions of Windows?
I can’t get it to record on Windows 10.
Also in Firefox, starting to leech crashes the flash player every time.
There has been recently a program suggested on the Audacity4blind mailing list
I’ve intensively tested it. It’s simply fantastic.
Of course, it hasn’t all the feature Steve mentioned but it works great as it can be started with global hotkeys, command line and per GUI.
Give it a try, the original post from the author follows:
----- Original Message -----
From: Carlos mailto:carlos1106@xxxxxxxxxx
To: BlindGeekZone mailto:blindgeekzone@xxxxxxxxxxxxxxxxxxx
Sent: Thursday, February 25, 2016 7:44 AM
Subject: [BlindGeekZone] New Utility - Virtual Recorder
Here is a new utility I wrote which some might find useful. I will
paste the contents of the ReadMe file below.
Virtual Recorder 1.0
Virtual Recorder is a GUI/frontend for the command line media converter
and Virtual Audio Capture Device.
Virtual Audio Capture Device is a DirectShow audio device which can be
used to capture/record what is playing through your speakers. It is
also possible to record what is being played through your speakers if
your sound card has a loopback feature usually called
“Stereo Mix”/“What You Hear”
Unfortunately, not all sound cards support this feature, especially on
laptops. Some other applications like Total Recorder, GoldWave, and
Audacity can also record what is being played through your speakers. In
the case of Total Recorder using it’s own virtual audio drivers. In the
case of GoldWave and Audacity using the WASAPI loopback feature which is
native to versions of Windows starting with Vista. However, Total
Recorder and GoldWave are not free, and with the WASAPI loopback feature
in Audacity, I kept receiving errors. FFmpeg is capable of accessing
DirectShow audio devices for capturing/recording, but it is a command
line utility with many confusing parameters for the average user. All
of the above reasons prompted me to start working on Virtual Recorder.
Virtual Recorder is free, and probably much easier to use than programs
like Total Recorder, GoldWave, and Audacity if all you want is an audio
recorder which can record what you hear, your sound card’s input, or
both at the same time. Virtual Recorder is not an attempt to compete
with such applications. It is a simple audio recorder, that is all.
Most of the options should be fairly self-explanatory so I won’t go into
great detail, but I will briefly mention and describe a few things which
may not be so obvious. As mentioned above, you can record from the
virtual capture device which will only record what is playing through
your speakers. (I.E. System sounds, audio from other applications
including your browser, and so on.) Of course this means that if you
are recording an internet stream for example, system sounds, sounds
produced by other applications, and anything else you might play will
also be recorded. You should take steps when making such recordings to
avoid this issue by not running such applications and possibly even
disabling system sounds in Control Panel. You can also record from your
sound card’s line-in and microphone. Finally, you can record from both
the virtual capture device and your sound card’s line-in/microphone at
the same time which might be useful for recording podcasts, Skype
sessions, and so on. You can select what is recorded using the
combo box. If you select the
options, you should also choose the appropriate input from the
combo box. Keep in mind that the virtual capture device only records
from which ever sound card is configured as the default system playback
device in Control Panel. So if you wanted to record both sides of a
Skype session, you would have to take a few steps first.
- Make sure that the speakers or headset you are using in Skype are
configured as the default playback device in Control Panel. It is not
enough to select the device in the Skype audio settings. You can access
the default audio devices in Control Panel quickly by pressing Windows
key R to open the
dialog, and then typing
followed by Enter.
- Make sure that in Virtual Recorder, the
option is selected in the
- Select the microphone you are using in the
Note that when recording from both the virtual capture device and your
sound card at the same time, you may have overall lower levels in the
resulting file. Use Virtual Recorder’s
to compensate for this. It may require some experimentation to achieve
You can record to the lossless flac/compressed, mp3, or lossless
wav/uncompressed audio formats. Other formats could easily be added,
but I figured these are the three most commonly used.
If you select the
button, you can configure some settings like whether the program runs at
startup, minimized to the tray, or completely hidden by disabling the
tray icon. There is also a
tab where you can assign hotkeys for starting, stopping, pausing, and
resuming recording when either the main window does not have focus or is
otherwise hidden. You can also assign a hotkey for activating/showing
the main window when it is hidden. Note that you cannot disable the
tray icon unless the
“Show main window”
hotkey is assigned since otherwise you would not be able to access the
program’s main window. For each hotkey, there is an associated
checkbox. Use this checkbox if you want to use the Windows key modifier
as part of your shortcut combination. For example, if you wanted to use
Control-Windows-F12 to start recording, you would press Control F12 in
the hotkey field and then enable the associated
All settings are saved in the file
located in the same folder as the program’s main executable.
Last but not least, there are a few command line parameters for
scheduling recordings with the Windows Task Scheduler or other
scheduling software. Use -r to have the program start recording
automatically, -t to set a duration for the recording, and -x to have
the program close automatically when it is finished recording. The
format for the duration should be hh:mm:ss (hours:minutes:seconds).
For example, to have the program record for 1 hour and then close, use
the following command:
VirtualRecorder.exe -r -t 01:00:00 -x
Record for 1 hour and 30 seconds:
VirtualRecorder.exe -r -t 01:00:30 -x
Record for 1 hour and 1 minute:
VirtualRecorder.exe -r -t 01:01:00 -x
Record for half an hour, but leave the program running:
VirtualRecorder.exe -r -t 00:30:00
Start recording and continue recording until manually stopped:
Note that when recording using command line parameters, the shown/hidden
state of the main window will be based on the settings in the
There is both an installer and a portable package for Virtual Recorder,
but due to requirements for making it portable, the two executables are
not the same. In other words, do not attempt to use the installed
executable in portable mode. It will not work correctly. Also, since
the portable version requires administrator privileges to register the
virtual audio capture device, if UAC is enabled you will always be
prompted the first time it runs. This is slightly annoying, but it is
the best I can do for now.
Both the installer and portable version can be found below at the usual
place thanks to Rob Hudson.
Send comments, questions and suggestions to: carlos1106@xxxxxxxxxx