> 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
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)
In Audacity, our goal is to keep it extremely approachable for beginners, so for us the idea of having one view of a clip in context of the project and a different view in which you only see the clip is something we'd rather not do. A wave editor window or panel separate from the main project timeline is however the industry standard, and as such it might be exactly the sort of feature which would be very at home in Ardour.
Already landing in Ardour 9. However, at present, since our editing is always non-destructive, you can't do much there other than move start/end markers. We'll likely be doing more work on variable realtime time stretching in the march towards v10, and that will likely be accessible from both the main timeline and dedicated editors (but we'll see).
And yeah, Ardour's current goal is much more focused on being a powerful tool for people who do this stuff a lot, but there are a variety of arguments that support the idea that we need to do something/more to support beginners. We'll see about that too.
I do want to mention the build system part though: indeed, there are trade offs of Tenacity's build system vs Audacity's build system. However, on Windows (and hopefully Mac soon), it does allow us to ship newer versions of our dependencies, such as wxWidgets, which means we can do some neat little things. For example, the latest development nightly version of Tenacity (which you can download at https://tenacityaudio.org/nightly) supports Windows dark mode simply because wxWidgets now has support for it. Alas, it's an undocumented features on Windows that can break at any time, but for now, it works, and it's a nice little thing to have. It will especially help when we implement dynamic theming support (which I have figured out how to adapt to light/dark mode changes via wxWidgets). Of course, merging upstream changes can be very long, but we can also work around that. (Sometimes, we are the upstream too, especially with libmad and libid3tag ;). Either way, I find one benefit of it is allowing us to easily use newer dependencies that enable us to use newer features, and while this doesn't matter a whole lot on systems like Linux, *BSD, Haiku, etc., it does help with systems like Windows and (hopefully soon) macOS. (Currently, you can install Tenacity via MacPorts).
Also, I wouldn't necessarily say that work on the build system lead to us falling behind in development necessarily. I'd say that was due to the hiatus we had. Unfortunately, maintainer burnout can happen, and it doesn't help that Tenacity's start had a bit of its own controversy either with naming. At this point, that seems to be mostly behind us. From what I've seen anyways, I don't see many people mention it at all, but I could be wrong.
Regarding the rebase, yes, not everything's been ported back. In fact, for 1.4 alpha 1, I actually intentionally left out one thing: our own themes. I decided I was done dealing with the theme system, so I decided I would go about rewriting it. I had this planned for several years at this point, and there was already some code to experiment with before the rebase. If not for user themes, then it's certainly for the maintenance part of it, as themes should be easier to work with afterwards. (If anyone is interested in what the new theme system would have to offer, then I'd be glad to discuss it! :D)
Finally, would it be appropriate to say we're going to keep legacy Audacity alive "for legacy systems"? Maybe the "legacy Audacity" part, but not "legacy systems". If anything, I think it's safe to say that Tenacity on Linux requires a distribution like Debian 12 or later (including its derivatives). Sure, Debian 12 might be a bit older at this point, but I wouldn't necessary call it "legacy" just yet right now. Do we aim to support older distributions as time goes along? As long as it's reasonable. The same goes with Windows and macOS. In fact, Tenacity requires macOS 10.15 and has for some time. I want to increase the minimum version some time later, at least to macOS 11 if not later, but I'll likely give (what I think should be) plenty of time before that happens.
I think time will have to tell where this all goes. After all, I think there's some purpose for Tenacity to exist considering we've already had over 3,000 downloads for the 64-bit Windows installer for 1.4 alpha 1 alone. It might not be much compared to Audacity, and I think it pales in comparison to Audacity's popularity. To me, however, even 3,000 downloads is quite a lot, and it means something to me. There's also someone looking to package Tenacity for FreeBSD, albeit it appears to be the 1.4 alpha 1 version (which I would prefer the latest stable version for clear reasons). Yes, it's, like you said, a "more niche" system, but it's interest nonetheless.
P.S. I welcome any contributions from any contributors, especially those packaging Tenacity. We don't require any CLA, just the Developer Certificate of Origin (the same one the Linux kernel uses), and neither do we use AI to review contributions ;)
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...
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
What other concerns besides national origin exist with this code? Nothing seems to qualify as a "back door," certainly.
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.
Either way, just wanted to say hi! :D
There's a reason for why I am doing what I am doing.
Will this be merged into Tenacity or are they going further apart?
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.
(found sniffing around https://codeberg.org/tenacityteam/tenacityaudio.org , this 404 was reported on IRC)
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.
Tenacity has been pretty nice
[ 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>'
https://github.com/audacity/audacity/issues/4614#issuecommen...
Looks similar and kind of makes sense with tenacity using the audacity 3 UI ¯\_(ツ)_/¯
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
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 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.
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.
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.
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.
... 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 :)
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.
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.
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?