The 3.7.x series is primarily maintenance releases while we’re working on Audacity 4.0. 3.7.0 fixes the following bugs:
- #6233, #7397, #6900 Improved Linux compatibility.
- #6702 Improved contrast in the light theme.
- #7008 MP3 exports: Renamed “Insane” to “Excessive”.
- #7570, #7452 Improved non-standard character handling for cloud saving.
- #7486 Renamed “Split cut/delete” to “Cut/delete and leave gap”.
- #7293 Pasting clips no longer moves clips on other tracks if “editing clips can move other clips” is enabled.
- #7312, #7382 Fixed database compacting not working properly sometimes.
- #6851 Improved startup speed on systems with many audio devices.
- #7186 Multi view: Fixed the hitbox of the x being misaligned with the visuals. (Thanks, Kurtsley)
- #7468 macOS: Fixed VST presets path.
- #7571 Adding, removing, replacing and reordering of effects now is undoable.
- #7573 Closing a project upon turning a realtime effect stack on and off doesn’t crash Audacity anymore.
- #7610 Canceling a stereo track mid-operation no longer crashes Audacity.
- #7385 Importing Opus files using libopus no longer shifts the audio data.
Since that whole telemetry debacle, I have no interest in this project. Tenacity is where it is at.
Afaik, back when it all went down, they heard the public reaction about the telemetry thing and completely reversed course. On top of that, many distros would be sure to never distribute a build with telemetry enabled anyway. So there has never been any cause for concern. Would love to be proven wrong, though.
Also, Audacity is handy, but it’s not perfect, and I’ll gladly use a better alternative. But the last time I tried Tenacity, it had a bunch of little differences that made the tool just a bit harder to use. So I still default to audacity.
The fact they were willing to try it says all it needs to about them. They only stopped because of complaints.
Your argument is like saying Unity game engine is fine because they rolled back on the changes. Nope.
Tenacity is much more trustworthy for me.
Could you elaborate on the harder to use? It was a fork so should be pretty similar. They overhauled the build stuff to make it easier to build on multiple systems.
I disagree that it’s the same for multiple reasons: first off the project and telemetry were never profit-driven. Their goal was always to use modern methods of software development to make the software better.
The fact is, these days all for-profit projects gather a ton of info without asking, and then use that data to inform their development and debugging (and sell, but that’s irrelevant to my point). To deny open source software the ability to even add the option of reporting telemetry is to ask them to make a better product than for-profit competition, with fewer tools at their disposal, and at a fraction of the pay (often on a voluntary basis). That’s just unreasonable.
Which is why the pushback wasn’t that they were using telemetry, it was that they were going to use Google Analytics and Yandex, which are “cheap” options, but are obviously for-profit and can’t be trusted as middlemen. They heard the concern over that and decided to steer away to a non-profit solution.
But as a software dev and a Linux user, I often wish I could easily create bug reports using open source, appropriately anonymized telemetry reporting tools. I want to make making a better system for me to use as easy as possible for the saints that are volunteering their time.
As for the issues in tenacity, it was likely specific to what I was doing. I was rapidly opening and closing a lot of small audio clips, and saving them to network mounted dirs under different names. I remember I had issues with simple stuff like keyboard shortcuts to open files, and I had to manually use the mouse to select a redundant option every single time (don’t recall what it was), and I think it would just crash trying to save to the network mounted dir, so I had to always save locally and copy over manually. So I just switched back and continued my work.
