Please, see our response:

https://github.com/audacity/audacity/discussions/889

Dear all,

Due to the large amount of worry about this PR, (which we completely understand), we want to clarify exactly what is going on:

1. Telemetry is strictly optional and disabled by default. No data is shared unless you choose to opt-in and enable telemetry.
2. Telemetry only works in the builds made by GitHub CI from the official repo (the telemetry URLs are only defined there).
3. If you are compiling Audacity from source, we will provide a CMake option to enable the telemetry code. This option will be turned off by default.

Why have telemetry at all?

Essentially, it’s to help us to identify product issues early:

1. Audacity is widely used across several platforms, but we have no information on the application stability.
2. It is difficult for us to estimate the size of the user base accurately.
3. We need a way to make informed decisions about which OS versions to support. For example, can we raise the minimum version of the macOS to 10.10 to update the wxWidgets to the latest version?
4. We have a known issue with the new file format introduced in Audacity 3.0. We found it with the great help of the community members on our forum. However, there is no way for us to estimate the impact of these issues on users. Is it just a random case? Do we need to rush the work on the recovery tool or help the users one by one? Or do we need to rethink the file format to make it safer and more easily recoverable?

Regarding the concerns about the choice of providers:

1. We do not incorporate cross-site tracking, limiting the ability to identify the user by both Google and Yandex.
2. Yandex would only receive the “application opened” event to help us estimate the size of the user base.
3. Google would only receive: a. Session start and end events; b. Errors for debugging; c. File formats used for import and export; d. OS and Audacity versions; e. Use of effects, generators, and analysis tools to prioritize future improvements;
4. We will consider replacing Google and Yandex with another service if we find one that fulfills our requirements - thanks for the suggestions and keep them coming.

Just to reiterate, telemetry is completely optional and disabled by default. We will try to make it as clear as possible exactly what data is collected if the user chooses to opt-in and enable telemetry. We will consider adding the fine-grained controls that some of you have asked for.

Also:

To address the concerns about use of private library versions, the largest part of this pull request is a networking layer built on top of libcurl. This library is chosen as it is an industry-standard for cross-platform networking. It is exceptionally tested and reviewed by industry experts. The layer on top of it, aka lib-network-manager meant to simplify the development of future features. libcurl is used without any patches. It is possible to use the system-provided version of the library available on the Linux distributions, and we will double-check that this works as expected.

Original PR description:

This request provides the basic telemetry for Audacity.

To implement the network layer libcurl is used to avoid issues with the built-in networking of the wxWidgets.

Universal Google Analytics is used to track the following events:

• Session start and end
• Errors, including errors from the sqlite3 engine, as we need to debug corruption issues reported on the Audacity forum
• Usage of effects, sound generators, analysis tools, so we can prioritize future improvements.
• Usage of file formats for import and export
• OS and Audacity versions

To identify sessions we use a UUID, which is generated and stored on the client machine.

We use Yandex Metrica to be able to correctly estimate the daily active users correctly. We have to use the second service as Google Analytics is known to have some really tight quotas.

Both services also record the IP the request is coming from.

Telemetry collection is optional and configurable at any time. In case of data sharing is disabled - all calls to the telemetry Report* functions are no-op.

Additionally, this pull request comes with a set of libraries to help the future efforts on Audacity.

For anyone not yet aware the official privacy policy was updated on the 2nd of July and contains some very disturbing things, most notably under data collection is "Data necessary for law enforcement, litigation and authorities’ requests (if any)", I want to ask what exactly does this mean ? this is completely vague and tells us nothing about what is actually being collected.

As far as I'm concerned any data collection is unacceptable unless what is collected is exactly stated and opt-out is provided, for an open source project this is doubly so, I urge all users to remove Audacity from their system until this is resolved, in addition if you're a Linux user I would contact the package maintainer for your distribution as such a license may not be permitted.

Describe the bug To quote the 2.4.2 release notes:

If you’re using Audacity 2.4.2 on Linux, do use the right wxWidgets library. We’ve in the past had a lot of reports of problems on Linux that turned out in the end to be because some distributions were using system wxWidgets (3.0.0) with Audacity.

When considering the aforementioned quote in the context of the build instructions for Linux in regards to wxwidgets in linux/build.txt or in the wiki it becomes clear, that these requirements can never be met on Linux distributions due to the way that source tarballs of audacity are offered to its consumers, how the build system for audacity works and foremost due to the custom wxwidgets version in use.

In the reproducer section I have highlighted the reasons why Linux distributions will not build against your custom version of wxwidgets (rendering Audacity broken or at best unstable across the board). Even if a distribution such as Suse Tumbleweed has the resources to spend on building the development version of wxwidgets (i.e. currently 3.1.3) they will not build Audacity against your custom patched version as this causes loads of pain: This is either to patch your custom version of wxwidgets to be built and linked statically every time - and given the recent unannounced changes with the build system (#595) I deem such an endeavor rather time consuming - or to provide a custom package of your custom development version of wxwidgets to be linked dynamically - which will introduce conflicts with (future) existing packages of wxwidgets in that specific version. Both are very unlikely to happen as this requires a lot of time to be spend on just one package (Audacity is the only consumer of its custom wxwidgets version).

Without working on this angle, I don't see how problems such as #538 (I guess there are many more judging from the release notes) can be prevented in the future and personally, as a distribution packager I don't see myself in a position where I am obligated (or able) to a) fix any issues resulting from this and b) provide Audacity as a package if the workload due to distribution tickets related to the aforementioned issues increase unreasonably.

I would be interested to hear the developer's ideas in regards to reproducibility of the current approach in a packaging context, the possibility around linking statically (although that will not satisfy many distributions) by providing encompassing source tarballs and what drove the decision making process in regards to patching the development version of wxwidgets.

To Reproduce Steps to reproduce the behavior:

1. Download tarball for Audacity 2.4.2
2. Build against stable wxwidgets (i.e. currently 3.0.5)
3. Have unstable package

Alternatively:

1. Download tarball for Audacity 2.4.2
2. Clone https://github.com/audacity/wxWidgets
3. Build an unreproducible version of a custom wxwidgets from HEAD of whatever is the current default branch (ouch!)
4. Install an unreproducible version of a custom wxwidgets into the build environment and build audacity against it (???)
5. Package Audacity with a custom (dynamically linked) wxwidgets version (???)

Alter-alternatively:

1. Clone https://github.com/audacity/wxWidgets
2. Build an unreproducible version of a custom wxwidgets from HEAD of whatever is the current default branch (ouch!)
3. Package an unreproducible version of a custom wxwidgets development release, that will only be used for Audacity (ouch!)
4. Install unreproducible package of a custom wxwidgets development release (which will then conflict with a future wxwidgets 3.1.x package in the case that distributions switch - currently there are not many distributions even going for 3.1.x though)
5. Download tarball for Audacity 2.4.2
6. Build Audacity against the custom unreproducible wxwidgets development package
7. Have stable package (???)

Expected behavior

• Audacity can be built against a stable version of wxwidgets without side-effects

Alternatively:

• Audacity can be built against a development version of wxwidgets without side-effects (downside: distributions need to package a development version, of which Audacity might be the only consumer)

Alter-Alternatively:

• Audacity source tarballs with all relevant custom sources (this includes the latest stable release of the custom and patched wxwidets) are offered to consumers that need to build from source
• Audacity may be built against its custom wxWidgets version (statically linked) from one source tarball (note: this will still be a big no-no for most Linux distributions, see Fedora's take on this topic)

Screenshots n/a

Additional information (please complete the following information):

• OS: Arch Linux
• Version: 2.4.2

Additional context Upstream wxWidgets clearly marks 3.0.5 as the stable release and 3.1.3 as a development release. This means Audacity makes use of a patched development release (so not even a vanilla development release).

Currently, Audacity vendors (manually copies the code of) every dependency. This is widely considered a bad practice to be avoided as much as possible. It increases the work to maintain Audacity and exposes its users to security vulnerabilities, which has in fact occurred for years. It violates Linux distributions' packaging policies which makes it unusually difficult to package Audacity compared to other software. Additionally, Audacity has forked (modified the code of) many of these dependencies, including its biggest dependency, wxWidgets (#625), which amplifies the problem.

How do we move forward from here? As a first step, I suggest auditing every one of Audacity's dependencies and updating them to the newest compatible version before changing how dependencies are handled, then make a release which focuses on updating those dependencies. Considering the Audacity maintainers are intent on introducing networking capabilities which will require an external library, I suggest as a second step to use the introduction of those external libraries as an opportunity to start introducing a better way of managing cross-platform dependencies.

I suggest using the vcpkg package manager for Audacity's dependencies. It is cross platform with Windows, macOS, and Linux all supported. This makes it quite convenient for developers to maintain because they can work on vcpkg packaging from any OS and test builds locally, provided that the dependency's build system is cross platform (CMake or Meson). vcpkg is well maintained by Microsoft with a very strong contributor base, currently at 1202 contributors. Microsoft intends to ship vcpkg in Visual Studio and VSCode soon which will make it easy for Windows developers to help maintain Audacity's dependencies.

@Holzhaus and I recently spent a month setting up vcpkg for Mixxx's Windows dependencies. Audacity and Mixxx share many dependencies so many of Audacity's dependencies are already packaged in vcpkg. The notable exception is PortMidi, which has been unmaintained for many years. It builds with vcpkg on Windows, but not on macOS or Linux currently. PortMidi uses a very old CMake build system that I was unable to debug without a lot of effort. Do official Audacity builds use PortMidi or is it an old unmaintained feature? I would be glad to collaborate on resolving this to get PortMidi packaged for vcpkg on macOS and Linux, which I was already planning to work on for Mixxx 2.4. I suggest either Audacity or Mixxx fork PortMidi and host a new upstream repository. Then we could write a new build system for it with modern CMake, which would hopefully be easy to package with vcpkg on macOS, Linux, and Windows.

For our setup for Mixxx, we maintain a fork of Microsoft's upstream vcpkg repository. Using vcpkg's overlay feature, we are able to easily vendor a few specific dependencies while keeping all other dependencies up to date easily. We use a GitHub Actions workflow to build all of Mixxx's dependencies. That uses vcpkg archive to package all the built dependencies in one big ZIP archive which is scp'ed to https://downloads.mixxx.org/dependencies/. This ZIP archive is downloaded and cached in the GitHub Actions workflow for the application code repository. I tried using vcpkg's binary caching feature with Azure Artifacts. However, this only works if build environment for the application build is exactly the same as the dependency build, so Windows developers building locally would have to rebuild the entire dependency graph from scratch, which for Mixxx takes about 4 hours on GitHub Actions. Using the ZIP archive from vcpkg archive avoids this issue.

Resolves: #3102 Resolves: #3366 Resolves: #3367

This PR makes setting dialogs to be non modal, so Audacity interface can be interactive while the dialog is open.

Key points:

1. One dialog can be opened per one effect instance:
   1. Dialog is closed when the effect instance is removed
   2. Dialog is closed when the track is removed
   3. Dialog survives "destructive" operations on the track, such as recording, using generators and applying destructive effects
   4. Dialog title reflects the name of a track
   5. Dialog title does not (yet) reflect the effect placement inside the stack or any additional parameters (for example - Ardour shows like Track 1: Distortion [VST3]). Current design currently lacks this features (@Tantacrul @LWinterberg FYI)
2. This PR does not address #3090. Apply behavior is left as is, as it will be removed as a part of #3090
3. Changing effect parameters is not reflected in the Undo Stack. This should be a separate task, and it should be a responsibility of each individual effect subclass to implement such functionality: we need to reflect the changed parameter in the undo text, like "Undo Change Gain". It has been agreed that this can be solved outside the Audacity 3.2 scope. For reference - Garage Band and Motu Performer offer no such functionality and it is unreliable in Ableton.

• [x] I signed CLA
• [x] The title of the pull request describes an issue it addresses
• [x] If changes are extensive, then there is a sequence of easily reviewable commits
• [x] Each commit's message describes its purpose and effects
• [x] There are no behavior changes unnecessary for the stated purpose of the PR

Recommended:

• [x] Each commit compiles and runs on my machine without known undesirable changes of behavior

Resolves: #2717

(short description of the changes and the motivation to make the changes)

• [x] I signed CLA
• [x] The title of the pull request describes an issue it addresses
• [x] If changes are extensive, then there is a sequence of easily reviewable commits
• [x] Each commit's message describes its purpose and effects
• [x] There are no behavior changes unnecessary for the stated purpose of the PR

Recommended:

• [x] Each commit compiles and runs on my machine without known undesirable changes of behavior

Your idea

Restore the Cut, Copy and Paste buttons as a new toolbar that would be

a) hidden by default to keep the revised 3.2 GUI clean

b) available for users to make visible in the upper tooldock with the View>Toolbars command

Oversize mockup

In situ mockup

Some users are already complaining about the loss of these buttons on the Forum: https://forum.audacityteam.org/viewtopic.php?f=46&t=127074&p=456464 and this is causing some of them to revert to older versions of Audacity just to get the buttons back (which is not ideal)

