Pursuant to moving to Qt, it is a good idea to make our audio code toolkit neutral. Some of this work has already started in AudioIO and RealtimeEffectManager at the time of initially writing this issue.

This issue isn't just pursuant to moving to Qt, however. This is also pursuant to moving Saucedacity's audio processing code into a separate library, perhaps called "SauceAudio" or something. SauceAudio should not have any dependencies on wxWidgets whatsoever.

Finally, in regards to Saucedacity 1.2: some parts might be complete before Saucedacity 1.2 stable is released, but not as a whole. On the other hand, SauceAudio will not make it for Saucedacity 1.2. It is currently planned that work be started on SauceAudio for Saucedacity 1.3 development.

Thanks for preserving Audacity. Tried going to Ardour, but it 1) has a terrible artifact-y time stretch, and 2) doesn't import mp3's.

Saw this, tried it; simply dragged and dropped the .sh file into Terminal and got this:

./saucedacity: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./saucedacity)

(along with GLIBC_2.28, and 2.33 not found--the latter being 'required by ./saucedacity' and two other files ending with '... .so' )

I'm competent enough to follow basic instructions problem solving, but probably a total newbie or at best tenuously amateur by github participant standards.

Is this about "adding dependencies"? I tried searching "How to add GLIBC" and the like; not seeing the solution there.

The release page said "Basically, if you have Audacity installed, then Saucedacity will work too. If Saucedacity doesn't work, then feel free to open an issue and we'll discuss it there" ;

any guidance much appreciated.

Boost Usage Proposal

This proposal comes from the task of moving our non-GUI code to a toolkit-neutral state. Boost is a very good use for that.

