Some Mac quirks ["retro-computing"]

Programming and Development
1

Hi,

I’ve been spending some time trying to get “recent” Audacity versions to build and run on older Mac computers. I’m currently at version “Audacity-3.5.1-409-g2677399f41473fd1cd13f607018475741350c0e1” (with VST3 support, if you please :slight_smile: ) .

There are two important quirks that I’d like to address before attempting to push to even new v3 versions (v4 is “dead” as it requires Qt6 and I’m not aware of anyone having backported that to older OS X versions).

  1. I’m a heavy command-line user, so I’m used to launching applications from a shell, just like I do on Linux. This works fine as long as Audacity isn’t running, but there’s a glitch somewhere in how it combines subsequent file-open requests coming in from a terminal with those coming in via LaunchServices. Basically, once Audacity runs, any audacity /path/to/some-audio.file command from the terminal locks up the process. That’s worse than just allowing multiple instances of the application (if that’s an option I must have missed it … else … why on earth not?).
    I did find a workaround (use open -a /path/to/Audacity.app /path/to/some-audio.file if launchctl list shows the app to be running, but I’d prefer to understand why this goes wrong and fix it.
    Audacity is the only application I’m aware of that does this…

  2. Scanning for plugins hangs: you can “skip” each plugin scan manually (tip: never trigger a rescan, as this takes a LONG time!) but that still leaves background processes that don’t show up in the regular process switcher or the Dock AND consume 100% CPU each.
    The problem: accessing “unsafe” CoreFoundation functions without doing an exec() after a fork().

Issue 1) may have solved itself in later versions (be it of wxWidgets or because of the move to Qt6) but I doubt that can have be the case for issue 2).
Can anyone familiar with the internals on Mac give some feedback here, ideally pointing me to commits (or tickets) that address these issues?

Thanks!

2

Re: 1) : doing open -n -a /path/to/Audacity.app /path/to/audio.file will also hang the application. Instead of launching a new instance, as intended.

And this does appear to be an issue in the wxWidgets version I was using; I can’t seem to reproduce it with an Audacity built against its own wxWidgets fork.

Still, and this isn’t really OT, the implementation to ensure only a single copy runs seems quite heavy-handed to me, what with the persistent semaphore. Does that even allow multiple users to run Audacity on the same machine (concurrently, at least)?!