3.2 is nothing but crashes at launch.

Ever since upgrading to 3.2, Audacity has been a trainwreck.

Macbook Pro running MacOS X 10.14.6.

Launch the app.

Expected outcome:
App launches and I start working in it.

Actual outcome:
Instant crash relating to some VST plugin.

I never granted Audacity access to my plugins and I don’t want it to have any. I have Logic Pro for that stuff. So 3.2 was a huge surprise, seeing it try a land grab on all my plugins. Before I could even stop it, it crashed, opening up a bug report window, asking if I wanted this report sent or not. I managed to get into Preferences and turned off every damn option I could find to tell Audacity to stay out of my plugins. But on relaunch, sure enough, it’s scanning for plugins again, and crashing. I’ve been using Audacity for years and years and years and this feels like the worst update ever. I sure hope you fix these bugs ASAP.

Some additional details:

The crash dialog box was labeled Exception Code 0x1, by the way.

Also, now whenever I launch Audacity it is STILL scanning for plugins, even though I’ve disabled such functionality via preferences. And it scans forever.

How does one absolutely STOP Audacity from going anywhere NEAR plugins? That is not what I use this app for.

By the way, I’ve installed and it still immediately scans for plugins upon launch. Is there ANY way to make it stop doing that???

I don’t think so, other than allowing it to complete once.
Once it has completed the scan, it should not do it again unless you tell it to (“Rescan” button in the Plugin Manager)

Appreciate the reply, thanks.

Well, I’m disappointed in the Audacity team’s decision to go this route. This is not how it should be done. If I indicate in preferences I don’t want it to touch my plugins, it shouldn’t be doing a scan every time I launch the app. It’s none of the apps, or the Audacity team’s business. Audacity is not my DAW, never will be. It’s a tool I use on the side. Did use, that is, for more than a dozen years, and now I’m not so sure, if the app is going to try to become something it’s never been.

It’s not my DAW either. I already have a much more capable DAW, so I don’t need another one, but I do need a good “audio editor”, which is what I use Audacity for.