With Boost, we can do many things. For example, there is Boost's ASIO library (Boost.Asio), which allows us to use networking features. This is useful for having a cross-platform implementation of our IPC server, which we do use for various tasks (I'm still looking at it to see what exactly it does). Additionally, Boost has a DLL/DSO loading library (Boost.DLL) which will assist in loading plugins and other external libraries that we use (most notably FFmpeg). There are many more libraries to Boost that might provide helpful utilities where the standard C++ library lacks in comparison. (The main point of comparison here is between Boost and C++'s standard library. I see that some of the features that Boost provides can also be useful beyond the C++ language).

Advantages

I might add more advantages here as time continues

• Assists with our library separation efforts.
• One library for several different things.

Disadvantages

I might add more advantages here as time continues

• Another new dependency

Tracking issue for:

• https://github.com/saucedacity/saucedacity/security/code-scanning/147

Temporarily, we'll use a small class that manages memory and employs some RAII strategies. Notably, this class is what manages all memory it allocates. This class is StackAllocator, although it technically doesn't allocate any memory on the stack. It does it on the heap instead.

This fix should be pushed soon. It is coming along nicely so far.

Is your feature request related to a problem? Please describe.
C++ 20 has a couple of things that would allow us to clean up more of our code base, including std::endian and stronger unicode requirements. We might be able to take advantage of some of these features as we clean up parts of Saucedacity's code base.

Describe the solution you'd like
We should bump our minimum required C++ standard to C++ 20.

Describe alternatives you've considered
A good compromise is by making Saucedacity compile in C++ 20. On the other hand, and probably more importantly, we should clean up more of Saucedacity's code base so that bumping the minimum required standard version would make more sense. Currently, we should focus on clean ups first.

Additional context
Compiler support for C++ 20: https://en.cppreference.com/w/cpp/compiler_support/20.

Bumping our minimum required Saucedacity version would also mean having to bump our minimum required compiler versions. For example, this would mean having to bump our minimum required GCC version to 8 instead of 4.9. Similarly, this would mean having to bump our minimum required Visual Studio version to 2019 instead of 2017.

Describe the bug
When the user has multiple tracks, the last track is cut off. As intended behavior, the last track should always be visible regardless of the number of tracks.

To Reproduce
Steps to reproduce the behavior:

Method 1

1. Open Saucedacity without any projects open.
2. Go to Tracks > Add New > Mono Track (or Stereo Track, it doesn't matter) and add a couple of new tracks
3. Observe bug (the last track is cut off)

Method 2

1. Open any multi-track project
2. Observe bug (the last track is cut off)

Expected behavior
The last track should be fully visible.

Screenshots

Additional information (please complete the following information):

• OS: Any (tested on Windows and Linux)
• Version: Saucedacity 1.1, latest Saucedacity alpha

Additional context
This bug was originally reported by @gotsum over at our Discussions page. We thank you for your report.

I intend to add new themes to Saucedacity. This includes a new theme in order to help us distinguish Saucedacity from upstream Audacity. However, I'm not just limiting to only one new theme. I also plan to modify the existing dark theme to make it darker as well.

Finally, we're not just limited to new themes I create. If you have your own theme to submit, make an issue with the name, ThemeAsCeeCode.h source, and screenshots of the new theme applied in Saucedacity. The only requirement is to make your theme code available under the GPL v2 or later.

Describe the bug
When exporting audio, avcodec_encode_audio2 fails with a return value AVERROR(EINVAL) (or -22). This indicates an invalid argument being passed to avcoded_encode_audio2().

To Reproduce
Steps to reproduce the behavior (as tested by me):

1. Record or open (obtain) some audio
2. Go to Export > Export Audio...
3. Select 'Custom FFmpeg Export
4. For the format, select 'OGG'. For the codec, select either codec available for the OGG format (either libvorbis or flac).
5. Click 'Save'
6. Fill in the metadata fields with any value (or leave them blank)
7. See error

Expected behavior
The export should succeed, providing completely exported audio.

Additional information (please complete the following information):

• OS: Pop!_OS 21.10
• Version: Latest Saucedacity git

Additional context
This issue was discovered while reorganizing FFmpeg support in Saucedacity. It was originally thought that the reorganization caused the error, but further investigation found that this error persisted in builds without any reorganization work (i.e. before the reorganization work was done).

Describe the bug
On Linux, under Wayland, the playback cursor and playhead do not update properly under Wayland. It is possible

To Reproduce
Steps to reproduce the behavior:

1. Start Saucedacity under a Wayland session.
2. Open an audio file or project, or record some audio
3. If opening a file: Press play. If recording: see 4.
4. Observe that both the playhead and playback cursor do not update

Expected behavior
Both the playhead and playback cursor should update as normal.

Screenshots
N/A.

Additional information (please complete the following information):

• OS: Linux
  • Tested on Pop!_OS 22.04 under COSMIC Wayland on an NVidia GPU and latest Arch Linux system on an AMD GPU.
• Version: Latest Saucedacity 1.2 development version.

Additional context
This issue was discovered and confirmed rather late, so it will not be fixed in time for Saucedacity 1.2 stable. (At least, this is most likely, but there is always a possible chance).

UPDATE

This has already been resolved. This issue is still open for the removal of some XPM files from the project.

Original Issue (as follows)

Describe the bug
When building Saucedacity on Windows, the build fails due to the updated 'AudacityLogoWithName' file. MSVC complains about some char* conversions and such.

To Reproduce
Following the build instructions in BUILDING.md should be enough.

Expected behavior
Saucedacity should be fully built at this point.

Additional information (please complete the following information):

• OS: Windows 10 (using Visual Studio 2019)
• Version: latest Saucedacity main branch.

Additional context
This also makes a greate excuse to get rid of that XPM file (and others like it, though not all). I've heard that the XPM image format is a legacy one, so that fits in perfectly here.

With that said, that likely means a redoing of a couple of things under the hood. This shoukd be coming in the next couple of days.

Describe the bug
A Conan should be removed because building Saucedacity from scratch can take quite a while when building from scratch. This is because Conan has to build wxWidgets (and others) from source. This can be quite unnecessary and especially bogs down build times.

To Reproduce
Steps to reproduce the behavior:

1. Install required dependencies (including Conan)
2. Clone this repo w/ submodules
3. Build Saucedacity using only local libraries (i.e, Conan libraries),
4. Observe long build times if this is your first time building Saucedacity.

Expected behavior
A clear and concise description of what you expected to happen.

Additional information (please complete the following information):

• OS: Any supported OS
• Version: any version as of this latest commit

Additional context
Of course, this is highly dependent on the machine Saucedacity is being built on. Conan might not slow down the build process on faster machines because of the extensive resources available. Nevertheless, for initial builds, and even on these machines, it should still help save some time as Conan will not be building dependencies from scratch.

Currently, from my tests, it appears that Saucedacity cannot fully be built against system libraries. This is namely because of zlib, which ld complains of undefined symbols. Additionally, upstream Audacity uses private PortAudio APIs, so building against the system's PortAudio will not work until this is resolved (we can still build against our own PortAudio in lib-src for the time being, however).

Describe the bug

After building on Windows x64, Saucedacity builds fail to run. Building on Windows x64 succeeds, but the built executable appears to be missing some libraries, most notably from wxWidgets.

To reproduce

Building

The instructions from BUILDING.md are used. I've even tried the oldinstructions, found on Audacity's Wiki.

Running the built executable

Simply run it, and you'll see that some libraries are missing.

Expected Behavior

The program, at this point, is supposed to be up and running, with the welcome screen and main window displayed, etc.

Additional information

• OS: Windows 10 20H2
• Version: Saucedacity 1.0

Additional context

Building Audacity's fork of wxWidgets appears to resolve some errors. However, not all libs are built.

Additionally, I'm likely skipping a step in the build instructions. The only reason why I'm building wxWidgets is from the old build instructions from Audacity's wiki. (Actually, these instructions have been deprecated for only a couple of months at the same, so they appear to be somewhat relevant). Although the new instructions (BUILDING.md) don't mention building wxWidgets while building on Windows, that's likely (if not already) the issue to why the built binaries do not work. However, it appears that more libraries are needed, such as zlib.

Overall, I believe there might need to be some additional steps in having to build this on Windows, or at least additional dependencies. Basically, I'm not clear on how to build Audacity for Windows, let alone Saucedacity.

Note: Linux, on the other hand, is unaffected. From my end, everything appears to be working okay. (Although I have Audacity installed alongside, but nevertheless the dependencies and required libraries should be the same anyways)

UPDATE

As this appears to be a dependency issue, a simple thing to do is to run either ldd (from some UNIX-like environment), Dependency Walker, or Dependencies on the produced binary. There should be a lost ofrewuired dependencies that Saucedacity relies on. Here, we could either donwload pre-built DLLs from the developer's website (e.g. for zlib https://zlib.net) or build them ourselves if necessary.

I will be trying this soon, and we will see what happens.

Tracking for a CodeQL scanning alert, which should ideally be reworked for more than just security reasons...

Calls to alloca() are found in src/AudioIO.cpp and in src/effects/RealtimeEffectManager.cpp. Ideally, they should be refactored not only for better security but to utilize C++ features.

How does an idiot install Saucedacity? (on Linux Mint)

I opened the tar.xz file and put the contents into a folder ... I opened the readme, went to the directory through terminal, then ran " source env_libs.sh "

No confirmation or error message occurred...

Then when I ran " ./saucedacity.x86_64 " I got this message:

"./saucedacity.x86_64: error while loading shared libraries: lib-string-utils.so: cannot open shared object file: No such file or directory"

I can see lib-string-utils.so is in my "lib" folder after all... Thanks in advance!

It appears that upstream Audacity has updated and reworked their FFmpeg support. There also appears to be FFmpeg 5.0 support in the latest alpha of Audacity.

Given that, I am proposing that we update FFmpeg support. I particularly want to use Audacity's lib-ffmpeg-support minus the library form (it will be integrated in Saucedacity's core). Therefore, I will be making a new branch updated-ffmpeg-support, to update Saucedacity's FFmpeg support.

We will, of course, add our own changes, but for now, I plan to see how this works well with Saucedacity Maybe this could even resolve #22, but I am not exactly sure about that.

In relation to Saucedacity 1.2, there is a chance that this will likely make it for the final release. I would normally reconsider this during a beta, but since this could fix a bug, this will have to do and will probably be merged in to main before Saucedacity 1.2 is released.

Is your feature request related to a problem? Please describe.
Tenacity PR 412 and Tenacity PR 418 have attempted to remove usage of alloca() in AudioIO and RealtimeEffectManager in PR 412. However, there might have been possible memory leaks in this fix, which is why 418 was introduced to fix some of these issues.

I have implemented a similar fix, except this is throughout the rest of the code. This is what StackAllocator was for. However, as I prefer the use of smart pointers, I've also made changes to utilize those instead. However, this wasn't entirely consistent because utilizing smart pointers right now makes for some...less than pleasant-looking code.

Using smart pointers from the start in AudioIO and RealtimeEffectManager will allow for cleaner code while not having to deal with possible memory leaks (or reducing them as much as possible).

Describe the solution you'd like
Ideally, we'd use smart pointers and maybe weak references in addition to more RAII semantics. I prefer the use of more standard smart pointers than our own solutions (e.g. StackAllocator) as much as possible.

Describe alternatives you've considered
I have not given this much thought, unfortunately, but here's something that I have below:

We could alwayys implement our own solution for these fixes as an alternative. Beyond just regular smart pointers, we could possibly implement tricks within these solutions too if need be.

You know how when you select a region, you select a start point, zoomed in... Then you want to select an end point... and when you zoom in, it zooms in on the middle of the region?

That's horrible. It should zoom in on the current marker position, so you can accurately select that end-point.

can saucedacity be translated ?

title.

probably not your priority but its nice to have,

Describe the bug
When starting Saucedacity is starting up, it simply freezes. The exact cause is unknown, but it has been boiled down to something with PortAudio.

To Reproduce
Steps to reproduce the behavior:

1. Just launch Saucedacity

Expected behavior
Saucedacity should start successfully without issue.

Additional information (please complete the following information):

• Pop!_OS 22.04
• Version: Saucedacity 1.2 alpha (latest revision as of 6/24/22)

Additional context
TL;DR: It might be an issue with PortAudio. I am working on updating it to v19.7.0 (stable).

As it appears that the issue is related to PortAudio, I have attempted to experiment with updating PortAudio. The lib-src/portmixer/portaudio.patch patch is required, but unfortunately, will not apply. I am figuring out if the other patches are needed.

If you leave Saucedacity open, it will produce this output (repeatedly) in the terminal:

Expression 'ret' failed in '/home/aking/Projects/saucedacity/lib-src/portaudio-v19/src/hostapi/alsa/pa_linux_alsa.c', line: 1812

(with the error pointing to the Saucedacity source tree, of course).

I've been discussing these topics about the project lately, since there has to be some way for the project to go. The topics being discussed are listed below:

1. Project name. We have to come up with a new project name, as we can't keep the name Audacity forever.

2. Project roadmap. We should be an idea of what we might want to do, e.g. if we want to add new features, change existing behavior, etc.

3. Possible inclusion of Rust code. Though I do like the idea of Rust, I have seen it a rather controversial issue. Therefore, I will leave it up for discussion. However, do keep in mind that we will not be re-writing anything in Rust. Rather, this is for any future contributions that introduce Rust code into the project.

Feel free to discuss these topics (and any other relater issues) below among each other.

We should be making an effort similar to Audacity's library separation efforts. I am not suggesting that we backport Audacity's efforts into Saucedacity's code base, but rather we should do the library separation ourselves in a similar nature to Audacity's efforts. For example, we should move Saucedacity's audio IO code into it's own library. We can also make that library available for general use, but that's for another issue.

Benefits

The benefits of separating parts of Saucedacity into several libraries helps with moving away from wxWidgets. Additionally, it can help with organizing Saucedacity's code base.

Why we should make our own efforts intstead of backporting Audacity's efforts

Before I go on: I will make it clear that **I am NOT opposed to backporting Audacity's library separation efforts. In fact, I've already done this with lib-ffmpeg-support (which currently resides in src/ffmpeg instead of being an actual library).

I believe that separating libraries in our own way will be more productive. Doing this effort ourselves can help us save time trying to figure out which pieces of the puzzle go where. This is especially considering that as time goes by, our code bases will continue to diverge from each other. As time progresses, I feel it will become virtually impossible to catch up with Audacity's separation efforts. Right now already, I believe there is already quite a bit of work required to catch up. Nevertheless, I like and even agree Audacity's idea of separating parts of their code base into different libraries.

If you have anything, including all questions, regarding the Tenacity merges, please discuss it here.

I am currently working on the following things to merge:

• Translations
• Themes
• Build System
  • Once the build system gets merged upstream, Qt development may start.
• New Dynamic Compressor
  • Plus RealtimeEffectManager improvements, but that's for another issue and maybe for another release.

The following list is not final. It will be finalized (and edited appropriately) when the final release agenda has been made.

I have vcpkg preconfigured and use it to build stuff occasionally. Is it possible to use local version of vcpkg instead of the submodule? if yes, what should i pass to the command line and what dependencies should i get before building?

Ah yes, another Audacity fork.

While I'm aware of all the other forks going on, I thought I'd give my try at resurrecting the situation. As we have now entered the battle, I'm ready to see what happens here.

Yes, I do have some things to do, so I'll get started with them. If you want to contribute, I welcome your help because I don't believe I can certainly do this by myself...

Anyways, let's see what this brings us to, and welcome!

Edit: Yes, telemetry is going to be removed, among others. I'm almost finished doing that right now.

That's just to state the obvious. However, we have to decide on a couple of things as they haven't been set in stone:

• A new name (obviously)
• Maybe new features? We could keep this close to upstream as possible or something
  Feel free to make any suggestions.

Anyways, expect a push via upstream right about now...
Now that that's done, I'm working on some rebranding, although I don't have a name yet. Wherever possible I'm currently working on some changes in documentation and such.

Changelog
2022-07-28: Removed Haiku, Slackware, and Alpine. We'll have to look at those another time (Haiku will not be until very later, however).

Saucedacity could be packaged and distributed on a numerous amount of platforms. Of course, we focus on 2 main platforms: Windows and Linux. However, it could be a good opportunity to bring Saucedacity to platforms that either 1) need an audio editor or 2) need a modern audio editor (namely being an alternative to Audacity).