Problem to be solved

1. some users are complaining about the removal of the Cut, Copy and Past buttons ffrom the Edit toolbar

2. some of those users are thus choosing to revert to older versions of Audacity, just to get the buttons back

Prior art

Microsoft apps that I use have such buttons (in addition to the "standard" shortcuts) - e.g.:

1. Microsoft Office: Word and Excel
2. Microsoft Paint

Additional context

See Forum threads regarding the loss of these buttons: (Audacity 3.2.0) Please Bring Back Cut, Copy, & Paste Buttons] https://forum.audacityteam.org/viewtopic.php?f=70&t=127081#p456403)#

And: audacity old version download https://forum.audacityteam.org/viewtopic.php?f=46&t=127074

Both the Audacity website as well as Muse Group's website states that Muse Group has acquired Audacity. However, hardly any details have been given. The information given on the Wikipedia page on Muse Group is also vague and questionable at best. All we have to work with is this quote from Tantacrul's video:

Audacity has just joined Muse Group, a collection of brands that includes another popular open source music app called MuseScore, which I’m currently in charge of.

This raises several important questions. To name a few:

• Is it even possible for a company to acquire a free and open source project licensed under the GPL?
• How exactly did Muse Group acquire Audacity?
• What rights and power does Muse Group legally have over the Audacity project?
• Can Muse Group even legally claim ownership over the project or do they simply own the trademarks to the name and logo?
• Who exactly is behind Muse Group; what roles do these people have?
• What are Muse Group's visions and goals for Audacity?
• How does Muse Group plan on going about putting these goals and visions into practice?
• How does Muse Group plan on handling situations where they want a new feature but the community rejects it (see PR 835)?
• Are any of the core maintainers and team members of Audacity now on the pay roll of Muse Group?
• What is the project father's and core maintainer's role and view of these events?

Describe the bug a) The slider setting value for AAC/MP4 export is not honored by Audacity.

b) Plus it is very hard (perhaps impossble) to set precise values - I found it impossible to set it to the "standard" rates of 192kbps and 256kbps

To Reproduce Steps to reproduce the behavior:

1. Get some stereo audio
2. File > Export > Export Audio
3. choose M4A(AAC) Files FFmpeg
4. Set the Quality slider to 320kbps
5. Click "Save" to make the export
6. Examine the file (on W10 I used Windows Explorer)
7. Observe the file is not 320kbps (mine was 465kbps YMMV)

Expected behavior a) Audacity should export at the rate the user selects b) The slider should allow for more precise setting (making it wider may help_ c) the user should be able to set a precise kbps value by typing it in (cf. MP3 export and mic/speaker sliders)

Screenshots None

Additional information (please complete the following information):

• OS: tested on Windows 10 - but assume all
• Version: Audacity 3.0.5 and 3.1.0

Additional context

1. Note that I am using the "recommended" FFmpeg the 64-bit Win downloaded from Buanzo's site This of course may change with an updated FFmpeg version ...

2. This does not happen with MP3 export in Audacity - the precise value is used for the exported file

3. Note that MP3 export uses a picking list and not a slider for the kbps setting - so we have an inconsistency issue here

4. The AACs that I have were made in iTunes,
   4.1) I export fro m Audacity as 16-bit WAV files 4.2) I import those WAV files into iTunes 4.3) I use iTunes to convert these WAVS to AAC files choosing 256kbps 4.4) I observe that iTunes converts these to 256kbps AAC files:

I made a post for this PR: https://forum.audacityteam.org/viewtopic.php?f=20&t=117875

Same content, but with code for generating the colormap: https://github.com/dofuuz/audacity-colormap

Dev checklist:

• If !mwState.expired(): Power button is visible, no buttons on the right
• Otherwise: No power button:
  • Apply is always shown
  • Preview is shown if mSupportsRealtime == true
• Presets & Settings is always shown

essentially a redesign of the existing play controls on plugins.

Note: In addition to what's shown in the images, there needs to be a play/stop button

Resolves:

Some dependencies that block some future module extractions are broken; to do that, more menu items are registered.

So this is mostly just boring cutting and pasting.

• [x] I signed CLA
• [x] The title of the pull request describes an issue it addresses
• [x] If changes are extensive, then there is a sequence of easily reviewable commits
• [x] Each commit's message describes its purpose and effects
• [x] There are no behavior changes unnecessary for the stated purpose of the PR

Recommended:

• [x] Each commit compiles and runs on my machine without known undesirable changes of behavior