There has certainly been a change of direction since muse group acquired Audacity (https://mu.se/newsroom/tpost/6dhedma301-muse-group-acquires-audacity-expanding-c).

I created an account in this forum, just so I could add to your comment.

Same there here, the last scan I did lasted more than 3 hours and nowhere to be completed → my mac runs the latest M1 Max/32gig and is dedicated to music production → I have more than a 1000 plugins… Allow me to say → trainwreck is way too nice here.

I’ve been using AD for decades and never have I lived something so ridiculous.

Which idiot decided a native scan from start was a good idea?


Sorry to hear you’re having the same problem. Though, glad to hear it’s not just me.

Hey Audacity team, if you’re out there, c’mon. Fix this stupidity.

Your comments have been forwarded to the Audacity development team in the form of a suggestion here: https://github.com/audacity/audacity/issues/3802

Please feel welcome to add to this github issue and/or create your own issue.

Also, Jayseb, please confirm that you still experience this issue in 3.2.1. Thank you.

I am still experiencing this in 3.2.1.

Users with Universal Audio recording interfaces (e.g. the Apollo rack units) will all have the plug-ins installed on their Macs, but they may take their Mac laptops away from the studio for a while, perhaps to work on something in Audacity that doesn’t require these plug-ins.

Universal Audio interfaces are the hardware DSP powering these plug-ins, but the plug-ins themselves might be checking to see if the UA unit is plugged in at the time of testing / activation. Additionally, the plugins themselves are licensed internally on the UA hardware—there is no iLok HASP or Aladdin dongle, it’s all done over the internet and the license is updated inside the interface’s memory—so the plugins may also be checking for activation keys even though the UA isn’t connected.

Audacity 3.2.1 is hanging indefinitely at checking one such plugin, and since there is no ‘skip’ button I must either Stop or Cancel.

I came back this morning after leaving it overnight. 12 hours. No progress.

I pressed “Stop” and will be marking all of the UAD plug-ins as “Disabled” for now.

Here’s a screenshot of what that list looks like in Audacity. Note the pathnames start with !UAD/aufx/xxAU, which is not a real path. The plug-ins in the “VST” folder are references to the real ones in the UAD collection.

After marking the UAD plugins as “Disabled,” I relaunched Audacity. Now there is a second Audacity icon bouncing in my dock. The plug-in validator appeared and was still stuck on one of the UAD plugins. Eventually the icon stopped bouncing.

I would suggest that Audacity break out the plug-in validator into a totally separate executable, the way that Logic Pro does, and monitor this child process for responsiveness. If it takes more than 10 seconds for the child process to validate a plugin, kill it and note the condition so the end user can decide how to handle it later.

Real-time plugins are not available in Audacity until this scan completes once..

Without completing the scan, the “Add Effect” drop-down menu is empty except for “Get More Effects…”

I’m attaching the crash log caught by macOS when killing the spawned validator process, and also a screenshot of what the UAD plugins look like in Audacity.
Screen Shot 2022-11-06 at 11.15.03 AM.jpg
audacity-plugin-validator-hang.txt (22.4 KB)

Thank you for sharing these difficulties.

I see you have also shared your report at https://github.com/audacity/audacity/issues/3802 which is where the developers will see it. :smiley:

The developers have marked this issue for attention for the next maintenance release which would be 3.2.2, which they are hopeful will be released within a few weeks, barring unforeseen problems.

Hey jademan, that’s awesome. Do you want me to beta test the release ?

So I am not sure that they have asked for beta testers yet, so you are on your own here, but on the github page, you can click on Actions. Then, look under the Events column until you locate the first tag, “release-3.2.2”. There must be a green checkmark. If not, find the next such entry. Then click on the black ink and scroll all the way to the bottom of the page until you find Artifacts. Find the one appropriate for your OS (eg. beta, MacOS, arm64, universal, x86_64) and download.

Thanks. I found Actions; however, it was actually under “Branch,” not “Events,” where I found I could “filter by branch” by entering “release-3.2.2” and selecting that tag. There are failures and successes as you described. If I am to judge by the action event titles, the newest build relevant to our plug-in predicament was executed 19 days ago by Paul-Licameli to “enable graphical UI for VST2 effects on macOS…” I’ll start with that build and work my way forward.

Update: my previous link was pointing to the wrong action (I selected the one above it). I will edit that link once the moderators approve my post.

On build 20221103, when I launch Audacity it starts running through the plug-in verification. It’s throwing an exception on every plugin, but this time Audacity is the one catching and handling the exceptions. The child process spawns and immediately shows a “Problem Report for Audacity” with Exception Code 0x1, and offers to send the report to Audacity. I can copy the text from this window.

Now I could probably sit here and dismiss the crash windows, but that will take a while due to the number of UAD plugins. :slight_smile: I’ll just post this screenshot and a crash sample text for now.

I’m running Universal Audio drivers v10.1 (compiled May 2022) and macOS Monterey 12.6.
Screen Shot 2022-11-06 at 8.44.06 PM.png
audacity-exception-0x1-uad-plugin.txt (82.4 KB)

Do you press the “Send” button - as that sends a crash report to the development team?


So I get “audacity-macOS-3.2.2-beta-20221103+c5a299b-arm64” as the most recent 3.2.2 public build available for download. I think you can rest assured that you have done all that can be done at this point. (Other than click the Send button as Peter suggested and update the tracking issue at github.).

If the current behavior is unacceptable, let me suggest reverting to 3.1.3 where I don’t believe they did all of this plugin scanning: https://www.fosshub.com/Audacity-old.html

Here is another post by a user with a Universal Audio interface: https://forum.audacityteam.org/t/how-do-i-get-plug-in-search-to-skip-a-folder/65963/1 Note the team member’s reply:

Yep! I hit “Send” on about 10 different plugins before trying to ‘skip’ them.

Paul Licameli made another build about 5 hours ago for “vst2 statelessness.” Going to give it a spin.

edit: didn’t make any difference. The UAD plugins still cause an 0x1 exception crash. I sent a few to the team.

edit2: OK, so Audacity appears to be able to get past some of the UAD plugins, but most fail. I’ll keep moving forward in the plugin check to see if I can spot a pattern on which ones Audacity scans without issue.

For instance, two plugins that it was able to scan were “UAD Oxford Dynamic EQ” and “UAD Oxford EQ.” I’ll reply later with a complete list of plugins that were passed or marked incompatible. I think it might be worth it for the Audacity staff to reach out to UAD and ask what it is about these plugins that might cause Audacity to crash. Audacity is like any other DAW. It behooves UAD to provide instructions for developers on how a DAW should check their plugins without crashing the app.

Yes - I wouldn’t hold my breath for any overnight fixes. :smiley: