Scope and goals of this fork?

[Be-ing]

Are you intending to continue developing new features on this fork or just make rebranded builds without tracking? This code base is in awful shape, for example consider:
audacity/audacity#840
audacity/audacity#871
audacity/audacity#625

It would take a lot of work to make it maintainable long term. The linked issues above are likely just the tip of the iceberg considering the attitudes of the old developers required to create those situations in the first place.

[cookiengineer]

Excellent question.

I've seen parts of the codebase because I filed some issues in couple of projects regarding support for my Focusrite based USB audio setup... and the code related to this is straight from nightmares :(

I don't know what's the best course of action, to be honest. There's basically two/three choices:

• Don't diverge from upstream, try to be as patch compatible as possible. So this will be basically sth like a FOSS fork only.

• Diverge from upstream, and implement those features. Requires a lot of contributor time and organization.

• Complete refactor with modern approaches like Rust and QT, which makes this not a fork but a rewrite. This also requires a lot of contributor time and organization, which I'm currently not capable of providing so it needs better governance and more people chiming in as contributors.

I was mentioning QT specifically, because the whole reasoning for e.g. Arch using the old version is that Audacity modified wxWidgets too heavily to be compatible. I only know about Wireshark's refactor and the dev blog, where the author claimed that QT was the best choice for the project in terms of architecture and maintainability.

Personally, I wouldn't go the GTK3 route because I've had some bad experiences trying to write bindings for GTK in the past; and while I admire the design guidelines, I do not admire the codebase of it 😢 - so switching to QT seems reasonable to me but I haven't gotten much experience rather than some small webviews and bindings with it myself.

[Be-ing]

IMO a big refactor would be a waste. The state of the code is such that it would be easier to start from scratch, or revive another old application such as KWave. But even that uses Qt's legacy QWidgets GUI technology rather than the modern QML which is much more performant and easier to work with.

Audacity is now using GitHub Actions for their builds, so I think it would be relatively easy to slightly modify their GitHub Actions workflows to switch off the CMake options for all the networking stuff. Then you just need to upload the builds to some server and make a little website for it.

[2075]

imo starting from scratch looks reasonable considering what i read so far here and there. but involves a lot of work if you want to keep windows and such in the loop. macos would be possible with less effort, tmu. but for now i believe you just wanted to get rid of the questionable tracking situation, which can be done if the original repo license model allows for ongoing migration?

[voidMike]

I wonder if there's a possibility that audacity will eventually become closed source?

[rubyFeedback]

I think one problem is that currently nobody really knows which fork will be the one that may be maintained. (I include other "code bases" into my assumption provided they do what oldschool audacity did in pre-telemetry sniffing days).

I am not sure whether I can speak for anyone else, but I personally am sort of waiting until the community and devs have "settled" on an alternative; not just in regards to the "no-telemetry-sniffing" thing but simply from a usability and feature point of view. That the upstream audacity is dead is known - nobody trusts the pro-telemetry guys anymore. Their reputation is gone, just see reddit alone.

[blackcrack]

@cookiengineer : Who belongs this software, can it/this fork/brunch sell again to a factory ?

is a rename to "Libre Audacity" or "Open Audacity" may be not bad ?
best

[Be-ing]

I wonder if there's a possibility that audacity will eventually become closed source?

Yes, this is possible. Muse Group have repeated many times that they will not do this, but they have also completely ignored calls to put legally binding language about this in the Contributor License Agreement. So I do not think it is wise to trust them about that.

[cookiengineer]

@cookiengineer : Who belongs this software, can it/this fork/brunch sell again to a factory ?

is a rename to "Libre Audacity" or "Open Audacity" may be not bad ?
best

I do not claim ownership for the changes I made, because of two reasons:

1. I cannot maintain such a big project full-time, so it has to be more than just me.

2. I think a single owner or benevolent dictator is the wrong approach to manage the project, so I hope that once the GitHub organization has been created that it can be a welcoming open+libre project that can govern itself in a democratic manner.

Regarding Audacity in its name: Nope, see the trademark issue #5

[CliffJumper]

I wonder if there's a possibility that audacity will eventually become closed source?

Yes, this is possible. Muse Group have repeated many times that they will not do this, but they have also completely ignored calls to put legally binding language about this in the Contributor License Agreement. So I do not think it is wise to trust them about that.

It’s GPL-2. If they modify the source and release the program based on that source to the public, they’re legally required to release that modified source.

[Be-ing]

@CliffJumper Muse Group has exempted themselves from the GPL via a CLA contract that contributors are required to sign before code is merged into Audacity. I think this fork should not work to send changes upstream because of that. Of course we could open issues and talk to upstream still.

[Deledrius]

@CliffJumper Muse Group has exempted themselves from the GPL via a CLA contract that contributors are required to sign before code is merged into Audacity.

It's important to note that such a thing doesn't apply retroactively to existing contributors.

[Be-ing]

It's important to note that such a thing doesn't apply retroactively to existing contributors.

Please read the linked discussion. They claim to have gotten permission from all "relevant" contributors (and are silent about whether they paid them).

[Deledrius]

I find that to be a dubious claim, but worrying if true.

[adrianheine]

Is there a place where people interested in maintaining a fork and setting up viable governance currently meet?

[a-hurst]

I was mentioning QT specifically, because the whole reasoning for e.g. Arch using the old version is that Audacity modified wxWidgets too heavily to be compatible. I only know about Wireshark's refactor and the dev blog, where the author claimed that QT was the best choice for the project in terms of architecture and maintainability.

I'm just a random bystander here, but I think a key part of establishing a definitive Audiacity fork would be to tackle just one of its big annoyances like this. Obviously a QT rewrite would be a large undertaking, but it would get the fork to the point where it has an important feature advantage over the original, which would help this version be the one that people contribute to and recommend to their friends.

Also, as @Be-ing and others have pointed out, Audacity is currently a mess for distro package maintainers to deal with for a multitude of reasons. If a fork started trying to address those issues (maybe starting with smaller ones), that would go a long way to seeing it quickly adopted and promoted by various distributions.

[JPcode05]

Audacity is now using GitHub Actions for their builds, so I think it would be relatively easy to slightly modify their GitHub Actions workflows to switch off the CMake options for all the networking stuff. Then you just need to upload the builds to some server and make a little website for it.

My plan is to stay patch-compatible for as long as possible until the time is right, then diverge from the upstream. I would not recommend a complete refactor as it is too much work and the software aint broke, so don't fix it. Maybe in a separate project.

And If Muse Group makes Audacity proprietary and trademarks the interface, this violates the GPL, so we may freely continue knowing we have the GPL on our side. And if Audacity makes any new proprietary features, the GPL doesn't cover those, so we might not need them.

[walterwatson]

It would be insane to rebase the project on Qt given their new community/paid business model.

[sykhro]

Also, as @Be-ing and others have pointed out, Audacity is currently a mess for distro package maintainers to deal with for a multitude of reasons. If a fork started trying to address those issues (maybe starting with smaller ones), that would go a long way to seeing it quickly adopted and promoted by various distributions.

Yes, this is what will drive interest to a fork. There's still a problem: who's gonna do it?
Look at the state of contributions to Audacity before Muse took over. Besides the core maintainers, there wasn't that much activity. Interest in contributing doesn't come out of thin air and the state of the codebase is simply awful. Addressing all of this is a big undertaking for upstream, which has people being paid to work on it, what hope is there for something community-driven considering that there was hardly any community contributions in recent times?

[cookiengineer]

Yes, this is what will drive interest to a fork. There's still a problem: who's gonna do it?
Look at the state of contributions to Audacity before Muse took over. Besides the core maintainers, there wasn't that much activity. Interest in contributing doesn't come out of thin air and the state of the codebase is simply awful. Addressing all of this is a big undertaking for upstream, which has people being paid to work on it, what hope is there for something community-driven considering that there was hardly any community contributions in recent times?

The answer you're looking for is faith in humanity. And hope.

[Conan-Kudo]

It would be insane to rebase the project on Qt given their new community/paid business model.

There's nothing wrong with Qt. Every new point release is released as FOSS. The only thing they're doing is that they're delaying the free release of LTS patch releases for the maximum time they're allowed to (12 months) so that customers that actually pay for the development of Qt will continue to fund its development. Qt 6 releases have been all released as FOSS, for example.

[nyanpasu64]

Complete refactor with modern approaches like Rust and QT