Bug description

When audio is present in an Audacity project but no selection is made in the audio the the buttons and commands for Cut, Copy and Delete are erroneously black and active.

Using them is this state causes an error message to be displayed as they are basically non-functional in this state.

The Copy button appears to be always active/black - but its counterpart Edit>Copy command is grayed-out and inactive.

1) At Step 4

2) at Step 8

a) The Cut/Copy erroneous behavior is a regression on 2.2.0 b) the Paste behavior is a regression on 2.1.2 c) The Delete button is new to 3.3.0 alpha (see #4131 )- but is also erroneous in its behavior

Steps to reproduce

1. launch 3.3.0 alpha (3.2.3 does the same, but has no Delete button)
2. Observe: Cut, Copy and Delete buttons are grayed out and Paste button is black/active
3. Edit command
4. Observe: Cut, Copy and Delete commands are grayed out and Paste command is black/active - see image 1
5. Get some audio (or even a blank audio track with add new track) - make no selection
6. Observe: Cut, Copy, Delete and Paste buttons are black/active
7. Edit command
8. Observe: Cut, Copy, Delete and Paste commands (and Duplicate) are erroneously black/active (as there is nothing to act on) - see image 2

Note that this does not happen if at step 5 you add an empty label track to the empty project

Expected behavior

Buttons in the Cut/Copy/Paste toolbar and their associated commands in the Edit menu should be grayed-out and inactive where there is nothing to act on or work with.

@crsib Dmitry assures me that the buttons shadow and take their state from their associated Edit commands.

Actual behavior

See above

Audacity Version

3.3.0 latest alpha and 3.2.3

Operating system

Windows 10 - but suspect all OS

Additional context

@Tantacrul - this, I think, explains the differences in behavior you and I were observing with these buttons when testing the new Delete button.

Having these buttons and commands properly grayed-out and inactive would remove a lot of unnecessary error messages being shown to users ((the messages have to stay as the shortcut commands are always "available"):

See also: Add a Delete button to the Cut/Copy/Paste toolbar #4131

Your idea

NR default

The default settings in Audacity for Noise Reduction are 12, 6, 3

Suggested improved default

Greg Kozikowski (Koz), a long-standing Forum elf and ex Audacity Team member, often recommends 6, 6 ,6 as a better alternative

Problem to be solved

Koz is a professional sound engineer in Hollywood so I trust his recommendation in this regard very highly.

I have used Koz' settings many time to remove FM hiss from radio broadcasts and got excellent results.

Prior art

No response

Additional context

No response

Bug description

During the execution of an Audacity macro, some (valid) commands may be skipped without warning.

Steps to reproduce

1. Generate a tone
2. Apply 4 "splits" with approximately even spacing to create 5 audio clips
3. Apply this macro to the project:

CursTrackStart:
SelNextClip:
FadeOut:Use_Preset="<Current Settings>"
SelNextClip:
FadeOut:Use_Preset="<Current Settings>"
SelNextClip:
FadeOut:Use_Preset="<Current Settings>"
SelNextClip:
FadeOut:Use_Preset="<Current Settings>"
SelNextClip:
FadeOut:Use_Preset="<Current Settings>"

Expected behavior

Actual behavior

Sometimes it works,

Sometimes it doesn't. Observe that in this instance, some of the "SelNextClip:" commands have failed, causing the second clip to be processed 4 times instead of once.

Audacity Version

current master / alpha / nightly build

Operating system

Linux

Additional context

Problem also reported on Windows, so probably affects all platforms.

When testing on Audacity 2.4.2, the macro works 100% reliably.

Resolves: #4106

(short description of the changes and the motivation to make the changes)

• [x] I signed CLA
• [x] The title of the pull request describes an issue it addresses
• [x] If changes are extensive, then there is a sequence of easily reviewable commits
• [x] Each commit's message describes its purpose and effects
• [x] There are no behavior changes unnecessary for the stated purpose of the PR

Recommended:

• [x] Each commit compiles and runs on my machine without known undesirable changes of behavior

Bug description

There is a seperator line in the right click context menu of a track where there shouldn't be.

Steps to reproduce

1. Load a track up in Audacity
2. Right click the left on the track
3. Observe the erroneous line at the top of the menu

Expected behavior

There should not be this line at the top of the menu

Actual behavior

There is a line at the top of the menu

Audacity Version

latest stable version (from audacityteam.org/download)

Operating system

Windows

Additional context

No response