Proposed OSes

This list is to be expanded in the mean time, and it might seem surprising (with the way the list is currently):

• Flatpak - We can publish our flatpak to Flathub
• Arch Linux (AUR), as suggested by some.
• Maybe OpenIndiana

Help Wanted

I know that should Saucedacity be working on any platforms on the list above, it'll add to my tasks with Saucedacity, of which I already have enough to do right now. Therefore, I would like to put out a "Help Wanted" sign to anyone who might be interested. If you have experience with packaging, your skills will be especially useful to Saucedacity (and particularly to this issue).

Status

AUR: Researching
Flatpak: Researching. We might be eyeing Tenacity.
OpenIndiana: In progress

Notes on Building

AUR

• Might add some PKGBUILDS.

Flatpak

• Currently eyeing Tenacity's flatpak builds. Comment below if you think this is a good idea.

OpenIndiana

• Building with Conan fails due to Conan executing make -j<n> (e.g. make -j6), which OpenIndiana's make does not like.
  • Building without Conan is currently in the works. I am attempting to find development packages for the different required libraries (right now zlib)

Just a quick suggestion:
Write the differences between Audacity and Saucedacity in your Readme and the main website. Will help new users figure out why they should use one versus the other.

I am trying to build saucedacity on windows before i start working on some code. I have some doubts related to building it on windows:

• i have vcpkg preconfigured and do use it to build stuff occasionally. Is it possible to use local version of vcpkg instead of the submodule? if yes, what should i pass to the command line and what dependencies should i get before building?

It appears that lib-uuid was intended for Sentry error reporting, oroginakky introduced in Aidacity. However, Saucedacity removes almost all (if not all) of this error reporting functionallity. Therefore, lib-uuid is really just a left over from error reporting and really is dead code.

Although left over from error reporting, this code only generates UUIDs and has no networking functionallity at all, so there is no need for concern, except if it relates to dead code.

Describe the bug
It appears that all plugins are disabled. This is likely due to incorrect folders (as Saucedacity in this case is not installed to system directories).

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Effect;
2. Click on 'Add / Remove Plug-ins...'
3. Observe that all plugins are disabled.

Expected behavior
At least some plugins are supposed to be enabled. Additionally, there are supposed to be menu items in 'Effect' and 'Generate' also.

Additional information (please complete the following information):

• OS: Pop!_OS 21.04
• Version: Saucedacity 1.0.1-alpha

Additional context
As stated before, this might be because of Saucedacity not being searched. In Audacity 2.4.2 on Pop!_OS 21.04, it appears that such plugins are found in /usr/share/audacity. In Saucedacity, (from what I presume anyways), this would either be /usr/share/saucedacity or (more likely) /usr/share/Saucedacity. However, plugins are loaded from the current working directory first, as the system directories take less priority over the current working directory (with SAUCEDACITY_PATH having the largest priority). Note that all this information comes from src/AudacityApp.cpp, should I recall correctly.

