Audacity 4: Rebuilding an Audio Editor Without Losing Its Muscle Memory

Audacity 4 is not a coat of paint on a familiar waveform editor. The application interface has been rebuilt on Qt, clips have become objects that can be selected and manipulated directly, project files now use the .aup4 format, and several long-standing tools have been replaced by context-sensitive behavior.

That is an unusually large change for software whose greatest feature may be familiarity. Audacity succeeds because people can install it, record or open a file, make a precise change, and export the result without first adopting a production system. Its interface grew over decades around that directness. Replacing the foundation risks disturbing thousands of small habits even when every individual redesign looks sensible.

The important question is therefore not whether version 4 looks modern. It is whether a mature desktop application can change its internal and interaction architecture while keeping the short path from sound to finished file intact.

The interface migration is an architectural change

Audacity 3 used wxWidgets for its cross-platform user interface. Audacity 4 moves the interface to Qt and QML, building substantial parts on the same Muse Framework used by MuseScore Studio. The project’s build instructions now call for Qt 6, recommend Qt Creator for QML work, and explicitly note the MuseScore foundation.

This matters beyond rounded controls and dark mode. A UI toolkit determines how an application lays out windows, renders at different display densities, routes keyboard focus, exposes controls to accessibility tools, and separates visual state from domain logic. Moving toolkits changes the seams at which all of those behaviors meet.

The visible Qt/QML interface sits on a broader migration of application services and editing boundaries; the audio engine remains the workhorse below it.

Qt gives Audacity native high-DPI rendering, dockable and floating panels, saveable workspaces, and a consistent theming surface. The shipped Modern, Classic, and Music workspaces are more than presets. They acknowledge that one permanent layout cannot serve a quick voice edit, a multitrack music session, and a long-time user’s muscle memory equally well.

The Classic option is especially important. Compatibility in mature tools is not limited to opening old files. Users also carry a spatial map: transport controls live here, meters sit there, and a repeated task follows a known sequence. A workspace that restores familiar positions lowers migration cost without forcing the new interface to remain frozen in the old architecture.

There is a trade-off for contributors and downstream packagers. The new build has a broad Qt and Muse Framework dependency graph, and the official instructions say some inherited MuseScore dependencies have not yet been cleaned up. A richer application framework makes features such as docking, command routing, and reusable controls easier to build, but it also expands the surface that must compile and behave correctly across Windows, macOS, and Linux.

Clips are finally the unit of editing

The more consequential user-facing change is the clip model. In Audacity 4, a clip can be clicked directly, Shift-clicked into a multi-selection, grouped with other clips, moved between compatible mono and stereo tracks, trimmed, or time-stretched together with the rest of a selection.

This sounds ordinary because most timeline editors train users to see a clip as a thing. Earlier Audacity workflows often made the time selection primary: first mark a range on the waveform, then choose what operation applies to the audio under that range. Version 4 makes both concepts explicit. A time selection describes an interval; a clip selection identifies the objects an edit should affect.

That distinction resolves several awkward operations. Moving three non-adjacent clips no longer requires arranging them into a special contiguous state. Grouping gives a persistent relationship instead of asking the user to reconstruct the selection. Trim and stretch handles reveal which transformations belong to the selected object. Alignment guides and sample-boundary snapping make placement rules visible at the moment they matter.

The new freedom also needs a clear collision rule. Audacity now allows one clip to be moved over another; the moved clip replaces the overlapped part instead of refusing the operation. This is efficient once learned, but destructive-looking behavior deserves care. Users should know whether hidden material remains recoverable, which clip has priority, and how Undo restores the previous state.

Direct selection makes the clip the object of the command; context and collision rules decide how that command changes the timeline.

The release also turns splitting into an explicit gesture: hold or press S, then click the waveform or clip header. Related commands cover split-cut, split-delete, splitting at silences, and splitting to a new track. Paste can create a track when needed and adapt compatible channel layouts. These are small reductions in ceremony, but quick editors are built from exactly this kind of accumulated friction.

Context replaces the old tool switch

Audacity’s separate Select, Envelope, Draw, and Multi-tool modes are gone. Their functions now emerge from context.

Zoom to individual samples and drawing becomes available. Show clip gain and the envelope appears as a visual layer. Hold S and a click becomes a split. Click a clip header and the clip becomes the target. The interface asks the pointer position, zoom level, visible layer, and modifier keys to determine what the user intends.

This reduces mode errors—the familiar experience of dragging while the wrong tool is active—but it can introduce discoverability errors. A toolbar announces the tools it contains. Context-sensitive behavior is quieter. It works beautifully after it becomes habit and can be invisible before that point.

Good contextual interfaces therefore need strong feedback. Cursors must change before the click. Handles must appear on selection. Sample points must become visibly editable at the required zoom. Shortcut hints and transition documentation must make hidden capabilities searchable. Audacity’s 3-to-4 transition guide performs part of that job by mapping old modes to new gestures rather than simply listing features.

The removal of Sync-Lock follows the same philosophy. Instead of keeping a persistent special mode, delete, cut, and paste have explicit variants for either leaving a gap or moving later material to preserve timing. The decision moves closer to the operation that needs it. That is easier to reason about locally, although users who relied on a project-wide Sync-Lock state must relearn the commands.

Realtime effects change the cost of experimentation

Audacity still supports destructive effects: select audio, apply the effect, and change the waveform. Version 4 also emphasizes realtime effect stacks on tracks and the master output. These effects are calculated during playback, remain adjustable, can be reordered, and are not written into the audio until export.

That changes editing from a sequence of commitments into a set of parameters. A noise treatment can be dialed back later. Compression can move before or after equalization. A master effect can shape the complete mix without rendering every source again.