Rust and Qt go together like oil and water. If you want to write a Qt Widgets app in Rust, the Ritual bindings don't support subclassing (and gtk-rs subclassing is heavy on boilerplate), severely limiting the ability to add custom painting or event handling. Alternatives include the QML bindings generator (passing messages over JSON, I suspect it won't work well for an audio app with megabytes of waveform data exchanged between the GUI and the backend if you don't have shared memory the bindings are specified in JSON but idk if it's message-based or JSON-based), and binding a C++ GUI with a Rust backend using something like cxx and interchanging C++ or C ABI types, or possibly-opaque pointers (didn't try).

[KWave] uses Qt's legacy QWidgets GUI technology rather than the modern QML which is much more performant and easier to work with.

QML isn't "better", it's different, and each is flawed in its own ways. Did you know that Qt 6 has no QML file picker and falls back to Qt Widgets, ever since they removed the legacy Qt Quick 1 file picker?

Muse Group have repeated many times that they will not [close the source], but they have also completely ignored calls to put legally binding language about this in the Contributor License Agreement. So I do not think it is wise to trust them about that.

Sadly there's no powerful organization like KDE to impose a KDE Free Qt type of agreement on Audacity.

And If Muse Group makes Audacity proprietary and trademarks the interface, this violates the GPL

Ever since they made most past contributors sign a CLA, those contributors can no longer enforce the GPL against them. And Muse Group is not bound by the GPL for all future code by employees or people who have signed a CLA.

It would be insane to rebase the project on Qt given their new community/paid business model.

I wouldn't go so far as "insane", but it's a legitimate concern.

Look at the state of contributions to Audacity before Muse took over. Besides the core maintainers, there wasn't that much activity. Interest in contributing doesn't come out of thin air and the state of the codebase is simply awful.

Was Audacity development confined to the core team because people didn't help, or did nobody help because the core team didn't help to onboard outsiders? One reason I thought the latter (but I'm not sure anymore) was because Audacity's bug report procedure used to ask users to report bugs through email, now forum. There's also a Bugzilla page that users can't file bugs at (only team members), and GitHub Issues that isn't mentioned at the page.

Also I'm curious about in what ways the codebase is awful.

How much effort would it take to create an audio editing app based off Audacity's UI, by rewriting Audacity's analysis tools (improving Plot Spectrum to allow horizontal zoom and such)? Is it possible to port over the dozens of effects automatically?

[Conan-Kudo]

If we wanted to consider Qt, then we should consider making this project part of KDE, e.V., and get the protections that exist from being a KDE project.

It wouldn't be the first time something like that has happened. GCompris was originally a GNOME project that got rewritten to use Qt and became a KDE project instead.

[nyanpasu64]

KDE already has Kwave, but it's not very popular. Hopefully the Audacity takeover will lead to more users and code activity. I don't know if it's a good idea to change the program to make the UI and keyboard shortcuts more like Audacity's, or change other things (like using Ctrl +/-/0 for zoom).

Sadly both Audacity and KWave's waveform views redraw slowly. I don't know if GPU acceleration (eg. QML) is the only way to get a faster render or lock to vsync, if it requires writing polygons or compute/pixel shaders by hand, or if there's a plug-and-play GPU-accelerated waveform viewer.

[Be-ing]

Was Audacity development confined to the core team because people didn't help, or did nobody help because the core team didn't help to onboard outsiders?

Both. They actively repelled newcomers with hostility.

[Stardust8502]

Excellent question.

I've seen parts of the codebase because I filed some issues in couple of projects regarding support for my Focusrite based USB audio setup... and the code related to this is straight from nightmares :(

I don't know what's the best course of action, to be honest. There's basically two/three choices:

• Don't diverge from upstream, try to be as patch compatible as possible. So this will be basically sth like a FOSS fork only.
• Diverge from upstream, and implement those features. Requires a lot of contributor time and organization.
• Complete refactor with modern approaches like Rust and QT, which makes this not a fork but a rewrite. This also requires a lot of contributor time and organization, which I'm currently not capable of providing so it needs better governance and more people chiming in as contributors.

I was mentioning QT specifically, because the whole reasoning for e.g. Arch using the old version is that Audacity modified wxWidgets too heavily to be compatible. I only know about Wireshark's refactor and the dev blog, where the author claimed that QT was the best choice for the project in terms of architecture and maintainability.

Personally, I wouldn't go the GTK3 route because I've had some bad experiences trying to write bindings for GTK in the past; and while I admire the design guidelines, I do not admire the codebase of it 😢 - so switching to QT seems reasonable to me but I haven't gotten much experience rather than some small webviews and bindings with it myself.

Since you seem to have worked with the previous Audacity code base, where would you start when trying to refactor it (assuming that is the conclusion)? I know a decent bit of C, but I'm certainly not a master

[Be-ing]

I recommend to start by getting it to build with upstream wxWidgets and PortAudio.

[a-hurst]

I recommend to start by getting it to build with upstream wxWidgets and PortAudio.

These seem like some great (and achievable) good initial goals. I guess the first steps here would be breaking each of these in to task lists so that people can start trying to check off some boxes?

The PortAudio issue linked in the OP has a post detailing the key differences between upstream and Audacity's custom version, so that would probably be the easiest to start with. Also Audacity's wxWidgets is only 28 commits ahead (3616 behind!) upstream according to the fork's page so that also seems manageable to break into a list.

If anyone without much programming background is looking for a way to contribute, breaking the above into checklists (see ruffle's progress tracking issues for an example) would certainly be a big help.

[ai-robert]

If this project is too much to maintain, I think a good idea would be to use Blender and port features there as needed. Blender is a full fledged media suite that already has audio (and video) editing capabilities. Contributing to Blender seems like the best way to ride on an existing project with lots of support and just focus on improving the audio editing bits within Blender.

[Sciss]

I think a good idea would be to use Blender and port features there as needed

I think the idea is to have a tool that opens quickly and does one thing without fuss - edit audio files. There are already many other applications out there that do more, like a DAW (Ardour) etc.

[sykhro]

The PortAudio issue linked in the OP has a post detailing the key differences between upstream and Audacity's custom version, so that would probably be the easiest to start with. Also Audacity's wxWidgets is only 28 commits ahead (3616 behind!) upstream according to the fork's page so that also seems manageable to break into a list.

wxWidgets changes wildly between versions, you can't really compare Audacity's version with upstream, simply because upstream won't be present in major distros for a while. e.g. Debian is shipping 3.0.2, which greatly differs in features (and bugs) from the latest version.

[sowa705]

imo rewrite is impossible and outside of the scope of this repository, keeping this repo just as a cleaned up upstream is the most simple and maintainable option

[derneuere]

Rewrites of complete apps are usually more expensive and lead to regressions. This is something I had to learn myself and others learned too. There are probably a lot of unknown Unknowns.

I think upgrading the dependencies, adding automated testing, continuous integration and incrementally refactoring are the way to go.

[sowa705]

Well its not that simple, audacity would greatly benefit from a rewrite but there's just not enough manpower to do it with this project. putting things on top of old codebases ends up with monstrosities like windows

[blackcrack]

.. and others learned too. ..

nice article, need only a hairdresser who say, "it is a nice growing wild and free Hair , perfect for study and dressing ;)
i guess only the die Lazy people do not want to read and study because , it's not they're Code out of the brain winding / brain coils and the really work tired they peoples who want not explore existent apis and funktions they could become surprises in positive way where be able to use and even less they want already not at all documentation a stranger Code and i guess become ever more a perfect Hairdresser with every step more where be more and more understand the code.. and like it was wrote.. peoples where build by self things up, want not use existent Castles of Sand and be like Child's, they want build up his own Castles of Sand ... nooo, they are not rebuilder, they are Builder and want his own... but working in community and overtake an strange/unfamiliar code is an other number of house, because it need's a understanding what sometime different peoples not have.. this is it like i guess.. danke für das Link/thank's for the link, like it.. *thumpsup* @derneuere

[ChameleonScales]

As a Linux desktop environment jumper, I'll be sad if Qt ends up being used. My experience with it has always been sprinkled with problems, accidental manipulations and other sources of frustrations, which I could definitely not say about GTK.
If this is the price to pay for MuseGroup's actions, so be it.
On the other hand, if Qt has been deemed the best solution for usability regardless of the development work that other options would require, then I have some user experiences to share.

[falkTX]

I have the opposite experience with Gtk, often a pain to get working right.
Not to mention far too many issues regarding custom theming.
But in either case, a working tool is better than no tool. Current WxWidgets as used by Audacity on Linux uses Gtk behind the scenes, still works fine. (or used to, Debian/Ubuntu hasn't updated Audacity package in a long while)

[Be-ing]

I recommend to start by getting it to build with upstream wxWidgets and PortAudio.

I have opened separate issues for each of these. Let's discuss the technical details there:
wxWidgets
PortAudio

[walterwatson]

It would be insane to rebase the project on Qt given their new community/paid business model.

There's nothing wrong with Qt. Every new point release is released as FOSS. The only thing they're doing is that they're delaying the free release of LTS patch releases for the maximum time they're allowed to (12 months) so that customers that actually pay for the development of Qt will continue to fund its development. Qt 6 releases have been all released as FOSS, for example.

---

I humbly, respectfully encourage you to reread the posts on Qt and their new model. For starters, unless you pay you do NOT get point releases. Secondly, Qt6 is not fully feature complete to what we had in the 5 series.

Sadly as a result of all of this, I for one, like many others have completely stopped greenfielding anything with Qt for free /libre open source work. Yes I'm aware that KDE is maintaining a frankenstein Qt repo. But that is not a viable long term solution in my opinion.

It's sad really, I loved Qt. But my time with them is over.

Cheers!

[Conan-Kudo]

It would be insane to rebase the project on Qt given their new community/paid business model.

There's nothing wrong with Qt. Every new point release is released as FOSS. The only thing they're doing is that they're delaying the free release of LTS patch releases for the maximum time they're allowed to (12 months) so that customers that actually pay for the development of Qt will continue to fund its development. Qt 6 releases have been all released as FOSS, for example.

I humbly, respectfully encourage you to reread the posts on Qt and their new model. For starters, unless you pay you do NOT get point releases. Secondly, Qt6 is not fully feature complete to what we had in the 5 series.

Point releases are x.y releases. Patch releases are x.y.z releases. You get the former, not the latter.

Qt 6.2 is the feature complete release, and it just had its beta release today: https://www.qt.io/blog/qt-6.2-beta-released

Sadly as a result of all of this, I for one, like many others have completely stopped greenfielding anything with Qt for free /libre open source work. Yes I'm aware that KDE is maintaining a frankenstein Qt repo. But that is not a viable long term solution in my opinion.

What makes KDE's tree more "frankenstein" than the patch releases Qt did? They're both just backports of fixes from mainline to the older series. FOSS users should not care about Qt LTS patch releases anyway. They either get Qt from their distro for Linux or use the latest point release for Windows/Mac releases.

[nyanpasu64]

Point releases are x.y releases. Patch releases are x.y.z releases. You get the former, not the latter.

Not sure myself what's "correct" or what walterwatson meant. Semver calls x major, y minor, and z patch, and Wikipedia calls both x.y and x.y.z point releases (though not mentioning x.y.0).

unless you pay you do NOT get point releases.

I'd word it differently. Everyone gets patch releases of Qt 6.x... until Qt 6.(x+1).0 is released. At that point, if 6.x is a LTS (eg. Qt 6.2), only commercial users get patch releases. Otherwise nobody does. This is not a significant issue for Linux distributions that always ship the latest Qt5 or Qt6.

Additionally, for Qt 5.15..., only commercial users are receiving patch releases. This is a real issue for open-source projects including KDE, since Qt 6 has missing components and breaking changes relative to Qt 5. To workaround this issue, KDE is maintaining their own fork of 5.15, which is better than not having changes to (eg.) fix compilation on newer headers, or fix bugs. Though for the many months between the Qt 5.15 commercial-only policy being announced and the patch collection (fork) being created, it seemed like Qt5 would be left in the dust, having been screwed over by the Qt Company.

[falkTX]

You can still cherry-pick the commits that matter.
Most of changes in Qt nowadays are not for desktop side, the Qt company is heavy focused on mobile (for better or worse)

Now, I hate what Qt company has done with Qt as well, but technically speaking there are still things Qt excels at.

Continuing with this would derail the thread more. For the time being Audacity will keep using WxWidgets, the Qt backend is unfinished and unusable for real applications.

[walterwatson]

Point releases are x.y releases. Patch releases are x.y.z releases. You get the former, not the latter.

Not sure myself what's "correct" or what walterwatson meant. Semver calls x major, y minor, and z patch, and Wikipedia calls both x.y and x.y.z point releases (though not mentioning x.y.0).

unless you pay you do NOT get point releases.

I'd word it differently. Everyone gets patch releases of Qt 6.x... until Qt 6.(x+1).0 is released. At that point, if 6.x is a LTS (eg. Qt 6.2), only commercial users get patch releases. Otherwise nobody does. This is not a significant issue for Linux distributions that always ship the latest Qt5 or Qt6.

Additionally, for Qt 5.15..., only commercial users are receiving patch releases. This is a real issue for open-source projects including KDE, since Qt 6 has missing components and breaking changes relative to Qt 5. To workaround this issue, KDE is maintaining their own fork of 5.15, which is better than not having changes to (eg.) fix compilation on newer headers, or fix bugs. Though for the many months between the Qt 5.15 commercial-only policy being announced and the patch collection (fork) being created, it seemed like Qt5 would be left in the dust, having been screwed over by the Qt Company.

• Yes I did not word it correctly. But my overall point is for many of us floss dev's Qt is no longer a viable option for new projects going forward.

[KaratekHD]

If we wanted to consider Qt, then we should consider making this project part of KDE, e.V., and get the protections that exist from being a KDE project.

It wouldn't be the first time something like that has happened. GCompris was originally a GNOME project that got rewritten to use Qt and became a KDE project instead.

I could also see a modern UI with KDE Kirigami being a nice thing

[Semisol]

If we wanted to consider Qt, then we should consider making this project part of KDE, e.V., and get the protections that exist from being a KDE project.
It wouldn't be the first time something like that has happened. GCompris was originally a GNOME project that got rewritten to use Qt and became a KDE project instead.

I could also see a modern UI with KDE Kirigami being a nice thing

There are some disputes over a new UI.

[l0go]

I like the idea of QT or maybe JUCE, although the former seems better.

[falkTX]

JUCE limits very heavily the amount of available OS targets we can build for.
For example, BSD is not supported.
Qt in comparison supports much more targets.

The current WxWidgets, using Gtk, can pretty much work on any POSIX system with X11.

[Conan-Kudo]

• Yes I did not word it correctly. But my overall point is for many of us floss dev's Qt is no longer a viable option for new projects going forward.

And I'm saying that's not true. Qt is still available as Free Software with new releases coming all the time available as Free Software. Nothing has changed here from the Free Software development point of view.

[Be-ing]

There are some disputes over a new UI.

Which are unhelpful. If someone seriously wants to do this, they can work on a different application. Proposing to change the UI toolkit is effectively proposing to rewrite the entire application. There are more immediately pressing concerns as I mentioned at the start of this discussion.

[a-hurst]

If someone seriously wants to do this, they can work on a different application.

Or at the least, if a UI rewrite is a long-term goal for the project, such discussions should wait until a) the project have a team of people interested in refactoring the existing code, and b) those people make an effort to separate the GUI/frontend code cleanly from the rest of the source in such a way that adding alternative front-ends wouldn't be such a mess.

[Songtech-0912]

There are some disputes over a new UI.

Which are unhelpful. If someone seriously wants to do this, they can work on a different application. Proposing to change the UI toolkit is effectively proposing to rewrite the entire application. There are more immediately pressing concerns as I mentioned at the start of this discussion.

Completely agree with this. WxWidgets is a powerful toolkit, much can be done with this staying as-is, even quite large scale visual changes.

[Nine-H]

WX sucks, Qt has some licensing problems, people aren't fans of GTK. Nothing's perfect. Can someone more familiar with the codebase let us know how closely coupled the core recording engine and the interface layer are? Because it might be worthwhile tearing a page from neovim's book and separating the core and UI layer, which would have some serious advantages if porting to a new interface toolkit came up in the future, a downstream wanted a more native experience, or we wanted to link against something like flutter and put a pleasant multi track recorder on mobile phones, which would be pretty useful for me because I currently use the camera app on mine to record most of my audio.

[Conan-Kudo]

wxWidgets is fairly tightly coupled into the codebase. Most Tenacity source files have includes and references to wxWidgets APIs. Reworking the whole thing to split it into two like Neovim did would be a huge effort in its own. Neovim had the benefit of the GUI being an ugly add-on to the thing, whereas Tenacity was built around the GUI.

[Nine-H]

That sounds pretty yuck, and kind of rules out an immediate Qt port. However, I think rearchitecting the software to excise that kind of vintage nastiness over time would be a good plan. Is there anything else in there that's grot? It was started back when undocumented plugin APIs were still in fashion.

edit: yep, in addition to standard audio plugins there is indeed an undocumented module API https://wiki.audacityteam.org/wiki/Modular_Architecture_Initiative

[Be-ing]

Is there anything else in there that's grot?

We keep discovering more and more.
audacity/audacity#840
audacity/audacity#871
https://github.com/tenacityteam/tenacity/pull/228#discussion_r668367887

[Nine-H]

I've seen PaUtil_GetTime missing crashes on some of my computers so some of that mess is already falling apart downstream. Re-read your posts in this thread. It's like all of the tooling is busted and I don't know how anyone thought that's how you vendor in dependencies. Mad respect for your work so far.

(edit: the crashes were in builds of upstream Audacity)