Is your feature request related to a problem? Please describe.

As you can see, the context menu is not in dark mode. The toolbar icons in Saucedacity/Tenacity are too big and make it seem less 'professional'.

Describe the solution you'd like
Implement a dark mode like the Notepad++ approach.

Still in awe how they got an outdated, old-school looking program into something as nice as that.

Describe alternatives you've considered
I would've considered Audacium, but it looks like it's also dying and the last update was months ago.

The Audacity/Saucedacity JACK implementation is technically functional, but it is different from most other jack clients, and as some people have described it: "A perfect example of how not to implement a jack client.

Current Behavior

When "JACK Audio Connection Kit" is selected in the Host drop-down, The recording and playback device show the clients currently connected to the jack audio server. Nothing else happens until you start recording.

When you start recording, Sauceacity automatically connects to the jack clients that were selected. It is then possible to switch the connections to other ports, but since Saucedacity is already recording you end up having to cut the first part of the recording and it makes it hard to record that track alongside other tracks. This makes it difficult to use Saucedacity with anything more than the most basic jack setups.

Expected Behavior

When "JACK Audio Connection Kit" is selected as the audio host, Saucedacity should connect to jack, and register input and output ports, but it should not automatically connect to anything.
Then the user can connect Saucedaity to other jack devices, and when they start recording, Saucedacity will respect these connections. Same with playback.

