Audacity 3.0.3 Released

Hello everyone!

As I understand it, the latest version 3.0.3 no longer works on 32-bit operating systems?

Thank you!

The default for Windows (and for all operating systems) is now 64-bit. If you have a 32-bit Windows system, you will find a 32-bit download available on the download website that should work for you.

For 32-bit Windows, use the 32-bit version of Audacity.

For 64-bit Windows, use the 64-bit version of Audacity, unless you have 32-bit plug-ins that you need to keep that are not available as 64-bit.
(32-bit Audacity will work on 64-bit Windows, but 64-bit Audacity is the preferred version. 64-bit Audacity only supports 64-bit VST plug-ins, and 32-bit Audacity only supports 32-bit VST plug-ins. Nyquist plug-ins work in both 32-bit and 64-bit Audacity.)

Both the 32-bit and 64-bit versions of Audacity 3.0.3 are available here: Audacity download latest version

Can you install both 64 and 32 bit versions simultaneously on a 64 bit machine, and select which version to launch? Thanks!

Yes, but they need to be in different folders - BUT you cannot run them both at the same time.

Peter.

In some cases it may be possible to run both at the same time, but don’t - doing so could corrupt both projects.

You should also use a “Portable Settings” folder for one or both versions, so that 32-bit plug-in settings are separate from 64-bit plug-in settings.
In my opinion, it would be much better to use the ZIP versions rather than installing.

If you’re not sure what you’re doing, then best to stick with one version: 64-bit Audacity on 64-bit Windows, otherwise 32-bit Audacity.

I tried using the “Portable Settings” on a USB SSD drive. Extracted the 64 bit zip file, and set up a “Portable Settings” folder at the root of the USB drive. When setting up on a computer that didn’t have Audacity already installed on the C: drive, it went okay…

BUT, with trying to set it up , or to use it on a computer that has “Audacity 3.0.2 32 bit” already installed, it comes up with MANY dialog boxes (each one needing to be dismissed), saying “Attempting to initiate the following effect failed”, etc. (Apparently finding the 32 bit VST files in the Audacity folder on the C: drive.)

Not useable. Seems to be looking at plugin folder on C drive, even though running from the USB “D:” drive, in this case.

Happens on multiple computers. Thanks…

The “Portable Settings” folder needs to be in the same location as the “audacity.exe” file.

For a small selection of features, such as the new automatic check for new versions, it would be nice to be able to disable it system-wide. By that, I mean some kind of separate configuration file that unprivileged users won’t be able to modify that would not only disable the feature in question, but either grey out or remove the option from the preferences dialogue box. I am specifically concerned with builds for Windows.

The features I am concerned about are:

  • Automatic check for new versions
  • Check for Updates in the Help menu

Obviously, any user can check audacityteam.org to find the latest version, but we’re more concerned with in-application reminders that inevitably generate unnecessary help desk calls from impatient users or users ignorant of our corporate software update cadence. We already have a monthly regimen of checking for, packaging, and deploying new versions of open source software such as Audacity and they’ll get the new version as long as it doesn’t violate corporate software policies.

It would be ideal if we could simply choose to disable these features by adding parameters to the installer command-line, but it would be simple enough to apply a separate LockedPrefs.ini file after installation, for example.

I’d also argue that it would be nice to be able to apply a system-wide set of default preferences as well – for example, to set some default file paths to a dedicated, low-latency disk – but that is a far more complicated feature to implement and a less pressing concern.

I’m sure that you’ll understand that Audacity is primarily intended for individual users rather than corporate users.
For an individual user of Audacity, I think it is right and proper that they (the user) can chose whether they wish to be notified of new releases or not.

As a corporate user, you could either build Audacity from the source code with networking disabled (it is disabled by default when building from source), or you could request a “corporate version” of Audacity to be built for you.

I’m not sure if we currently have a contact for corporate enquiries, but I could try to find out if you would like?

That would be great!

I’ve got a lot to say on the subject, but suffice it to say that I think a feature like this would allow a lot more companies to adopt the software who simply license a commercial alternative. As a proponent of FLOSS, I generally think the more users the better. Perhaps they might even participate. :slight_smile:

Perhaps you could write a “audacity.cfg” file to *Users<username>\AppData\Roaming\audacity*
The audacity.cfg file contains Audacity’s “preference” settings.

Most of the settings in audacity.cfg are fairly straightforward if you look at an existing audacity.cfg. For example, to set the default Export location, you would need to include:

[Directories/Export]
Default=<enter required path here>

Note that the audacity.cfg file must be writeable for the user, as it also stores information such as the recently opened files list.

This is a user setting contained in the user’s profile. It’s not system-wide in any way and to make it act as a default, we would have to overwrite or modify the user’s configuration. We don’t want to clobber the user settings, we want admins to be able to provide sensible defaults for the systems they administer without writing dubious login scripts.

What I’m suggesting is a new feature. An optional “defaults.cfg” file created by an admin in the same folder as “audacity.exe” which could basically contain all the same options as the “audacity.cfg” file. There are a few common ways of handling this in the application.

  1. A simple check on app launch that scans both the user’s “audacity.cfg” file (writeable) and the “defaults.cfg” file (possibly non-writeable) and populates any entries not already defined in the user’s “audacity.cfg” file with those from the “defaults.cfg” file. This should probably happen as part of the normal creation of the “audacity.cfg” file on first launch to allow these admin defaults to supersede the app defaults. No settings get clobbered and the user is still in control, but some default values are applied early, so none of the rest of the code needs to change.
  2. A more robust fallback mechanism where both .cfg files are parsed and the entries kept in memory as distinct configuration sets. During normal references to the user’s configuration, if a given setting isn’t found in the user config set, the default config set is referenced.

Option 1 is very simple and should be more or less self-contained in that it shouldn’t affect other code and is therefor low-risk.

Option 2 is much more elegant, but from what I’ve seen in the code it would require an overhaul of the configuration code. It might be worth doing however, because once the concept of configuration sets is implemented it opens other efficiencies. Application defaults could be another config set, for example, allowing default values scattered all over the source code tree to be collected in one place if that makes sense to do. From there it’s easy to implement another configuration file in the “audacity.exe” folder called “locked.cfg” that allows the admin to override both user settings and other defaults, thereby satisfying my main request. :slight_smile:

You would effectively have a simple fallback for each setting that descends a list of configuration sets. The first defined value to be found is used.
The search order would go like this:

[locked.cfg (ro)] -> [audacity.cfg (rw)] -> [defaults.cfg (ro)] -> [App Defaults (ro)]

Say the app needs to look up the value of the “Directories/Export/Default” value. It will first check the “Locked” config set (locked.cfg). If the setting isn’t defined in that file or the file doesn’t exist, then it will try the “User” config set (audacity.cfg) next. If it’s defined there, it will use that and stop checking for the setting in other sets. If it’s not, it will try the “Defaults” config set (defaults.cfg). If it’s not defined there either (or the file doesn’t exist) it will fall back to the “App Defaults” config set, which should have values for every possible setting.

Ultimately, the ability to disable the automatic update check and “Check for Updates…” in the Help menu are my priorities, but I think it makes sense to look at the configuration system more broadly and consider changes. I’d take a crack at it myself if I could justify a Visual Studio license to my boss!

I want to be clear. I don’t think this configuration overhaul is necessary to implement the ability to lock down automatic updates, etc. I’m just making an argument for robust configuration code. The lockdown code can be pretty simple really, but it needs to involve an additional file. It doesn’t even need to lock down any more than two settings. Allowing an administrator to disable the automatic updates and “check for updates…” in the Help menu is all it would take to make Audacity totally enterprise-friendly.