After its inception, Tenacity unfortunately tackled an irrelevant, yet opinionated part of development first: The build system, together with any internal variables saying "audacity" getting replaced with "tenacity". As such, a lot of the work that's gone into it don't manifest to users, and merging any upstream changes takes needlessly long. As a result of this, Tenacity fell behind upstream a lot, being stuck somewhere around Audacity 3.1 while Audacity already was around 3.7. Last month, mercifully, Tenacity got rebased onto Audacity 3.7: https://codeberg.org/tenacityteam/tenacity/pulls/527 (a +261299 -395037 diff!)
As far as user-facing changes go, it's some new themes, a different compressor, keeping features visible which upstream has hidden by default, MKA support without FFmpeg, as well as support for some more niche systems (Haiku, BSD). All of this is in some stages of ongoing; Tenacity 1.4 alpha 1 got released a few weeks ago, and while that does include the rebase, it hasn't ported back all of the changes which were made before the rebase.
Noteworthy: Most of the development is being contributed by one person, Avery King.
As of right now, I'd recommend Audacity 3.7.x over Tenacity, as Audacity 3.x has been in maintenance mode pretty much since 3.6, while Tenacity is currently finding its footing again. Disabling update checking is easy enough anyway.
In the future though, it appears that Tenacity is going to keep alive legacy Audacity for legacy systems while Audacity 4 is on the way of adding more DAW features and dropping support for older systems. Definitely a worthwhile role to inherit.
The things that are happening to Audacity 4 have made me ponder doing the opposite: taking Ardour and stripping it down to make an audio file editor ...
I've been using both lately. Last I checked, Tenacity was missing some of Audacity's best new features such as real-time effects. Also, Tenacity crashes constantly, whereas Audacity only crashes a lot (on my Thinkpad running Fedora).
Well, technically the reason for the fork was the implanted backdoor that was executing a binary coming from Muse groups server, hidden as telemetry and an update check. It's not a well built backdoor and the code is easy to spot, as there's not a lot of other http related code in audacity itself.
edit: Check the au3/src/update/UpdateManager.cpp, they're still not hiding this better after all that happened, lol.
I mean, you already are "executing a binary coming from Muse groups server" if you downloaded Audacity from their website. How is an auto update mechanism a backdoor? You have to accept a modal for it to run the downloaded binary.
I guess it could be improved by using and verifying signatures, but it seems pretty on point for a standard windows software auto update feature
Not good to hear they're based in Moscow, but that ship has presumably already sailed and sunk if you're running the auto-update code in an existing Audacity installation.
What other concerns besides national origin exist with this code? Nothing seems to qualify as a "back door," certainly.
Set the system language and timezone, the IP and originating ASN, to areas where APT28/APT29 is having active malware campaigns and see whether you'll receive a sample. Pretty simple.
The real question is whether they have changed their C2 behaviors since Valentine's day in 2023, and whether or not the AstraL1nvx botnet operator images are still available publicly.
that's a beautiful and very educational video. Basically how to listen user and how to implement feedback around user feedback.
I mean tantacrul's videos are generally super educational to begin with but I really liked this one tbh. Wish he could do this full time and had more frequent videos.
the only thing that I didn't liked the logo. I mean bleh. i hope they'll do something more nice to look at. that's my only complaint lol.
Listenable at 2x, so only a 26 minute video! (I highly recommend trying more than 2x for premium users, and letting your brain get used to it before poopooing it.)
I love OcenAudio, it's SoundForge for the new millennium =)
It is, however, not the same type of app. OcenAudio is a wave editor, so only one file at a time. Audacity is multitrack, and has a project structure much like a DAW without the MIDI stuff.
I'm having difficulty building it on Artix (an arch derivative).
[ 63%] Linking CXX executable ../RelWithDebInfo/tenacity
/usr/bin/ld: /tmp/lto-llvm-3894d5.o: (.data.rel.ro._ZTI21ListNavigationEnabledI8wxWindowE[_ZTI21ListNavigationEnabledI8wxWindowE]+0x10): undefined reference to `typeinfo for wxNavigationEnabled<wxWindow>'
This is probably some sort of issue with the way part of wxwindows was built on my distribution. I'd love it, of course, if anyone has had the same problem and a solution or any ideas about what to do. I will see if it's possible to rebuild some more recent wxwindows or to change its build options to include type info.
Will have to try this out. I have yet to find a reason to not just continue to use the old version 2.x audacity from the pre-telemetry days. I just need simple post-production tools after rendering out of my DAW and the old audacity does the trick.
It seems like Tenacity is getting more attention in recent days. Why that is, I'm not sure, but it's great to see it getting more traction! (I say this as a current maintainer! :D)
In recent times, Tenacity 1.4 alpha 1 was released! This is the culmination of a months-long rebase effort off Audacity 3.7.5, bringing features like realtime effects, non-destructive pitch shifting and stretching, beats and bars support, and plenty of others. Of course, there's no telemetry either, including cloud integration too.
Keep in mind that this is an alpha release, so we're still working on the final 1.4 release and are still a good deal away from it. For example, one of the most notable things missing at the moment are our themes, but those will return in 1.4 alpha 2 as I'm working on a brand new theme system to address the limitations of the current theme system. I intentionally did not reimplement our themes again because I was tired of dealing with the theme system we inherited, and this has been in the work for several years now. We should be close to fruition, but I'm performing some refactoring first before I continue on :)
Meanwhile, we're also working on an unplanned 1.3.5 release. It was originally intended to be a rebuild of 1.3.4 (which I'll explain when 1.3.5 is released), but it's going to include a fix for a spectrogram crash, Windows dark mode support, fixes for recent compilers, and a new Windows on ARM build! I also plan to get macOS builds back again, but I don't have a Mac to test things on. I know macOS builds are currently packaged incorrectly, and I'm currently trying to figure that out. If anyone wants to test out the latest 1.3.5 builds, you can here: https://nightly.link/tenacityteam/tenacity/workflows/cmake_b.... All in all, you can think of 1.3.5 as, at this point, having a few 1.4 alpha 1 backports, kind of like how 1.3.4 had a few pre-rebase 1.4 backports.
Does anyone see multitrack recording happening well in-browser?
Has anyone tried BandLab? Aside from the social slop and recent aggressive advertising, their recording app is super impressive, glitch free, low latency, easy to use and sounds great.
Or will this always be the domain of installable software?
I've never recorded with BandLab, but used it a lot for playback, and for a beginner, it's really good and very easy to use.
With regards to recording - I'm curious how this would work on a scale like 16 ins at a time. Dumping bits from the interface to disk as uncompressed .wav is trivial, on the browser I'm not sure how storage works. Would it have to upload to the cloud immediately?
Serious question: Why would it be preferable to have something like this in the browser? The thought of having to keep track of a browser tab that you might accidentally close and lose all your work doesn't sound great.
I would like to see something like this in the Web simply to allow for collaboration.
I would love to see a DAW where randos upload just a track—maybe a drum track. Other's can "create a branch" where they jam along: add a bass track. And let the jamming, branching, songwriting commence.
Why does that require the web? Networked collaboration integration already exists in mainstream DAWs without all the downsides of forcing things into a web browser
The bigger, broader problem is that "virtual jamming" just doesn't seem to have taken off the way some folks thought it would.
It's not a useless thing to be able to do, but there are few people who seem to want it at the center of their music-making activity. At least that is the way it seems to me. It initially appeared to be an immensely cool new capability, and in many ways it really is. It just isn't a thing that many people want to do.
I've seen a few products that are in essence, "virtual jamming" but they're not marketed like that. For example a bunch of live sound mixers come with an iOS app for live monitoring that you can use to feed monitor mixes straight to musicians' devices. Super useful if you have an iPad controlling Mainstage, a monitor mix, and sheet music. Another that's less obvious are live transcription/hearing assistance where you want to use your phone to tap into the output of the recording console's mix, or a translation/audio description mix.
There are monitoring apps that do send audio to the device. I'm not talking about mix control apps. These are wireless replacements for dedicated monitor mixes that run over WiFi.
Right, but those are entirely different from the control protocols used between the pad and the mixer ...
... and it is still different from virtual jamming, which more or less definitionally requires a WAN. If you're all within wifi range of the mixer, you're actually jamming :)
This is easy to fix with local storage. You reopen the tab and you're right where you left it. Unfortunately the companies see it as an opportunity to lock users in with cloud saving.
The allure is that the web is the most open, most stable and the most cross-device platform we have. Almost anything that was made for web still works today, with Flash and Java applets being the two big exceptions. Following the Lindy effect the self-contained web apps of today will still be operational far into the future.
Contrast this with Android's pathetic record of constantly breaking backward compatibility and restricting what software the users can even run on their devices.
How is the web stable? Any server can change the app you're working on without you being able to do anything. Tons of the old web is broken or gone.
Compare that to a win32 desktop app that will almost certainly keep working indefinitely without any changes. Plus you can use proper files for storage.
I didn't know it was still maintained. Just gave it a try on this laptop with Manjaro Linux + XFCE and noticed it both messes with the desktop panel toolbar making it rearrange and flash repeatedly for some seconds while loading and also when changing preferences, then doesn't correctly fit fonts into the dropdown lists in all toolbars. It appears to me it doesn't take into account that the list elements add a bigger empty space around fonts compared for example to buttons, so it considers them shorter and they're partially cut out. I don't have a GH account to properly report this.
From the Development section
> The upstream development repository is found on Codeberg. We maintain a GitHub mirror for accessibility and CI purposes, but pull requests are ignored.
An audacity fork. Reason for forking described at https://tenacityaudio.org/docs/_content/Introduction_and_Mot... . Their own summary:
> at the primary reasons were attempts at adding telemetry and a new desktop privacy policy [by the new audacity maintainers]
Previously discussed at https://news.ycombinator.com/item?id=34835200
So, 4 years since the initial forks and 2 years since the Audacium merge, how Tenacity (basically Tenacity&Saucedacity&Audacium) compares to Audacity?
After its inception, Tenacity unfortunately tackled an irrelevant, yet opinionated part of development first: The build system, together with any internal variables saying "audacity" getting replaced with "tenacity". As such, a lot of the work that's gone into it don't manifest to users, and merging any upstream changes takes needlessly long. As a result of this, Tenacity fell behind upstream a lot, being stuck somewhere around Audacity 3.1 while Audacity already was around 3.7. Last month, mercifully, Tenacity got rebased onto Audacity 3.7: https://codeberg.org/tenacityteam/tenacity/pulls/527 (a +261299 -395037 diff!)
As far as user-facing changes go, it's some new themes, a different compressor, keeping features visible which upstream has hidden by default, MKA support without FFmpeg, as well as support for some more niche systems (Haiku, BSD). All of this is in some stages of ongoing; Tenacity 1.4 alpha 1 got released a few weeks ago, and while that does include the rebase, it hasn't ported back all of the changes which were made before the rebase.
Noteworthy: Most of the development is being contributed by one person, Avery King.
As of right now, I'd recommend Audacity 3.7.x over Tenacity, as Audacity 3.x has been in maintenance mode pretty much since 3.6, while Tenacity is currently finding its footing again. Disabling update checking is easy enough anyway.
In the future though, it appears that Tenacity is going to keep alive legacy Audacity for legacy systems while Audacity 4 is on the way of adding more DAW features and dropping support for older systems. Definitely a worthwhile role to inherit.
(disclaimer: I was a designer for Audacity)
The things that are happening to Audacity 4 have made me ponder doing the opposite: taking Ardour and stripping it down to make an audio file editor ...
I've been using both lately. Last I checked, Tenacity was missing some of Audacity's best new features such as real-time effects. Also, Tenacity crashes constantly, whereas Audacity only crashes a lot (on my Thinkpad running Fedora).
Well, technically the reason for the fork was the implanted backdoor that was executing a binary coming from Muse groups server, hidden as telemetry and an update check. It's not a well built backdoor and the code is easy to spot, as there's not a lot of other http related code in audacity itself.
edit: Check the au3/src/update/UpdateManager.cpp, they're still not hiding this better after all that happened, lol.
[1] https://github.com/audacity/audacity/blob/8d6e45a9756e700b7f...
Can you point out the specific issue here? At a glance it looks like a fairly normal self-update patching process
I mean, you already are "executing a binary coming from Muse groups server" if you downloaded Audacity from their website. How is an auto update mechanism a backdoor? You have to accept a modal for it to run the downloaded binary.
I guess it could be improved by using and verifying signatures, but it seems pretty on point for a standard windows software auto update feature
You are aware that VLC, LibreOffice and many other FOSS apps have an update checker?
The problem is not the update check itself, but what the server in Moscow returns. That's the whole point and the reason of me mentioning it.
Not good to hear they're based in Moscow, but that ship has presumably already sailed and sunk if you're running the auto-update code in an existing Audacity installation.
What other concerns besides national origin exist with this code? Nothing seems to qualify as a "back door," certainly.
Set the system language and timezone, the IP and originating ASN, to areas where APT28/APT29 is having active malware campaigns and see whether you'll receive a sample. Pretty simple.
The real question is whether they have changed their C2 behaviors since Valentine's day in 2023, and whether or not the AstraL1nvx botnet operator images are still available publicly.
Audacity had a 5 year plan on removing technical debt and overhauling the UI https://www.youtube.com/watch?v=QYM3TWf_G38 (1 hour long video)
Will this be merged into Tenacity or are they going further apart?
that's a beautiful and very educational video. Basically how to listen user and how to implement feedback around user feedback.
I mean tantacrul's videos are generally super educational to begin with but I really liked this one tbh. Wish he could do this full time and had more frequent videos.
the only thing that I didn't liked the logo. I mean bleh. i hope they'll do something more nice to look at. that's my only complaint lol.
the logo on their website has been much improved imo: https://cdn.prod.website-files.com/6511efa00919fb9000588f9a/...
They have a new logo for the new release that is quite ugly in my opinion. I think that one is meant here.
Listenable at 2x, so only a 26 minute video! (I highly recommend trying more than 2x for premium users, and letting your brain get used to it before poopooing it.)
If you're curious about the legacy link being a 404, the correct link seems to be that: https://tenacityaudio.org/legacy/legacy.html
(found sniffing around https://codeberg.org/tenacityteam/tenacityaudio.org , this 404 was reported on IRC)
I like this more https://www.ocenaudio.com/features
I love OcenAudio, it's SoundForge for the new millennium =)
It is, however, not the same type of app. OcenAudio is a wave editor, so only one file at a time. Audacity is multitrack, and has a project structure much like a DAW without the MIDI stuff.
Not open source, as far as I can see.
I dropped audacity because of the audacious cloud crap in an application I view as Notepad for wav files
Tenacity has been pretty nice
I'm having difficulty building it on Artix (an arch derivative).
This is probably some sort of issue with the way part of wxwindows was built on my distribution. I'd love it, of course, if anyone has had the same problem and a solution or any ideas about what to do. I will see if it's possible to rebuild some more recent wxwindows or to change its build options to include type info.I have nothing to tenacity or artix, but my top search result gave me this link:
https://github.com/audacity/audacity/issues/4614#issuecommen...
Looks similar and kind of makes sense with tenacity using the audacity 3 UI ¯\_(ツ)_/¯
Thank you!
Will have to try this out. I have yet to find a reason to not just continue to use the old version 2.x audacity from the pre-telemetry days. I just need simple post-production tools after rendering out of my DAW and the old audacity does the trick.
It seems like Tenacity is getting more attention in recent days. Why that is, I'm not sure, but it's great to see it getting more traction! (I say this as a current maintainer! :D)
In recent times, Tenacity 1.4 alpha 1 was released! This is the culmination of a months-long rebase effort off Audacity 3.7.5, bringing features like realtime effects, non-destructive pitch shifting and stretching, beats and bars support, and plenty of others. Of course, there's no telemetry either, including cloud integration too.
Keep in mind that this is an alpha release, so we're still working on the final 1.4 release and are still a good deal away from it. For example, one of the most notable things missing at the moment are our themes, but those will return in 1.4 alpha 2 as I'm working on a brand new theme system to address the limitations of the current theme system. I intentionally did not reimplement our themes again because I was tired of dealing with the theme system we inherited, and this has been in the work for several years now. We should be close to fruition, but I'm performing some refactoring first before I continue on :)
Meanwhile, we're also working on an unplanned 1.3.5 release. It was originally intended to be a rebuild of 1.3.4 (which I'll explain when 1.3.5 is released), but it's going to include a fix for a spectrogram crash, Windows dark mode support, fixes for recent compilers, and a new Windows on ARM build! I also plan to get macOS builds back again, but I don't have a Mac to test things on. I know macOS builds are currently packaged incorrectly, and I'm currently trying to figure that out. If anyone wants to test out the latest 1.3.5 builds, you can here: https://nightly.link/tenacityteam/tenacity/workflows/cmake_b.... All in all, you can think of 1.3.5 as, at this point, having a few 1.4 alpha 1 backports, kind of like how 1.3.4 had a few pre-rebase 1.4 backports.
Anyways, I'm glad to see some interest in Tenacity. If anyone wants to contribute, feel free to come over to https://codeberg.org/tenacityteam/tenacity and contribute in anyway you can! We also have a manual that needs to be (re)written (for 1.4) here: https://codeberg.org/tenacityteam/tenacity-manual. Finally, you can also contribute to our Weblate here: https://hosted.weblate.org/projects/tenacity. However you contribute, we will wholeheartedly accept it! Thanks in advance too! :D
Does anyone see multitrack recording happening well in-browser?
Has anyone tried BandLab? Aside from the social slop and recent aggressive advertising, their recording app is super impressive, glitch free, low latency, easy to use and sounds great.
Or will this always be the domain of installable software?
Someone ported Audacity to the web. https://wavacity.com/
I've never recorded with BandLab, but used it a lot for playback, and for a beginner, it's really good and very easy to use.
With regards to recording - I'm curious how this would work on a scale like 16 ins at a time. Dumping bits from the interface to disk as uncompressed .wav is trivial, on the browser I'm not sure how storage works. Would it have to upload to the cloud immediately?
Serious question: Why would it be preferable to have something like this in the browser? The thought of having to keep track of a browser tab that you might accidentally close and lose all your work doesn't sound great.
I would like to see something like this in the Web simply to allow for collaboration.
I would love to see a DAW where randos upload just a track—maybe a drum track. Other's can "create a branch" where they jam along: add a bass track. And let the jamming, branching, songwriting commence.
Why does that require the web? Networked collaboration integration already exists in mainstream DAWs without all the downsides of forcing things into a web browser
Everyone has a browser, not everyone has a DAW, and even fewer people have the same DAW.
Doing this in a browser is ridiculously inefficient.
But if you just want a limited-track scratchpad for virtual jamming, it's the most accessible option.
The bigger, broader problem is that "virtual jamming" just doesn't seem to have taken off the way some folks thought it would.
It's not a useless thing to be able to do, but there are few people who seem to want it at the center of their music-making activity. At least that is the way it seems to me. It initially appeared to be an immensely cool new capability, and in many ways it really is. It just isn't a thing that many people want to do.
I've seen a few products that are in essence, "virtual jamming" but they're not marketed like that. For example a bunch of live sound mixers come with an iOS app for live monitoring that you can use to feed monitor mixes straight to musicians' devices. Super useful if you have an iPad controlling Mainstage, a monitor mix, and sheet music. Another that's less obvious are live transcription/hearing assistance where you want to use your phone to tap into the output of the recording console's mix, or a translation/audio description mix.
That's a completely different concept from "virtual jamming", which requires moving audio back and forth over a WAN.
The sort of live sound mixers you're describing just send control signals between the pad and the mixer, no audio flows to or from the pad.
There are monitoring apps that do send audio to the device. I'm not talking about mix control apps. These are wireless replacements for dedicated monitor mixes that run over WiFi.
Right, but those are entirely different from the control protocols used between the pad and the mixer ...
... and it is still different from virtual jamming, which more or less definitionally requires a WAN. If you're all within wifi range of the mixer, you're actually jamming :)
This is easy to fix with local storage. You reopen the tab and you're right where you left it. Unfortunately the companies see it as an opportunity to lock users in with cloud saving.
The allure is that the web is the most open, most stable and the most cross-device platform we have. Almost anything that was made for web still works today, with Flash and Java applets being the two big exceptions. Following the Lindy effect the self-contained web apps of today will still be operational far into the future.
Contrast this with Android's pathetic record of constantly breaking backward compatibility and restricting what software the users can even run on their devices.
How is the web stable? Any server can change the app you're working on without you being able to do anything. Tons of the old web is broken or gone.
Compare that to a win32 desktop app that will almost certainly keep working indefinitely without any changes. Plus you can use proper files for storage.
For something more simplistic, there is also kwave: https://apps.kde.org/kwave/
While Audacity is the app that I always have on every platform, UI is not so good. That shouldn't be hard to remake in raylib.
Audacity 4 is getting a completely new UI.
I didn't know it was still maintained. Just gave it a try on this laptop with Manjaro Linux + XFCE and noticed it both messes with the desktop panel toolbar making it rearrange and flash repeatedly for some seconds while loading and also when changing preferences, then doesn't correctly fit fonts into the dropdown lists in all toolbars. It appears to me it doesn't take into account that the list elements add a bigger empty space around fonts compared for example to buttons, so it considers them shorter and they're partially cut out. I don't have a GH account to properly report this.
From the Development section > The upstream development repository is found on Codeberg. We maintain a GitHub mirror for accessibility and CI purposes, but pull requests are ignored.