Alternatives

• Enabling "Sound Activated Recording". This gives the user more time to change the connections from what Saucedacity automatically does, but it is still much more of a hassle than it should be, and it means that as soon as you connect to something it will start recording, which isn't ideal in most cases. and still isn't a proper jack implementation.
• Using some sort of pass-through jack client that Saucedacity automatically connects to, and then manually connecting the passthrough client to other clients.

Additional context

This is a problem in the Audacity issue tracker, but the maintainers basically said it was usable how it is and they weren't going to fix it, So I created this in hope that there will be more support for a better jack implementation here.

Applicable Audacity Issues:
audacity/audacity#3553
audacity/audacity#711
audacity/audacity#710

If there is anything I can help with related to this issue, please let me know.

(This issue is a duplicate, just not a duplicate of an existing Saucedacity Issue.)

Hi love this zombie. I hope it keeps limping on
I've been on the Tenacity code base here. I'm not going bother you im not coder so sorry

Moving Saucedacity to a toolkit neutral library helps with reducing the dependency of a specific toolkit (namel wxWidgets) on Saucedacity. Most of this code would be moved to lib-basic-ui, something re gained in the Audacity 3.0.3 rebase.

The primary intention of making Saucedacity toolkit-neutral would ease the task of possibly having to port code in Saucedacity to a new toolkit should we ever want to switch.

Finally, Audacity intends to move toolkit specific code to lib-basic-ui. However, we plan to make this a priority, therefore not having to rely on Audacity for such changes.