The benefit is not merely Undo. Undo walks backward through history, potentially discarding later work. A realtime stack keeps the decision live in the current project state. The editor can revisit one parameter without rewinding unrelated edits.

The cost moves to playback. Realtime processing must finish each audio buffer before the device needs it. A large stack, expensive plugin, or small buffer can exhaust the timing budget and cause dropouts. Audacity must coordinate UI changes, project state, plugin hosting, meters, and the audio thread without allowing interface work to interrupt sound. The new track-header meters and consistent preset handling make this system easier to inspect, but the hard constraint remains: audio deadlines do not wait for the UI.

Supported plugin boundaries also changed. The 4.0 release notes list VST3, Nyquist, LV2 on Linux, and Audio Units on macOS, while the transition guide describes the formats currently available to users. The release explicitly says VAMP and LADSPA hosting, along with some analyzers and effects, are not yet present. Anyone whose workflow depends on a particular plugin should verify it before converting an active project.

Playback and recording become timeline-native

The playhead now remains visible during navigation and can be dragged. Playback can seek without stopping. Recording can begin at any point on the timeline and creates a clip there. Loop boundaries and selections have been revised so these different ranges are easier to control independently.

These changes make transport behave more like editing. The timeline is not just a picture underneath play and record buttons; it is the shared coordinate system for navigation, loops, selections, clips, and new recordings.

Audio Setup has also been rebuilt around real device behavior. It can show system-default devices, refresh lists, map channels, and follow operating-system device changes. Official Windows builds now include ASIO playback and recording. For users with compatible interfaces, that can mean lower-latency and multichannel access without compiling a custom build.

None of this removes the need to test a real setup. Audio applications sit at the meeting point of drivers, permissions, sample rates, channel layouts, plugins, and hardware clocks. A release note can promise that the path exists; only a rehearsal proves that a particular microphone, interface, and monitoring arrangement works together.

.aup4 draws a one-way project boundary

Audacity 4 saves projects as .aup4. It opens .aup3 projects and converts them without changing the original, and it can import still older .aup projects. The converted work cannot be saved back to .aup3.

That one-way boundary is the correct place to be conservative. A project file is not an exported WAV or MP3. It contains editable structure: tracks, clips, hidden trimmed audio, effect configuration, appearance data, preview thumbnails, and undo-related state. Saving a new model into an old schema would either lose information silently or require the old application to understand concepts it never had.

The safe migration workflow is simple:

1. Keep the original .aup3 file and its backups.
2. Open a copy in Audacity 4 and save the converted .aup4 project under a new name.
3. Check clip positions, envelopes, effects, labels, sample rate, and project duration.
4. Export a reference mix and compare it with the version produced by Audacity 3.
5. Convert important projects before uninstalling the older application.

The official saving guide says an .aup4 file holds the editable project and distinguishes that from exported audio. That distinction is easy to overlook. An export is the deliverable; the project is the machinery required to change it. Migration testing must cover both.

A major release includes deliberate gaps

Audacity 4.0 does not pretend to be a strict superset of Audacity 3. The release notes identify Time Tracks, note/MIDI tracks, the Mixer, Macro Manager and scripting pipe, VAMP and LADSPA hosting, and play-at-speed as unavailable at launch. Sync-Lock and the old tool modes are intentionally replaced rather than scheduled for restoration. Some export, rendering, analysis, and effect features are also missing.

This is the uncomfortable arithmetic of a foundation rewrite. Waiting for perfect parity keeps the new architecture away from real workloads; releasing earlier gives users the architecture while asking some of them to remain on version 3. The honest approach is a visible compatibility list and a reversible trial.

For a quick two-track edit, version 4’s direct clips and cleaner interface may make the decision easy. For a scripted production pipeline that drives the old command pipe, the missing Macro Manager can be a blocker. For an accessibility-dependent workflow, the relevant question is not visual polish but whether keyboard navigation, focus order, screen-reader labels, and high-contrast behavior work for the exact task.

Version numbers do not decide those cases. Workflows do.

How to evaluate the upgrade

Treat Audacity 4 as a new editing environment that can import old work, not as an invisible point update.

Start with a disposable project representative of what you actually do. Record through the real device. Move and overlap clips. Exercise ripple-style deletion. Load the effects and plugins you depend on. Save, close, recover, reopen, and export. Test keyboard-only operation if shortcuts matter. If collaboration depends on project exchange, make sure every participant understands that .aup4 cannot return to version 3.

Then separate three kinds of compatibility:

• Data compatibility: Does the old project convert with the expected structure and sound?
• Workflow compatibility: Can you complete the job without a missing tool or automation path?
• Operational compatibility: Do devices, plugins, latency, stability, packaging, and accessibility meet production needs?

Audacity 4’s achievement is not that all three answers are automatically yes. It is that the project has established a new platform on which those answers can improve: a modern UI stack, clearer editing objects, explicit command routing, flexible workspaces, realtime processing, and a project format able to carry the new state.

The release preserves Audacity’s essential proposition. Audio stays editable on the user’s machine, the waveform remains the center of the work, and the shortest useful path is still open, edit, export. Almost everything around that path has been rebuilt. The next test is whether the new foundation can remain as approachable as the old one while becoming easier to extend for the decade ahead.

Further reading

• Audacity 4.0 release notes, the complete feature and compatibility list.
• Audacity 3 to 4 transition guide, a workflow map for existing users.
• Building Audacity, the Qt, QML, CMake, and Muse Framework development setup.
• Save your project, the distinction between editable .aup4 projects and exported audio.
• Audacity source repository, for code, issues, and contribution guidance.