xtc/docs/ROADMAP.md

# Roadmap

## Phase 0 — Baseline
Inspect repository/toolchain, verify Makefile and minimal executable, document
dependencies. No system changes without permission.

Baseline implementation: headless startup/shutdown executable, core tests,
separate debug build, optional FLTK shell build, and header dependencies.
See [BUILD.md](BUILD.md) for toolchain, commands, licensing and limitations.

## Phase 1 — C core and offline processing
Graph data structures, validation, cycle detection, topological ordering,
preallocated buffers, test oscillator, gain and offline render tests.

Implemented: mono ports, transactional cycle rejection, independent compiled
plans, precomputed input routing, oscillator/gain/meter/output, deterministic
variable-block tests and lifecycle/error coverage. See AUDIO_ENGINE.md for API
limits and compatibility behavior.

## Phase 2 — Real-time backend
Choose and implement a Linux backend. Document callback semantics, start/stop,
device errors, shutdown, and safe graph publication.

Implemented: optional JACK-compatible mono backend, explicit audio port routing,
format/xrun/loss status, start/stop/reopen, and bounded pending/retired plan
handoff using lock-free atomics. Hardware-independent failure/concurrency tests
and a 30-second software-loopback run pass. See decision 0004 and AUDIO_ENGINE.md.
Physical hardware playback/endurance and live server-loss recovery remain
unverified; GUI engine controls are implemented in Phase 3.

## Phase 3 — FLTK shell
Main window, transport controls, view switching, backend status, clean startup
and shutdown through the C API.

Implemented: dark FLTK shell, Play/Stop/Reconnect, view/menu shortcuts, backend
state/format/xrun/process status, persistent command errors, timer-based refresh
and retirement collection, and callback-safe close/retry. Mock-backend GUI tests
and live GUI/JACK start/stop/reconnect/close tests pass under Xvfb. Sequencer,
mixer and project-file actions remain placeholders; initial graph is silent. See GUI.md.

## Phase 4 — Modular editor
Draw nodes/ports/edges; create, move and connect nodes; reject invalid edges;
safely submit edits to the C core.

Implemented: scrollable node/port/wire canvas; add/select/move/delete nodes;
drag connections, select/delete wires, and show invalid-edit feedback. C owns
stable IDs, read-only snapshots and transactional edits. Exact accepted graph
snapshots are submitted to the backend; prepared/queued/active state is exposed
through revision acknowledgements. Core/render, GUI rollback, mouse smoke and
live adoption tests pass. See GUI.md and AUDIO_ENGINE.md. Preset parameters,
mono-only processing, fixed canvas and no persistence/undo/zoom remain limits.

## Phase 5 — Project and sequencer
Versioned persistence, stable IDs, tracks, clips, timeline, selection, zoom,
scrolling, and transport synchronization.

Implemented: bounded version-1 project persistence with transactional loads and
temporary-file/fsync/rename saves; stable track/clip/node IDs; silent regions;
track and region creation/deletion, selection, move/trim, timeline zoom/scroll;
sample-counted playhead, pause/resume and stopped seek. Project/graph arrangement
roundtrips, malformed-input, GUI rollback/gesture and live transport tests pass.
See PROJECT_FORMAT.md and GUI.md. Constant tempo/4/4, silent metadata regions,
no undo, asset playback, MIDI or persisted GUI layout are explicit limits.

## Phase 6 — Audio clips and recording
Audio import/playback, recording through bounded buffers, missing-asset
handling, no file I/O in callbacks.

Implemented: bounded PCM16/24/32 and float32 WAV import (mono/stereo downmix),
preloaded overlap-summed clip plans with linear rate conversion, and an audio
source node using ordinary graph routing. A lock-free SPSC ring transfers JACK
input to a control-thread WAV writer; Stop finalizes and adds successful takes.
Version 2 metadata stores external asset references and reads v1. Missing assets
remain silent with reporting and manual relinking. Core, callback, GUI and live
software record/save/reopen/play acceptance tests pass. See AUDIO_FILES.md for
memory/format limits, overflow recovery and deferred physical-device validation.
No new dependency or callback I/O was introduced.

## Phase 7 — MIDI and instrument
MIDI input/events/clips, simple internal instrument, note-off/panic handling,
then a basic piano roll.

Implemented: bounded source-relative note events with stable IDs; sample-offset
JACK MIDI input; a velocity-scaled sine instrument and separate graph source;
panic, note-off, stop and seek handling; and a piano roll for drawing, moving,
resizing and deleting notes. Version 3 saves notes and reads v1/v2 projects.
Core, fault-injection, GUI and live software MIDI/save/reopen/play tests pass.
Acceptance uses drawn notes; MIDI recording and SMF import are deferred.
See MIDI.md for capacities, immediate note-off, routing and hardware limits.

## Phase 8 — Mixer and editing
Gain/pan, meters, mute/solo, automation, undo/redo, keyboard workflow.

Implemented: selectable per-track channel strips with gain/pan and mute/solo;
stereo graph/JACK output and output peak meters; editable gain/pan automation
lanes with sample interpolation; bounded 32-edit C snapshot undo/redo and mixer
keyboard controls. Format v4 persists mixing/automation and reads v1–v3.
Core, GUI rollback/gesture/history and live stereo software playback tests pass.
See MIXER.md for routing, mono compatibility, pan law, history behavior and limits.
Track inserts/sends, live fader adoption, MIDI capture, per-track meters and
advanced automation remain deferred. No project-file editing is needed for the
implemented composition/mixing workflow.

## Phase 9 — Extensibility and release
Native node API, evaluate plugin hosting, licensing review, packaging,
installation tests, performance and recovery tests.

Implemented: versioned native C processor lifecycle and graph source/effect API,
explicit instrument-buffer integration, example and error/retirement tests;
external-hosting evaluation (deferred); dependency/license review; deterministic
source/release targets; core/GUI staged install/uninstall and installed C/C++
consumer tests; headless version/help/metadata validation; offline performance
and process-crash/write-failure recovery tests. Source format stays v4, reading
v1–v3. See NATIVE_API.md, RELEASING.md, LINUX.md, LICENSES.md, PERFORMANCE.md and
RECOVERY.md. Native graphs remain session-only, with unsupported saves preserving
files. No stable binary plugin ABI, external host, system package, autosave or
physical-device/endurance qualification is claimed.

## Phase 10 — Engine Correctness and Reliability

**Goal:** Verify that the existing implementation behaves correctly under realistic workloads before adding more features.

### Tasks

- Audit graph compilation, topological ordering, port compatibility, and cycle detection.
- Test graph replacement while audio is running, including safe reclamation of old processing graphs.
- Verify that audio-thread operations are bounded and non-blocking.
- Test repeated initialization, start/stop cycles, device failures, shutdown, and partial initialization.
- Run AddressSanitizer, UndefinedBehaviorSanitizer, leak checks, and static analysis where available.
- Add regression tests for every bug discovered.
- Document known limitations and thread ownership for shared resources.

### Acceptance criteria

- Reproducible tests cover engine lifecycle, graph changes, error handling, and DSP output.
- No known critical real-time safety defects remain.
- Resource ownership and cleanup behavior are documented.

Implemented: graph/DSP and ownership audit; stereo source-alias correction with
exact-output regression tests; maximum-size reverse-order graph/cycle rollback;
allocation-failure sweeps and callback allocation/free guards; 2000 concurrent
native-plan replacements with control-thread destruction and balanced lifetimes;
repeatable ASan/UBSan/leak and Clang static-analysis targets. Core, no-JACK,
GUI/mock/live JACK, recovery and TSan publication/recorder tests pass. See
RELIABILITY.md for ownership, synchronization, bounded-work analysis, commands
and evidence. Physical-device/endurance validation and trusted native callback
behavior remain explicit limits; no critical realtime safety defect is known
within the documented contracts.

## Phase 11 — Complete Minimal Music-Making Workflow

**Goal:** Ensure a user can create, save, reopen, and play a small musical project without manually editing project files.

### Tasks

- Verify project creation, track creation, clip arrangement, routing, and transport as one integrated workflow.
- Ensure play, pause, stop, seek, and return-to-start behavior are consistent.
- Save, close, reopen, and continue editing projects.
- Provide useful defaults and actionable error messages.
- Keep the sequencer as the default workspace, with the modular graph available when needed.
- Test that GUI state and engine state remain synchronized.

### Acceptance criteria

- A user can create and reopen a small project and reproduce the same arrangement and routing.
- Common operations do not require manual project-file edits.
- Transport and GUI state remain consistent during normal playback and error conditions.

Implemented: explicit Pause/F7 and To start/Home controls, position-preserving
Stop compatibility, recording guards, sequencer selection on New/Open, first-use
composition/routing guidance, and GUI status refresh after failed installation.
A real GUI/backend workflow test creates MIDI and audio, arranges/routes, saves,
closes/destroys the window, reopens in a fresh window, compares exact stereo
rendering and stable clip/routing metadata, then plays/seeks/pauses/resumes,
continues editing with undo/redo and saves/reopens again. Mock failure tests and
live JACK/GUI/software MIDI tests pass. See WORKFLOW.md for instructions,
transport semantics, test commands and limits. External playback routing remains
explicit; physical-device listening and endurance remain unqualified.

## Phase 12 — Audio Quality and Transport Correctness

**Goal:** Make timing and audio output predictable and musically reliable.

### Tasks

- Define precise behavior for tempo and meter changes.
- Verify conversion between musical positions and sample positions without accumulated timing drift.
- Test clips and events that cross processing-block boundaries.
- Prevent clicks at clip boundaries and during playback start/stop where appropriate.
- Implement gain ramps and parameter smoothing where abrupt changes could create artifacts.
- Test silence, clipping, denormal values, channel layouts, and unusual supported buffer sizes.
- Document latency reporting and identify whether latency compensation is required by the current architecture.
- Add deterministic tests for sample-accurate event scheduling where supported.

### Acceptance criteria

- Automated tests verify timing conversions and expected sample output.
- Tests cover events and clips at block boundaries and tempo changes.
- Listening tests cover transitions, start/stop behavior, and representative projects.
- Known limitations involving latency and synchronization are documented.

Implemented: documented constant-tempo/fixed-4/4 snapshot policy; absolute timing
and sample-offset regression matrix; configurable audio/scheduled-note boundary
fades; single-owner gain ramps; GUI 5 ms start and asynchronous Pause/Stop fades
with control-thread acknowledgement/deactivation; finite/subnormal output policy;
exact endpoint, block-size, stereo, overload and failure/retry tests. Latency and
synchronization limits are documented in AUDIO_QUALITY.md. Normal/no-JACK,
sanitizer/static-analysis, TSan, GUI/workflow/live JACK and install checks pass.
`make quality-preview` generates matched listening WAVs. Human listening and
physical-device acceptance remain pending; immediate safety/recording/seek paths
and live graph swaps may still click. No tempo/meter map, latency compensation,
limiter or project-format change is claimed.

## Phase 13 — Recording and Recovery

**Goal:** Protect recorded material and handle recording failures predictably.

### Tasks

- Test long recordings and recording-buffer saturation.
- Handle disk-full conditions, write errors, interrupted recording, and unavailable destinations.
- Keep file I/O outside the real-time audio callback.
- Define and implement recovery or clear reporting for incomplete recordings.
- Make recording destinations and supported file formats explicit.
- Protect existing files from accidental overwrites.
- Test reopening projects when media files are missing, incomplete, or inaccessible.
- Ensure shutdown and project closure do not silently discard pending recorded data.

### Acceptance criteria

- Recording failures are reported clearly and do not cause unsafe audio-thread behavior.
- Valid recorded material is preserved whenever possible.
- Incomplete recordings and missing media are detected and explained.
- Recording and recovery behavior is covered by automated or repeatable integration tests.

Implemented: no-clobber recording destinations and race-safe publication;
explicit opt-in replacement API; retained failed temporaries and recovery-path
reporting; streaming `xtc-check --recover-recording TEMP NEW.wav` salvage;
quiescent destructor draining and exceptional-shutdown reporting. Virtual
30-minute recording, saturation/concurrency, destination races, disk-write
failure/prefix recovery, killed writers and missing/incomplete media tests pass.
See AUDIO_FILES.md and RECOVERY.md. Physical endurance, power-loss guarantees
and playback of assets above the existing preload limit remain unqualified.

## Phase 14 — Native Plugin, Instrument, and Effect Architecture

**Goal:** Provide a stable internal extension interface before hosting external plugins.

### Tasks

- Finalize the native C node API, including initialization, processing, reset, and destruction.
- Define parameter metadata, defaults, valid ranges, and automation behavior.
- Specify audio channel layouts and MIDI/event handling.
- Define node state serialization and restoration requirements.
- Establish rules for node creation, failure, reconfiguration, and destruction.
- Ensure the GUI uses documented public APIs rather than internal engine structures.
- Provide a small example instrument and effect implemented against the public interface.
- Document ABI/API compatibility expectations for native extensions.

### Acceptance criteria

- A developer can implement a small native instrument or effect using documented interfaces.
- Invalid parameters, unsupported layouts, and failed initialization are handled safely.
- Node state can be saved and restored where required.
- No C++ or FLTK types leak into the public C API.

Implemented: ABI 2 parameter-only C processor lifecycle with copied descriptors,
metadata/default/range validation, sample-offset parameter/MIDI ordering,
transactional portable configuration restoration, and public gain/instrument
examples. Lifecycle, invalid input, event ordering, in-place output, reset,
callback failure and state compatibility tests pass. See NATIVE_API.md. ABI 1
graph compatibility is retained; native graph persistence and opaque plugin
state are explicitly outside this parameter-only interface.

## Phase 15 — External Plugin Hosting

**Goal:** Add external plugin support only after the internal node lifecycle is reliable.

### Tasks

- Evaluate candidate plugin formats for licensing, dependencies, maintenance, and Linux support.
- Record the selected format and rationale in an architecture decision document.
- Implement plugin discovery and loading outside the real-time callback.
- Map plugin audio ports, parameters, MIDI/events, and channel layouts to the engine's node model.
- Support plugin state save/load and clear reporting for missing or incompatible plugins.
- Test plugins with different channel counts, parameter sets, and processing requirements.
- Define how plugin failures are reported and how the engine recovers.
- Document crash-isolation limitations; an in-process plugin must not be assumed safe merely because the host is safe.

### Acceptance criteria

- A small, documented set of compatible third-party plugins can be loaded, connected, saved, reopened, and played.
- Missing or incompatible plugins do not silently corrupt the project.
- Plugin loading and destruction do not occur in the real-time callback.
- The chosen format's dependencies and licensing are documented.

Implemented: bounded LADSPA 1.1 C host with explicit file/index discovery,
control-thread loading/lifecycle, mono source/effect graph mapping, independent
stereo instances, metadata/range checks and v5 identity/control persistence.
Public-API GUI load/configure commands support ordinary routing/save/reopen and
undo. Fixture/error/retirement/GUI tests and installed amp/inverter/sine acceptance
pass. See decision 0009, PLUGIN_HOSTING.md and LICENSES.md. MIDI, true multichannel
layouts, opaque state, editors, latency compensation and crash isolation are
unsupported; plugin realtime behavior and physical listening are unqualified.

## Phase 16 — Automation and Expressive Control

**Goal:** Make automation and MIDI control reliable, sample-timed, and usable.

### Tasks

- Support automation for common parameters such as volume, pan, instrument parameters, and effect parameters.
- Define interpolation modes and behavior at clip boundaries.
- Evaluate automation at the correct time and sample offsets for each processing block.
- Smooth parameter changes where needed to avoid zipper noise or audio artifacts.
- Add MIDI controller mapping where appropriate.
- Handle note-off, panic, seek, stop, project teardown, and device disconnect correctly.
- Define deterministic ordering for MIDI and automation events that occur at the same sample position.
- Test overlapping notes, repeated note-ons, and interrupted playback.

### Acceptance criteria

- Automation and MIDI control reproduce consistent results across repeated playback and project reloads.
- Held notes are released safely on stop, panic, seek, and relevant failure paths.
- Event ordering and interpolation behavior are documented and tested.

Implemented: persisted sample-evaluated LADSPA parameter lanes with linear/step
modes, range/discrete validation and public GUI editing; absolute automation
position through seek and plan handoff; fixed live CC7/10/64 mappings with volume/
pan ramps, sustain/retrigger safety, and exact block-partition regressions.
Existing track Gain/Pan lanes cover audio and scheduled instrument volume.
Format v6 migrates v1–v5. See CONTROL.md. MIDI capture/learn, pitch bend, new
instrument timbres and physical listening remain outside the supported scope.

## Phase 17 — Editing Workflow, Undo/Redo, and Usability

**Goal:** Make common editing tasks efficient and protect users from accidental changes.

### Tasks

- Make common operations undoable, including create, delete, move, trim, duplicate, and connect.
- Define undo behavior for recording and destructive operations.
- Add consistent keyboard shortcuts and context menus for frequently used actions.
- Implement predictable snapping, grid settings, zoom, scrolling, and selection behavior.
- Improve clip labels, track organization, and visual feedback.
- Make destructive actions difficult to trigger accidentally.
- Keep the GUI responsive while audio is running.
- Ensure undo/redo updates project state and the active engine graph consistently.
- Test keyboard focus and accessibility of essential controls where practical.

### Acceptance criteria

- Common editing workflows can be completed without unnecessary dialogs or manual workarounds.
- Undo/redo restores the intended project state and corresponding engine state.
- GUI operations do not block the real-time audio thread.
- Interaction behavior is documented and covered by relevant tests.

Implemented: transactional full-source clip duplication, clip/track names,
track ordering, configurable timeline snap, Ctrl+D/F2/Alt+arrow commands and a
context menu; kind/name clip labels and focus regressions. Snapshot/GUI tests
verify duplicate/rename/order undo/redo, source-note retention, capacity rollback
and existing graph/backend history behavior. Recording undo removes references,
never media. See WORKFLOW.md. Background loading, persisted UI layout and broad
screen-reader/accessibility qualification remain explicit limits.

## Phase 18 — Project Format, Compatibility, and Portability

**Goal:** Keep project files valid, recoverable, and maintainable over time.

### Tasks

- Version the project format and implement explicit migration logic when the format changes.
- Validate project data before constructing engine objects from it.
- Handle malformed files, unknown node types, missing assets, and unavailable plugins.
- Define project-folder behavior and reliable media path handling.
- Make saving robust against interrupted writes, for example by writing a temporary file and replacing the destination safely where supported.
- Test save/load round trips and migration from every format version that is supported.
- Keep the format documented and preferably human-inspectable.
- Avoid silently discarding unknown data during load/save unless the format policy explicitly requires it.

### Acceptance criteria

- Supported older projects load correctly or produce clear, actionable compatibility errors.
- Malformed project files do not crash the application or trigger unsafe allocations.
- Missing media and plugins are reported clearly.
- Save/load round trips and format migrations have automated tests.

Implemented: v7 folder-relative media persistence with absolute runtime references,
transactional resolution independent of launch cwd, Save As identity preservation,
and parent-directory fsync after atomic publication. Checked-in v1–v6 migrations
(including missing plugins), moved-folder exact playback, missing-media retention,
truncation/mutation and unknown-record/error tests pass. See PROJECT_FORMAT.md.
No media is copied/deleted automatically; absolute external/plugin dependencies,
path bounds, post-rename sync errors and physical power-loss limits are explicit.

## Phase 19 — Performance, Scalability, and Stress Testing

**Goal:** Measure performance and establish predictable behavior as projects grow.

### Tasks

- Create repeatable benchmarks for increasing node counts and audio channel counts.
- Measure processing time at supported sample rates and block sizes.
- Profile graph compilation separately from real-time audio processing.
- Identify unnecessary buffer copies, allocations, and redundant processing.
- Test large arrangements, many clips, automation events, and active meters.
- Define bounded processing limits and meaningful overload diagnostics.
- Test under CPU pressure and during frequent GUI redraws.
- Optimize only after profiling identifies a meaningful bottleneck.
- Record baseline benchmark results so regressions can be detected.

### Acceptance criteria

- Performance targets and test conditions are documented.
- Repeatable benchmarks cover representative small and large projects.
- Overload behavior is defined and does not cause unbounded work in the callback.
- Significant performance regressions can be detected through repeatable tests.

Implemented: 24-case node/channel/rate/block matrix with separate compilation
and warmed process timings, recorded machine/compiler baseline and opt-in
regression budgets; maximum track/clip/note/automation/meter capacity checks and
publication/GUI tests under CPU contention. Measurements justified skipping
unused live-controller processing; exact output tests remain passing. See
PERFORMANCE.md and performance-baseline.json for results, thresholds and overload
policy. Arbitrary plugin costs and physical realtime/endurance are unqualified.

## Phase 20 — Release Engineering, Packaging, and Maintenance

**Goal:** Make the application straightforward to build, install, use, diagnose, and maintain.

### Tasks

- Provide reproducible release builds and clean build instructions.
- Add Makefile targets for building, testing, installing, and uninstalling.
- Package the application and required resources for the initial supported Linux target.
- Review licenses and attribution for direct and bundled dependencies.
- Document supported audio backends, required system packages, and configuration.
- Add useful crash and error diagnostics without compromising real-time processing.
- Test fresh installations, upgrades, missing dependencies, and removal.
- Publish a basic user manual, developer documentation, and a known-limitations list.
- Define a release checklist and a policy for handling regressions and project-format compatibility.

### Acceptance criteria

- A person other than the primary developer can build or install the application using the documented steps.
- The installed application can complete the supported core workflow.
- Installation and removal are tested on the initial target environment.
- Dependencies, licensing, limitations, and troubleshooting steps are documented.
- A release can be reproduced from a clean checkout with recorded build instructions.

Implemented: normalized Linux binary/development archives with SHA-256/file/
ELF-dependency manifests, headless compiled-feature diagnostics, repeat-install
upgrade/repair and installed C/C++ save/reopen/render checks. Existing deterministic
source/release, no-dependency, sanitizer, staged uninstall and GUI/live tests are
retained. USER_MANUAL.md, KNOWN_LIMITATIONS.md and MAINTENANCE.md consolidate setup,
operation, licensing/diagnostics, release and regression policy. No public release
or distro registration is performed. Independent human installation/usability,
physical-device/endurance and listening acceptance remain pending and must be
completed before claiming production qualification.

## Phase 21 — Advanced MIDI and Composition

### Goal
Make MIDI composition expressive and efficient without turning the application into an unnecessarily complicated notation editor.

### Tasks
- Improve piano-roll editing for note creation, selection, movement, resizing, and deletion.
- Support configurable snap and grid resolution, including triplets where practical.
- Add velocity editing and editing for supported MIDI note properties.
- Support MIDI channel and note-range filtering where appropriate.
- Improve quantization, transposition, duplication, and pattern repetition.
- Ensure MIDI event ordering is deterministic, especially when note-off and note-on events share a timestamp.
- Define handling for overlapping notes, repeated notes, and malformed MIDI events.
- Add regression tests for MIDI editing and playback scheduling.

### Acceptance criteria
- Common MIDI editing tasks can be completed without manually editing project files.
- Editing preserves unrelated notes and event properties.
- MIDI scheduling remains deterministic at buffer boundaries and under transport changes.
- MIDI operations are covered by automated tests.

Implemented: transactional C filtered note transforms, nearest-grid quantization,
velocity/channel edits, transposition, bounded fresh-ID repetition and deletion;
piano-roll Notes menu, keyboard commands, configurable straight/triplet grids,
channel/pitch filtering and filtered-set selection. Existing mouse move/resize
and project undo/redo remain supported. Core and GUI regression tests demonstrate
property/other-clip preservation, rollback, undo/redo, adjacent/overlapping notes,
equal-offset caller ordering, exact block partitions and seek chase. See MIDI.md.
No format change, MIDI capture, SMF import, lasso selection or piano-roll zoom;
physical-device and listening validation remain pending.

Acceptance evidence:
- [x] Menu/keyboard/mouse commands edit notes without project-file editing.
- [x] Filtered batch tests preserve unmatched notes and unrelated properties.
- [x] Exact scheduling tests cover buffer boundaries and transport seeks.
- [x] Core composition and GUI undo/redo regressions exercise these operations.

## Phase 22 — Audio Clip Editing and Utility Operations

### Goal
Provide focused, non-destructive audio editing tools for arranging and preparing recorded or imported material.

### Tasks
- Support moving, trimming, splitting, duplicating, and deleting audio clips.
- Define clip-boundary behavior, including fades and source offsets.
- Add non-destructive clip gain and basic fade-in/fade-out controls.
- Support time-stretching and pitch-shifting only after selecting a suitable implementation and quality target; otherwise document them as future work.
- Ensure edits do not unexpectedly modify source audio files.
- Add waveform display caching that never blocks the audio thread.
- Test edits at project boundaries, source-file boundaries, and very short clip lengths.
- Document which operations are destructive and non-destructive.

### Acceptance criteria
- Basic clip editing is predictable and undoable.
- Source files remain unchanged unless a documented destructive operation is explicitly invoked.
- Clip boundaries do not produce unintended clicks from invalid offsets or discontinuities.
- Editing and waveform generation never perform blocking work in the real-time audio callback.

Implemented: transactional audio/silent-clip splitting with stable IDs and source
offsets; persisted linear clip gain and explicit in/out fades in v8 (v1–v7 migrate
to unity/no explicit fades); undoable sequencer menu/context/keyboard controls;
immutable bounded source-peak summaries shared across clips and drawn from
cached memory. Existing move/trim/duplicate/delete remain supported; very short
clip hit testing now matches drawing. See AUDIO_FILES.md and PROJECT_FORMAT.md.
Stretch/pitch processing and crossfades remain future work; waveform loading is
synchronous on the control thread, and physical listening remains pending.

Acceptance evidence:
- [x] Core/GUI regressions cover split/duplicate/delete and snapshot undo.
- [x] Exact byte comparison verifies source files survive all metadata edits.
- [x] Boundary tests cover invalid offsets, short tails, one-frame media, explicit
      fade endpoints, gain, block partitions, seeks and capacity rollback.
- [x] Waveform construction stays on control-thread paths; redraw reads cached
      peaks and audio rendering retains immutable/preloaded callback storage.

## Phase 23 — Modular Workflow and Routing Refinement

### Goal
Preserve the modular spirit of the application while making complex projects understandable and manageable.

### Tasks
- Refine graph and routing views so signal paths are easy to inspect.
- Make connections, disconnections, and invalid routing states clear.
- Provide useful names and visual distinctions for tracks, instruments, effects, buses, and I/O ports.
- Support track grouping or folders if the project model can represent them cleanly.
- Add routing presets or reusable track templates only if they do not complicate the core model.
- Define behavior for cycles and feedback paths; reject unsupported cycles explicitly.
- Make graph changes transactional so failed edits do not leave partially updated routing.
- Add tests for graph changes while playback is running.

### Acceptance criteria
- Users can inspect and understand a project's signal path.
- Invalid graph edits fail safely and leave the previous valid graph intact.
- Graph updates follow the documented real-time synchronization strategy.
- GUI routing concepts map cleanly to the public C engine API.

Implemented: cached public C routing analysis (edge counts, longest-path levels,
output reachability and external-input fallback); directional/highlighted wires,
role colors/labels, no-output badges, selection inspection and keyboard navigation;
scrollable signal-flow auto-layout and non-overlapping initial placement. Atomic
unity-gain wire insertion is one undoable C edit using existing node persistence.
Core and mock/live GUI tests cover rollback, complete plan adoption, cycles,
disconnect/restore and undo/redo. See ROUTING.md. Flat tracks/shared audio/MIDI
sources do not yet represent folders or per-track routing templates; these
conditional tasks are deferred. No format change, feedback processing, latency
compensation or physical listening qualification is claimed.

Acceptance evidence:
- [x] Direction/role labels, layout and public routing diagnostics expose paths.
- [x] Invalid/capacity/backend-failed commands retain the previous graph/plan.
- [x] Live JACK graph tests verify complete block-boundary plan adoption.
- [x] GUI routing analysis and edits use public C APIs; callback ownership is unchanged.

## Phase 24 — Mixing and Mastering Essentials

### Goal
Provide the essential mixing controls needed to finish a small or medium-sized project.

### Tasks
- Complete track and bus gain, pan, mute, solo, and metering behavior.
- Define how solo states affect buses, sends, and sidechains.
- Add peak meters with clear units and documented ballistics.
- Add master-bus monitoring and clipping indicators.
- Support routing to buses and auxiliary sends if the graph model supports them.
- Make gain staging explicit and avoid hidden or surprising level changes.
- Document meter tap points and whether values are pre-fader, post-fader, or post-effects.
- Test mute, solo, pan, gain, and routing interactions.

### Acceptance criteria
- [x] Mixer controls behave consistently across tracks, buses, and master output.
- [x] Meter readings correspond to documented signal points and units.
- [x] Solo and mute behavior is covered by automated tests.
- [x] No mixer operation introduces allocations, locks, or other prohibited work in the audio callback.

Implemented: one-level stereo mix buses with routing, shared gain/pan automation,
inclusive solo and mute precedence; coherent audio/MIDI track and bus peaks;
interval master peaks, dBFS ballistics and sticky clipping; v9 persistence reading
v1–v8. See MIXER.md for exact taps, gain staging and callback scratch bounds.
Independent per-track aux sends/sidechains and per-bus graph effects remain
conditional/deferred because graph sources still expose shared mixes.

Validation: warning-enabled core/GUI builds and unit/integration tests, bus and
backend fault tests, GUI plugin/workflow tests, software JACK GUI/audio/MIDI,
allocation-failure/callback-allocation guard, static analysis, installation and
package relocation, optional-dependency-free build, and core/GUI ASan+UBSan.
The live MIDI connection test required one retry after a JACK connection failure;
its full playback assertions passed on retry. GUI leak checks use the existing
fontconfig suppression; core checks are unsuppressed. Physical hardware,
human listening and extended high-density endurance remain unverified.

## Phase 25 — Plugin and Instrument Usability

### Goal
Make instruments and effects practical to use, manage, and diagnose in real projects.

### Tasks
- Improve plugin discovery, insertion, removal, replacement, and ordering.
- Show useful plugin identity and status information, including load failures.
- Define parameter metadata, ranges, defaults, units, and formatting.
- Support parameter reset and safe default values.
- Preserve plugin state across save/load where the plugin API supports it.
- Define behavior when a saved plugin is missing or incompatible.
- Manage plugin UI lifetime separately from engine object lifetime.
- Add tests for plugin lifecycle, state restoration, and failure paths.
- Document plugin API versioning and compatibility expectations.

### Acceptance criteria
- [x] Users can identify and manage loaded instruments and effects without editing configuration files.
- [x] Missing or incompatible plugins produce actionable diagnostics and do not silently corrupt projects.
- [x] Plugin state restoration is tested for supported plugin types.
- [x] The engine remains safe if plugin initialization or processing fails, within the documented failure model.

Implemented for the supported LADSPA 1.1 mono effects/audio sources: explicit
module descriptor browser, copied identity and control metadata, generic parameter
editor with validated Apply/Cancel and defaults reset, compatible-layout
replacement preserving node ID/wires, and atomic effect insertion on a selected
wire. Graph connections define order and existing deletion removes incident
wires. Edits integrate with undo/redo and compile before adoption. State uses
existing v9 parameter/automation records; missing/incompatible plugins retain the
current document and report recovery guidance. Native processor ABI 2 remains
unchanged. See PLUGIN_HOSTING.md and RECOVERY.md.

Validation: warning-enabled core/GUI builds; full unit/integration suite;
fixture and installed amp/inverter/sine plugin tests; actual chooser/editor GUI
tests; reset/cancel, insertion, replacement, removal and undo; layout/init/missing
module rollback; exact persisted rendering and noncommutative processing order;
callback allocation/module-lifetime guards, reliability and static analysis;
software JACK GUI/audio/MIDI and workflow; dependency-free build; installation
and package relocation; ASan/UBSan including generic-dialog lifetimes (existing
fontconfig leak suppression for GUI/system font allocations).

Qualification remains the documented in-process failure model: LADSPA cannot
signal run failure or contain crashes/hangs. No external editor, opaque state,
MIDI-capable plugin instrument, recursive scanner or new format was added.
Physical listening and arbitrary third-party plugin/endurance qualification
remain pending.

## Phase 26 — Automation and Control Mapping

### Goal
Enable repeatable changes to mix and instrument parameters over time, with clear timing and ownership rules.

### Tasks
- Define a common parameter identity and metadata model.
- Support automation lanes for a carefully selected set of parameters.
- Define interpolation modes and behavior at clip boundaries.
- Specify how automation interacts with live parameter changes and MIDI control.
- Add control mapping for selected external MIDI controllers if feasible.
- Schedule automation deterministically without allocating memory in the audio callback.
- Define behavior when a target parameter or plugin is missing.
- Test automation at buffer boundaries, during seeks, and across loop points.
- Document precedence rules for automation, controller input, and direct user changes.

### Acceptance criteria
- [x] Supported parameters can be automated and saved in a project.
- [x] Playback produces deterministic automation values for a given project and transport position.
- [x] Missing targets fail safely and are reported to the user.
- [x] Automation processing meets the engine's real-time safety requirements.

Implemented: common stable owner/parameter keys and copied metadata for
track/bus gain/pan, LADSPA input controls and live sine controller targets;
validated common static/lane edit APIs; per-point linear/hold mixer automation;
per-channel saved volume/pan/sustain CC bindings with explicit disable and reserved
panic controllers. GUI adds Interpolation and Audio/MIDI controller mapping;
edits participate in undo/redo. Project v10 reads v1–v9 with linear/default-map
migration. CONTROL.md documents target identity, clip boundaries, precedence,
missing-target handling, controller ramps and real-time ownership.

Validation: warning-enabled core/GUI builds and full tests; common metadata,
missing owner/port/module failures and retained state; exact step/ramp endpoints,
low-rate collisions, odd blocks, seeks and explicit backward wraps; default/
remapped/disabled/unmapped CCs and stereo pan, immutable maps after preparation;
GUI map/interpolation/save/Open/undo/redo and invalid-edit rollback; v1–v9
migration, v10 exact persistence and malformed records; fixture/installed plugin
tests, callback-allocation guards, reliability/static analysis, performance and
capacity tests; software JACK GUI/audio/MIDI and workflow; dependency-free build,
installation/package relocation, core/GUI ASan+UBSan (existing fontconfig leak
suppression only for GUI/system font allocations).

No loop transport, MIDI learn/capture, write/touch/latch modes, arbitrary MIDI
mapping to arranged faders/plugins, timbre parameter for the built-in sine or
opaque-plugin seek restoration is claimed. Live MIDI targets have reset-default
metadata and controller bindings, not timeline lanes. Physical controllers,
listening and extended third-party-plugin endurance remain unverified.

## Phase 27 — Editing Workflow, Undo/Redo, and Usability

### Goal
Make common editing actions quick, discoverable, and safe to reverse.

### Tasks
- Audit user-visible editing operations for undo/redo support.
- Implement command-based edits with explicit ownership and rollback behavior.
- Group related low-level changes into one meaningful undo step.
- Define undo behavior for operations affecting engine state or external files.
- Improve keyboard shortcuts, selection behavior, focus handling, and context menus.
- Use confirmation only for genuinely destructive or difficult-to-reverse actions.
- Provide clear feedback for long-running operations and failures.
- Add GUI tests or reproducible manual test procedures for critical workflows.
- Keep presentation logic out of the core C engine.

### Acceptance criteria
- [x] Documented editing operations have predictable undo/redo behavior.
- [x] Undo and redo restore the project model and relevant engine state consistently.
- [x] Failed operations do not leave partial changes behind.
- [x] Common tasks can be completed using documented keyboard and mouse interactions.

Implemented: operation-by-operation audit in EDITING.md; reserved history storage
before GUI command mutation/candidate publication, followed by allocation-free
snapshot capture; recording start creates no empty history entry and each
completed take is one undoable reference edit; unavailable main-menu history
steps disabled; surviving editor selections and open piano-roll context retained
on undo; piano-roll history shortcuts/context menu and pointer-targeted graph
context menus; input focus guards and synchronous busy feedback. Existing C
graph/batch note commands and snapshot history remain the model boundary; FLTK
presentation stays in C++. No project format change (v10 retained).

Validation: warning-enabled core/GUI builds and full tests; interposed allocation
failure for each history reservation and capture with all allocations disabled;
GUI history-reservation failure retains document, engine submission count and
redo; completed-take undo grouping retains WAV; selection/context-target tests;
existing grouped gestures/batches, candidate/backend rollback and save/reopen;
workflow/software JACK GUI integration, reliability/callback guards, Clang static
analysis, core/GUI ASan+UBSan, optional-dependency-free build, installation and
package relocation. GUI sanitizer runs retain the existing fontconfig-only leak
suppression. EDITING.md supplies a reproducible native manual procedure for
popup dismissal, text focus, large synchronous operations and recorded takes.

Native manual popup/focus/large-file usability checks, broad accessibility and
physical-device listening/endurance remain pending. History remains bounded and
session-only; selection/layout history, arbitrary command grouping, background
loading and destructive source-media editing are not supplied. Preparation
failure can stop/reset transport while retaining the old document/history.

## Phase 28 — Project Format, Compatibility, and Portability

### Goal
Make project files robust, diagnosable, and maintainable across application versions and supported systems.

### Tasks
- Version the project format and document its compatibility policy.
- Validate project input before applying it to the live engine.
- Handle missing media, plugins, and external dependencies with clear diagnostics.
- Define relative-path, absolute-path, and media-relocation behavior.
- Add safe migration routines for supported older versions.
- Preserve unknown optional fields where practical, or document when they cannot be preserved.
- Test malformed files, truncated files, oversized input, and invalid values.
- Make saves atomic where the platform permits, using a temporary file and replacement strategy.
- Document portability limits, including plugin and audio-backend dependencies.

### Acceptance criteria
- Invalid project files are rejected safely without partially replacing the current project.
- Save failures do not silently destroy the previous valid project file.
- Version incompatibilities and missing dependencies are clearly reported.
- Supported project versions have migration and regression tests.

### Implementation status
Completed: version-10 compatibility policy and v1–v10 fixture migration;
transactional diagnostic loading in the core and GUI; metadata-only dependency
inspection with explicit availability limits; relocation and unknown-field
policies; bounded-input and deterministic pre/post-rename save-failure coverage.
No format bump was needed. Linux/POSIX, plugin ABI/path and audio-backend limits
are documented in PROJECT_FORMAT.md and RECOVERY.md.

Validation: full core/GUI/plugin/JACK/workflow/recording/recovery tests, static
analysis, staged installation and binary packaging; minimal no-JACK/no-LADSPA
build and tests; ASan/UBSan core, reliability and recovery tests.

## Phase 29 — Performance, Scalability, and Stress Testing

### Goal
Establish measurable performance expectations and verify that larger projects remain stable.

### Tasks
- Define representative test projects and target buffer sizes.
- Measure audio callback duration, deadline misses, CPU use, memory use, and graph rebuild costs.
- Test projects with increasing numbers of tracks, graph nodes, connections, MIDI events, and automation points.
- Test long playback sessions and repeated start, stop, seek, and loop operations.
- Stress-test device changes, plugin failures, missing media, and project reloads.
- Use profiling to identify bottlenecks before introducing optimizations.
- Verify that the real-time callback does not allocate, block on mutexes, perform file I/O, or wait on GUI work.
- Document expected limits and known performance bottlenecks.
- Add sanitizers and static analysis to regular development builds where supported.

### Acceptance criteria
- Performance is measured against documented test cases, not subjective impressions alone.
- Stress tests can run repeatedly and produce reproducible results.
- No known real-time safety violation remains in the engine's own callback path.
- Performance regressions can be detected by repeatable tests or benchmark reports.

### Implementation status
Implemented with the existing graph/capacity/fault infrastructure plus Phase 29
project scaling matrices, CPU/RSS/deadline metrics, checked-in reports, virtual
endurance, repeated reload/device/plugin fault suites, wider host callback guards
and a combined development/sanitizer/static-analysis target. See PERFORMANCE.md
for exact workloads, profiling evidence and qualification limits.

Validation: normal core/GUI/JACK/plugin/recovery/recording suites, three-round
CPU-contention stress, 2.282-hour virtual playback, minimal build, ASan/UBSan,
static analysis and benchmark-gate regression tests passed. Project timing
comparison passed. Graph comparisons detect shared-host variation (including a
16-node mono/31-frame alert in a longer run); the prior baseline is retained and
this limitation is recorded rather than suppressing the gate. Hardware and
wall-clock endurance remain unqualified.

## Phase 30 — Release Engineering, Packaging, and Maintenance

### Goal
Turn the application into a maintainable release that users can build, install, run, and troubleshoot.

### Tasks
- Define supported operating systems, compiler versions, and audio backends.
- Document build dependencies and provide clear build and test commands.
- Add install and uninstall targets that respect `PREFIX` and standard directory variables.
- Provide appropriate package metadata and desktop integration where relevant.
- Verify installation paths for binaries, libraries, headers, resources, documentation, and example projects.
- Add version reporting and a concise diagnostic mode where useful.
- Prepare release notes, known limitations, and upgrade guidance.
- Test clean builds from a fresh checkout and installation into a staging directory.
- Define a release checklist covering tests, warnings, packaging, and project compatibility.
- Document how users can report reproducible bugs and how maintainers should triage them.

### Acceptance criteria
- A clean checkout can be built and tested using documented commands.
- Installation works with a configurable prefix and does not overwrite unrelated user files.
- The release includes documentation, known limitations, and a reproducible version identifier.
- The project has a repeatable process for preparing and validating releases.

### Implementation status
Completed: configurable standard install directories with one shared owned-file
inventory, staged file/symlink safety checks, installed metadata-only MIDI example
and all performance resources, source SHA-256 sidecars, release notes, upgrades,
support matrix and maintenance/triage guidance. Existing version/diagnostic modes,
desktop metadata and normalized source/binary packaging are retained.

Acceptance verified with warning-enabled core/GUI builds and tests; default and
custom-layout staged install/repair/uninstall with C/C++ consumers; minimal
no-JACK/no-FLTK/no-LADSPA build; two clean source-export release builds with
byte-identical binaries and repacks; and binary manifest/hash/relocation checks.
No public release, tag, version bump or system install is performed. Physical
qualification and the Phase 29 graph timing alert remain documented limitations.

## Phase 31 — CLAP, VST2 and VST3 Plugin Loading

### Goal
Load trusted Linux CLAP, VST2 and VST3 audio effects through the graph and GUI,
with explicit lifecycle, format compatibility and realtime ownership contracts.

### Tasks
- Review and pin redistributable ABI headers and license notices; keep C99 adapters.
- Add explicit format probing and compatible mono float32 effect initialization.
- Integrate processing, immutable plans, retirement and failure rollback.
- Share module entry lifetimes across overlapping instances; defer main-thread callbacks.
- Add format/stable identity metadata with v11 migration and missing-module retention.
- Generalize the GUI browser, insertion/replacement and identity presentation.
- Test original fixtures for all three ABIs, partial failure cleanup, callback safety,
  save/reopen, missing dependencies and GUI lifecycle.
- Document the initial default-configuration effect subset and unsupported extensions.

### Acceptance criteria
- Compatible fixtures for all three formats render exact expected audio in graphs.
- Failed loading/identity/layout/initialization retains the current project/plan.
- Loading and reclamation remain off the audio callback, with bounded host processing.
- Project files preserve identity and missing references without executing plugins.
- Core/GUI builds, regressions, sanitizers and release installation checks pass.

### Implementation status
Implemented in C99 with pinned permissive ABI headers, shared entry lifetimes,
CLAP main-thread scheduling, graph/GUI integration and v11 plugin identity.
Normal/minimal builds, core and GUI plugin fixtures, live JACK/workflow,
ASan/UBSan core and GUI checks, static analysis, staged installation and
source/binary release checks pass. Tests include activation/start/process and
restart errors, rejected layouts/identities, missing modules and retirement.
GUI leak checking retains only the existing Fontconfig suppression; core checks
use none. Only original ABI fixtures are qualified; arbitrary third-party plugins
and physical audio remain unverified. See PLUGIN_HOSTING.md and decision 0010.

The initial subset excludes instruments/events, editable modern parameters,
opaque state/custom editors, true stereo/multichannel and latency compensation.
These require separate future work; they are not claimed as implemented by loading.

---

## Phase 32 — MIDI Track Plugin Instruments

### Goal
Play CLAP, VST2 and VST3 synthesizer/instrument plugins from MIDI clips and live MIDI.

### Tasks and acceptance criteria
- [x] Discover and initialize compatible zero-input, mono float32, zero-latency instruments.
- [x] Bind independent instances to tracks; preserve built-in sine for unassigned tracks.
- [x] Deliver sample-offset notes and bounded event queues without callback allocations.
- [x] Apply track/bus mixing and provide an explicit saved live-MIDI target.
- [x] Handle discontinuity note chase, panic, teardown and failed preparation.
- [x] Save bindings in v12; migrate v1–v11 and retain missing module references.
- [x] Add GUI load/clear/live-target commands with undo and candidate preparation.
- [x] Test original fixtures for all three formats and document the supported subset.

### Implementation status
Implemented with track-owned prepared instances and 256-frame processing chunks.
Only original ABI fixtures are qualified; arbitrary third-party instruments and
physical MIDI/audio hardware remain unverified. Mono/default configuration only;
no custom editors, opaque state or modern parameter automation. Native-note CLAP
and VST3 carry notes only; CLAP MIDI and VST2 also receive live controllers.
Seeking retriggers held scheduled notes with fresh envelopes; plugin release tails
can remain after note-off/panic. See PLUGIN_HOSTING.md and decision 0011.

Validation: normal/minimal core and GUI builds, core/instrument/GUI fixtures,
JACK/workflow, reliability, ASan/UBSan core and GUI, static analysis, staged
installation, reproducible source releases and relocatable binary packages pass.

---

## Phase 33 — Flat Modern DAW Workspace

### Goal
Give xtc a clear, modern DAW presentation for creating tracks and arranging
music, with simple flat controls and no 3D styling or proprietary assets.

### Tasks and acceptance criteria
- [x] Introduce one shared dark palette, typography, flat controls and focus/selection accents.
- [x] Make track creation, import, instrument loading and MIDI editing visible in a persistent sidebar.
- [x] Create/select MIDI tracks with clips and audio tracks transactionally, with undo and failure rollback.
- [x] Organize transport, musical position/BPM, main editors, inspector and status in a resizable workspace.
- [x] Draw colored track headers, clear clip selection, bar/beat grids and actual MIDI note previews.
- [x] Preserve existing editing, mixer/automation, graph, plugin, recording and keyboard behavior.
- [x] Add an original multi-track example and document the workflow and retained limitations.
- [x] Verify GUI actions, minimum/large layouts, core regressions and release packaging.

### Implementation status
Implemented in the FLTK GUI without new dependencies, engine changes or a project
format change. Default workspace 1280 × 800; supported minimum 1220 × 720.
Track creation is a single undoable prepared-model edit. The transport and
sidebar inspector are read-only displays; existing editors retain their controls.
Original four-track example visually checked; GUI tests cover creation,
selection, rollback, undo/reopen and minimum/large window sizes. This phase
modernizes presentation and workflow; it does not claim commercial-DAW feature
parity or add docking, scanning or mixer channel-strip functionality.
See WORKSPACE.md for the workflow, tests and limits.

---

## Phase 34 — Grid, Clip Editing and Track Instrument Controls

### Goal
Expose common DAW editing actions directly in the flat workspace: selectable
snap, MIDI clip double-click, individual note velocity and track instruments.

### Tasks and acceptance criteria
- [x] Draw bar/beat/subdivision grid lines and expose a sequencer Snap dropdown.
- [x] Offer Off, straight, triplet, half-note and bar divisions; synchronize the existing snap menu.
- [x] Snap clip moves and both trim edges to absolute grid positions, including off-grid clips.
- [x] Open the selected MIDI clip's piano roll on left-button double-click without moving it.
- [x] Add a fixed velocity lane and selected-note slider with 1..127 validation and one undo step per edit.
- [x] Keep coincident chord notes individually editable and preserve timing/pitch/channel.
- [x] Add a dropdown to every non-bus track for built-in sine, project instruments and explicit plugin loading.
- [x] Preserve track identity through reorder, undo, clear and project reload; retain candidate failure rollback.
- [x] Keep controls flat, retain current project format and verify builds, GUI regressions and releases.

### Implementation status
Implemented in the C++ GUI over existing C model APIs. Snap preferences are
session UI state; note velocity and track instruments already persist in v12.
The project instrument list is built from existing assignments, with Load plugin
for other trusted binaries; automatic disk scanning is not introduced.
At low zoom the visual grid coarsens for readability while snap remains exact to
the selected tick division. Off uses pointer/model tick precision. MIDI velocity
is a performance value, not a per-note dB gain stage; third-party instrument
patches control its audible response. See WORKSPACE.md and MIDI.md.

---

## Phase 35 — Application Preferences and Sequencer Looping

### Goal
Persist application preferences in `~/.xtc.conf` and provide selectable sequencer loops.

### Tasks and acceptance criteria
- [x] Add a flat, tabbed Edit / Preferences dialog with Apply and Close.
- [x] Validate and atomically save all preference tabs as a private INI file; load at startup.
- [x] Expose audio, interface, editing, new-project, plugin-path and transport settings.
- [x] List plugin files from configurable CLAP, VST2, VST3 and LADSPA search paths without executing modules.
- [x] Select a snapped loop range by Shift-dragging the ruler or entering tick bounds.
- [x] Toggle looping and split audio processing at exact sample boundaries.
- [x] Preserve real-time constraints and reject recording with looping enabled.
- [x] Verify persistence, invalid input, GUI Apply/reload, backend wraps and existing regressions.

### Implementation status
Implemented without dependencies or a project format change. Application settings
are saved only with Apply; audio connection options take effect on Reconnect and
project defaults on New. Existing projects retain their musical data. Loop ranges
are global preferences, not project data. Enabled loops require at least 64 samples.
See [PREFERENCES.md](PREFERENCES.md) for configuration, workflow and limitations.

---

## Phase 36 — Studio Mixer Overview

### Goal
Show every track and bus as a studio-style channel strip with direct level,
pan, routing and metering controls in the flat workspace.

### Tasks and acceptance criteria
- [x] Replace the single-track control panel with a horizontally scrolling bank of all tracks and buses.
- [x] Provide vertical dB faders, flat pan knobs, mute/solo switches and output routing per strip.
- [x] Show simultaneous stereo track/bus meters and keep the master output monitor visible while scrolling.
- [x] Retain selected-track gain/pan automation, interpolation, keyboard control and Add bus.
- [x] Preserve stable track identity, undo/redo, persistence and failure rollback across strip edits.
- [x] Verify empty/full sessions, reorder/remove, minimum/large layouts and independent meters.
- [x] Refresh the view screenshots and document mixer controls and metering limits.
- [x] Build and run GUI/core, live JACK, sanitizer and release checks.

### Implementation status
Implemented in the C++ FLTK GUI using the existing C mixer and backend snapshot
APIs. No audio callback, project format or dependency changes. The fixed master
strip monitors graph output; it does not introduce a separate master gain stage.
Faders edit static gain and do not chase automation. See [MIXER.md](MIXER.md)
and the updated [screenshots](../screenshots/README.md).

---

## Phase 37 — Workspace Navigation and Direct Editing

### Goal
Reduce menu hunting and make the workspace useful for everyday project editing
with a direct transport, track inspector and searchable commands.

### Tasks and acceptance criteria
- [x] Add Ctrl+P command search with filtering, keyboard navigation, Enter and Escape.
- [x] Expose active menu actions through existing callbacks, without duplicating command implementations.
- [x] Make project BPM editable from the transport with validation, undo and failed-preparation rollback.
- [x] Replace the passive sidebar with a context-aware gain/pan/mute/solo inspector.
- [x] Preserve unfinished numeric input across timer refreshes and avoid no-op history edits.
- [x] Add a session summary, Fit song and optional Follow playhead navigation.
- [x] Persist Follow playhead through the existing Preferences / Apply workflow.
- [x] Test command selection/cancellation, inspector edits, tempo rollback/undo and navigation.
- [x] Refresh all screenshots, including a command-palette view, and document the workflow.

### Implementation status
Implemented over the existing C model, history and backend APIs, with no new
dependencies or project format change. Tempo edits stop and rewind transport;
track/clip and piano selections survive. Fit song uses the supported 24..384
pixels-per-beat zoom levels; very long projects still require scrolling.
The inspector targets the selected mixer channel in Mixer and the arrangement
track in other views. Command search lists active menu actions; it is not a
plugin scanner or a key-binding editor. See WORKSPACE.md.

### Future usability work
Independent track inserts and customizable shortcuts remain future work.
Dockable editors and pinned headers are implemented in Phase 46; arrangement
multiselection and phrase editing follow in Phases 47–51.

---

## Phase 38 — Internal instruments and effects

### Tasks and acceptance criteria

- [x] Add always-available Soft Keys and Sub Bass MIDI instrument presets.
- [x] Add Delay and Reverb with bounded controls and effect automation.
- [x] Integrate track selection, graph wire insertion, undo and saved projects.
- [x] Preserve older projects; reserve format 13 internal device identities.
- [x] Verify DSP tails, block partition consistency, note release/panic and persistence.
- [x] Refresh application screenshots and add internal device editor views.

### Implementation status

Implemented for the bounded initial device set. Audited 2026-11-05 against
`src/plugin/builtin.c`, the shared plugin host, track instrument selector,
graph commands and v13 persistence. Soft Keys and Sub Bass are fixed 32-voice
presets; Delay and Reverb each expose three bounded, automatable controls.
Preparation owns buffer allocation; processing uses preallocated storage.
Internal devices use virtual identities rather than loading external modules;
the reader retains v1–v12 compatibility. Actual device control screenshots are
listed in [screenshots/README.md](../screenshots/README.md).

`tests/unit/test_builtin.c` covers both effect tails and block partitions, dry
mix, invalid feedback, both instruments' release/panic, mix automation and a
keys/delay project round trip. Shared GUI tests cover instrument selection,
history and plugin editing, but do not constitute a dedicated end-to-end matrix
for all four internal devices. Additional qualification is tracked in Phase 40.

The initial subset lacked editable presets, pitch bend, sample instruments,
smooth/tempo-synced delay, stereo reverb, seek history policy and automatic tails.
These audit gaps are addressed by Phases 41–44 below. See
[BUILTIN_DEVICES.md](BUILTIN_DEVICES.md) for controls and explicit limitations.

---

## Phase 39 — Detachable transport and mixer

### Tasks and acceptance criteria

- [x] Float/dock the existing transport and mixer without duplicating state.
- [x] Keep BPM and loop settings in the shared transport controls.
- [x] Recover arrangement space and retain resizable mixer channels.
- [x] Support close-to-dock, Dock all, floating playback shortcuts and safe shutdown.
- [x] Exercise lifecycle, settings and resizing in GUI tests and capture floating views.

### Implementation status

Implemented for the transport and mixer. Audited 2026-11-05 against
`src/gui/main_window.cpp` and `tests/integration/test_gui.cpp`. Detaching
reparents the existing widgets on the GUI thread; BPM, loop settings and mixer
state remain shared. Docking restores ownership and arrangement space, and the
destructor docks panels before destroying their windows. Tests exercise repeated
detach/dock, close-to-dock, shared BPM/loop state, floating playback shortcuts,
main/floating resizing and failed/successful shutdown. Floating screenshots are
listed in [screenshots/README.md](../screenshots/README.md).

The original subset used session-only positions, a 1220-pixel transport and
only two detachable panels. Phases 45–46 add persisted geometry, a compact
transport and editor panels. Mixer minimum remains 600 × 420. See
[WORKSPACE.md](WORKSPACE.md) for usage and limits.

### Audit validation (Phases 38–39)

Warning-enabled `make BUILD_DIR=build/roadmap-audit all gui test` passed,
including `test-builtins`. Sequential GUI runs with the same build passed:
`test-gui`, `test-gui-instruments`, `test-gui-modern-plugins` and
`test-gui-plugins`. The initial parallel GUI invocation reported passing test
assertions but failed Xvfb cleanup; sequential reruns exited successfully.
Historical sanitizer/live-JACK evidence in WORKSPACE.md is separate from this
audit; sanitizers, live JACK and physical listening were not rerun here.

---

## Phase 40 — Internal Device Acceptance Coverage

### Goal
Close the dedicated validation gaps in the initial Phase 38 device set.

### Tasks and acceptance criteria
- [x] Exercise all four internal devices through GUI selection/addition, wire insertion where applicable, control editing, undo/redo and save/reopen.
- [x] Round-trip both instruments and both effects, including automated controls, and compare rendered output.
- [x] Verify older-format migration alongside v13 identities and reject malformed internal identities transactionally.
- [x] Test sustain, repeated notes, voice exhaustion, seek/stop/panic and instrument block partition consistency.
- [x] Cover preparation/allocation failures and callback allocation/free guards for internal devices.
- [x] Document repeatable manual listening checks for both presets and representative effect settings.

### Implementation status
Implemented: dedicated all-device GUI/history/persistence tests, exact persisted
render comparisons, malformed-identity rollback, voice/transport regressions and
allocation-failure/callback guards. Warning-enabled core tests, reliability, GUI
and listening-preview generation pass. See BUILTIN_DEVICES.md for repeatable
manual checks; human listening and physical hardware remain unverified.

---

## Phase 41 — Editable Internal Instruments and Presets

### Goal
Extend the fixed Soft Keys/Sub Bass presets into editable instruments.

### Tasks and acceptance criteria
- [x] Define bounded oscillator, envelope and filter controls with metadata and defaults that preserve existing preset sounds.
- [x] Provide instrument parameter editing, automation and reusable preset save/load through public C APIs.
- [x] Support channel pitch bend with a documented range and sustain/note lifecycle behavior.
- [x] Persist parameters and presets with explicit version migration, undo and failed-preparation rollback.
- [x] Verify sample timing, block partition consistency, bounds, aliasing behavior and callback safety.

### Implementation status
Implemented: five bounded oscillator/envelope/filter/bend controls, absolute-time
automation, instrument editor and reusable preset C APIs/GUI commands. Format 14
persists bindings and reads v1–v13, preserving legacy default sounds. Core,
reliability and GUI tests pass, including preset/migration, exact partition and
pitch-bend offset regressions. See BUILTIN_DEVICES.md and PROJECT_FORMAT.md.

---

## Phase 42 — Internal Sample Instrument

### Goal
Provide sample-based sounds beyond the current oscillator presets.

### Tasks and acceptance criteria
- [x] Define supported sample formats, mapping, looping, envelopes, voice limits and memory budgets.
- [x] Load/prepare samples outside callbacks and expose an instrument editor with undo.
- [x] Persist sample references and mappings with missing-media reporting and relinking.
- [x] Provide original or appropriately licensed example sounds and document their licenses.
- [x] Test playback rate conversion, boundaries, voice release, missing assets and project reload.

### Implementation status
Implemented: a 32-voice, single-root WAV sampler with whole-file looping,
envelopes, gain, cached linear rate conversion and an undoable editor/relink
workflow. Format 15 persists relocatable sample references and reads v1–v14.
Missing/invalid media becomes reported silence. Original licensed example and
core, GUI, persistence, release/loop and allocation/callback tests are included.
See BUILTIN_DEVICES.md for memory/format and transposition limits.

---

## Phase 43 — Smooth Delay and Stereo Reverb

### Goal
Address the documented sound-design and transition limits of the basic effects.

### Tasks and acceptance criteria
- [x] Smooth or crossfade delay-time changes and define automation behavior without abrupt read-head jumps.
- [x] Add tempo-synced delay divisions with deterministic tempo/seek behavior.
- [x] Add true stereo processing and reverb diffusion/room controls rather than independent mono instances alone.
- [x] Preserve old projects' effect identities, parameters and sound, or provide an explicit compatibility mode.
- [x] Test stability at parameter extremes, stereo response, automation partitions and transition artifacts; document listening results.

### Implementation status
Implemented as new Stereo Delay/Reverb identities, preserving original devices.
Delay uses fractional read-head crossfades and tempo divisions; reverb adds room
spacing and coupled stereo diffusion. Graph evaluation now processes coupled
channels together. Core, graph/direct DSP, partition, tempo, GUI persistence,
callback-guard and sanitizer tests pass. Listening previews/procedure are
documented; human listening is unverified. See BUILTIN_DEVICES.md.

---

## Phase 44 — Effect History and Tail Rendering

### Goal
Make discontinuities and effect tails explicit in playback and export.

### Tasks and acceptance criteria
- [x] Define retained/reset effect history for seek, stop, loop wrap and project/plan replacement.
- [x] Implement the chosen history policy without callback allocation or unsafe state sharing.
- [x] Add bounded automatic or user-configurable tail rendering after the arrangement/export endpoint.
- [x] Expose tail limits and cancellation, including silent input and non-decaying/high-feedback cases.
- [x] Test seek/loop reproducibility and complete delay/reverb tails across processing block sizes.

### Implementation status
Implemented: constant-cost internal history invalidation on discontinuity/stop,
plus incremental stereo WAV export with 0..60-second tails, progress/cancel and
no-clobber publication. Preferences optionally stop playback after the tail
(with GUI-timer/fade precision); loops/recording retain their existing behavior.
Core, reliability, export/direct partition, GUI and sanitizer checks pass.
External-plugin history remains retained. See BUILTIN_DEVICES.md for limits.

---

## Phase 45 — Persistent Panel Layouts and Compact Transport

### Goal
Retain useful floating layouts across sessions and support narrower displays.

### Tasks and acceptance criteria
- [x] Persist docked/floating state and panel geometry through the application preferences workflow.
- [x] Restore layouts safely when monitors or display sizes change; keep all panels reachable.
- [x] Provide a compact/responsive floating transport while retaining BPM, loop and playback controls.
- [x] Preserve close-to-dock, Dock all, shortcuts, editing focus protection and safe shutdown.
- [x] Test restart, invalid settings, off-screen geometry, narrow sizes and repeated dock/resize cycles.

### Implementation status
Implemented: validated panel preferences, geometry capture on Preferences/Apply,
safe display-area restoration and a wrapping floating transport down to 400
pixels. Core/settings and GUI tests pass, including restart, invalid geometry,
off-screen clamping, narrow control bounds and existing dock/lifecycle checks.
The full-window minimum is unchanged. See WORKSPACE.md and PREFERENCES.md.

---

## Phase 46 — Additional Dockable Editors

### Goal
Extend Phase 39's two-panel arrangement to a general editor workspace.

### Tasks and acceptance criteria
- [x] Define supported dock locations and layout ownership for sequencer, piano roll and modular graph panels.
- [x] Detach/dock each supported editor without duplicating project, selection or history state.
- [x] Support resizable pinned track headers and preserve editing coordinates, scrolling and focus after reparenting.
- [x] Integrate with Phase 45 layout persistence and provide a safe reset-layout action.
- [x] Verify minimum/large layouts, cross-panel editing, repeated reparenting and shutdown/error paths.

### Implementation status
Implemented: complete Sequencer/Graph panels and Piano Roll reparent between
floating windows and their main tabs, with shared model/history/selection and
preserved scroll positions. Validated preferences persist layouts; reset docks
panels and restores default rectangles. Arrangement headers/selectors stay pinned
and resize from 180 to 360 pixels. Supported docking is explicitly limited to
original tabs; arbitrary split layouts and drag docking are future extensions.
Core/settings, GUI lifecycle/editing/restart and integrated checks are recorded
below. See WORKSPACE.md and PREFERENCES.md.

---

### Integrated validation for Phases 40–46

Each phase was built and tested before its separate implementation commit.
Core/reliability tests cover devices, migration, persistence, DSP partitions,
transport history and export. GUI tests cover editing, shared state and panel
lifecycle; CLAP/VST2/VST3/LADSPA fixture and live software JACK suites retain the
existing workflows. Sanitizers cover built-in DSP/export and GUI lifetimes;
static analysis and staged installation check the final integrated changes.
Human listening, arbitrary third-party plugins and physical hardware remain
unqualified. Listening WAV generation and manual procedures are documented in
BUILTIN_DEVICES.md. Application project format is now 15, reading versions 1–14.

---

## Phase 47 — Arrangement Multi-selection

### Goal
Select clips across tracks with additive selection and Select all; preserve stable IDs across refresh and docking.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: additive Shift-click selection, Ctrl+A/Select all and selected clip outlines across tracks. Stable IDs survive refresh and panel reparenting. Core build/tests and GUI selection/docking tests pass.

---

## Phase 48 — Transactional Group Editing

### Goal
Move, duplicate and delete selected clips atomically, preserving relative positions and a single undo step.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: atomic C99 batch move/duplicate/delete APIs and GUI selection commands. One published edit preserves relative spacing, fresh duplicate IDs and single undo history entries. Core and GUI tests pass, including negative-position rollback and invalid selections.

---

## Phase 49 — Arrangement Clipboard

### Goal
Copy selected clips into an independent session clipboard and paste at the cursor with fresh IDs, notes and media references.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: independent control-thread clipboard snapshots, fresh-ID paste at the cursor and relative existing-track mapping. Notes, source trims, audio properties and references survive copying independently of later edits. Core rollback/lifetime and GUI copy/paste tests pass.

---

## Phase 50 — Repeat Arrangement Patterns

### Goal
Repeat a selected phrase by its complete bounding span with bounded copy counts and all-or-nothing capacity validation.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: bounded phrase repeat uses the complete selected bounding span, including gaps, with fresh clip/note IDs and atomic capacity/range validation. Core repeat/capacity tests and focused GUI phrase workflows pass.

---

## Phase 51 — Align and Slip Editing

### Goal
Align selected clip starts to the cursor and slip source offsets without moving timeline boundaries.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: selection-wide start alignment and source slip commands reuse atomic clip transactions. Clip start/length and source limits remain validated for audio and MIDI. Core late-failure rollback and focused GUI alignment/history tests pass.

---

## Phase 52 — MIDI Swing Quantization

### Goal
Apply bounded swing and quantize strength to source note starts with deterministic rounding and source-bound checks.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: deterministic nearest swung-grid quantization with 0..100 strength and source-range rollback through a C99 API and MIDI tools dialog. Core timing, strength and late-note rollback tests plus focused GUI/piano refresh tests pass.

---

## Phase 53 — MIDI Legato and Gate Tools

### Goal
Set note gates or extend notes to the next onset on the same channel, preserving IDs and validating all notes before publication.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: atomic gate scaling and same-channel legato over selected MIDI clip sources. Chords share the next distinct onset; final notes extend to source end. Core channel/chord/bounds rollback and GUI duration/refresh tests pass.

---

## Phase 54 — MIDI Scale Correction

### Goal
Snap notes to a chosen root and chromatic, major or minor scale with deterministic nearest-pitch ties.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: root-aware nearest-pitch correction to chromatic, major or natural minor scales, with lower-pitch ties and MIDI endpoint bounds. Core root/tie/endpoint/invalid-input and GUI pitch-refresh tests pass; note IDs and timing persist.

---

## Phase 55 — MIDI Velocity Shaping

### Goal
Apply bounded velocity scaling and offsets to selected MIDI clips, with explicit clipping to valid MIDI velocities.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: rounded velocity percentage and offset transforms with explicit 1..127 saturation. Core scale/offset/extreme/invalid-input and GUI velocity-refresh tests pass; timing, IDs, pitch and channel remain unchanged.

---

## Phase 56 — Batch Audio Fade Tools

### Goal
Apply symmetric boundary fades or remove fades on selected audio clips, preserving clip gain, media and timing.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: selection-wide symmetric boundary fade and remove-fade tools preserve gain, references and timing. Fade lengths must fit half every current clip duration; mixed MIDI selections reject atomically. Core late-failure/property tests, existing audio rendering tests and focused GUI fade workflows pass.

---

## Phase 57 — Mixer A/B Comparison

### Goal
Capture and recall two session mixer snapshots by stable track ID, with transactional validation, undo and explicit automation limitations.

### Tasks and acceptance criteria
- [x] Provide the control/model behavior and accessible GUI commands.
- [x] Validate bounds and failure rollback; preserve existing project compatibility and callback safety.
- [x] Test the new workflow and document scope and limitations.

### Implementation status
Implemented: two independent GUI mixer comparison slots and public C snapshot capture/recall. Recall validates the stable track ID set, tolerates reorder and creates one undoable edit; New/Open clears slots. Core rollback/reorder, GUI recall/undo/document lifecycle, allocation-failure, persistence/render, sanitizer, static-analysis and installation checks qualify the integrated work. See MODERN_EDITING.md for scope and validation.

---

### Integrated validation for Phases 47–57

Each phase has a separate implementation commit and warning-enabled model/GUI
checks. The final suite includes allocation-failure rollback and ID preservation,
clipboard track mapping, note/source bounds, grouped undo, persistence/render
comparison, the complete GUI/plugin fixture matrix and software JACK lifecycle.
ASan/UBSan, Clang analysis and both staged installation layouts cover integration.
Project format remains 15; no new dependencies or callback work were introduced.
See [MODERN_EDITING.md](MODERN_EDITING.md) for commands, scope and remaining DAW
features. Human listening, physical hardware and arbitrary third-party plugins
remain unqualified.

---

## Phase 58 — Persistent Arrangement Markers

### Goal
Store up to 128 named, tick-keyed markers with versioned migration, undoable GUI editing and ruler display.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: sorted tick-keyed markers, bounded UTF-8 names, undoable GUI editing and ruler display. Format 16 appends marker records and reads versions 1–15. Core, legacy migration, malformed-load rollback and focused GUI history/docking tests pass.

---

## Phase 59 — Section Navigation and Looping

### Goal
Navigate previous/next markers and loop the section between a marker and its successor or the song end.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: strict previous/next navigation and section queries, exposed through View commands. Navigation stops playback safely; section looping shares existing loop controls. Core boundaries/final-section and GUI navigation/loop tests pass.

---

## Phase 60 — Ripple Time Editing

### Goal
Insert or remove bounded timeline ranges atomically, shifting clips, markers and automation; reject clips crossing edit boundaries explicitly.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: atomic gap insertion/range removal shifts clips, markers and mixer/instrument/graph plugin automation. Crossing clips reject explicitly. Core position/automation/removal rollback tests and GUI edit/history checks pass.

---

## Phase 61 — Complete Track Duplication

### Goal
Duplicate a non-bus track with fresh IDs, clips, notes, mixer controls, routing, instrument settings and track automation in one transaction.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: complete non-bus track duplication with fresh IDs, adjacent ordering, source media/notes, instrument settings, mix, bus routing and automation. Core ownership/property checks and GUI undo tests pass.

---

## Phase 62 — Nondestructive MIDI Clip Splitting

### Goal
Split trimmed MIDI clips at the cursor while preserving source-relative note content and verifying boundary scheduling.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: trimmed MIDI splitting with fresh right-side clip/note IDs and complete retained source notes. Original sine rendering is identical across the split in regression tests; MIDI instruments may retrigger at boundaries. Core range/render and GUI split/undo tests pass.

---

## Phase 63 — MIDI Clip Consolidation

### Goal
Merge selected MIDI clips on one track into a fresh source, retaining audible notes and gaps with explicit boundary clipping and rollback.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: transactional consolidation of selected same-track MIDI clips into a fresh source. Visible note intersections are cropped, hidden notes dropped and gaps/overlaps retained. Core trim/timing/ID checks and GUI merge/undo tests pass.

---

## Phase 64 — Deterministic MIDI Humanization

### Goal
Apply seeded timing and velocity variation to MIDI clip sources with reproducible results, bounds checks and undo.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: seeded note-ID keyed timing/velocity humanization, independent of selection order. Timing overflow rejects atomically; velocity saturates to MIDI bounds. Core reproducibility/range/rollback and GUI undo tests pass.

---

## Phase 65 — Chord Construction

### Goal
Generate bounded custom chord intervals from source notes with fresh IDs, preserved articulation and transactional pitch/capacity checks.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: custom bounded chord intervals add independent notes with fresh IDs while retaining originals and articulation. Core pitch/duplicate-interval/capacity-bound rollback and GUI chord/history tests pass.

---

## Phase 66 — Offline Arpeggio Generation

### Goal
Convert source note chords into bounded ascending/descending stepped patterns with gate controls, deterministic ordering and undo.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: bounded offline ascending/descending arpeggio generation with equal-onset/channel chord grouping, step/gate controls and fresh note IDs. Core ordering/gate/capacity rollback and GUI generation/undo tests pass.

---

## Phase 67 — Audio Peak Normalization

### Goal
Analyze the audible source slice outside callbacks and adjust nondestructive clip gain to a requested sample-peak target; validate silence, missing media and gain limits.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: native-rate audible-slice sample-peak analysis adjusts nondestructive clip gain atomically. GUI accepts dBFS targets. Core exact gain, missing-media rollback, silence/gain-limit checks and GUI normalization/undo tests pass.

---

## Phase 68 — Portable Project Collection

### Goal
Collect referenced audio and sampler media into a new self-contained project folder, deduplicate references, preserve original files and reject existing destinations or unsupported references safely.

### Tasks and acceptance criteria
- [x] Implement bounded C99 model/control APIs and accessible GUI commands.
- [x] Preserve transactional errors, history, compatibility and callback safety.
- [x] Verify the feature with automated model/GUI tests and document limitations.

### Implementation status
Implemented: new-folder media collection deduplicates canonical audio and sampler references, copies bounded regular files, writes relative project references last and cleans owned outputs on failure. Relocation after deleting originals, rendered sample content, oversized/FIFO cleanup, existing destinations, allocation rollback and GUI collection pass. Integrated validation below covers all eleven phases.


### Integrated validation for Phases 58–68

All eleven numbered phases have separate implementation commits and passing
warning-enabled model and focused GUI checks. Final integration passed the full
core/offline suite, allocation-failure rollback and ID preservation, complete GUI
and LADSPA/CLAP/VST2/VST3 effect/instrument fixture matrix, and software JACK
start/stop/reconnect/record/active-close checks. ASan/UBSan core and full GUI runs
passed with only the existing system Fontconfig leak suppression. Clang analysis
passed for every core source; both staged installation layouts and C/C++
pkg-config consumers passed. Collection additionally covers relocation after
source deletion, copied render content, deduplication and partial-output cleanup.

The current writer uses project format 16 and reads versions 1–15. These phases
add no dependencies or callback I/O/allocation. See
[COMPOSITION_WORKFLOWS.md](COMPOSITION_WORKFLOWS.md) for commands and bounded
behavior. Human listening, physical hardware, arbitrary third-party plugins and
feature parity with commercial DAWs remain unqualified.

All application screenshots were refreshed after Phase 68. The
[screenshot gallery](../screenshots/README.md) includes controls and results for
every phase from 58 through 68, plus refreshed existing views and detached
editors. The optional `make screenshots` target reproduces the captures using
real FLTK widgets and isolated demonstration data.

---

## Phase 69 — Sample Editor and Source Inspection

### Goal
Open selected audio in a dedicated modal waveform editor with frame-based selection, zoom/scroll and peak/RMS/DC statistics. Preload bounded mono samples outside callbacks; originals and project remain unchanged.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: bounded C99 source snapshots, per-range min/max/RMS/DC analysis and a real modal waveform editor with frame selection, zoom/scroll and audio double-click integration. Warning-enabled full core and focused GUI range/view validation pass; no callback or source file changes.

---

## Phase 70 — Nondestructive Source Range Trimming

### Goal
Apply sample-editor selection as audible clip trims with conservative frame-to-musical-tick rounding, preserved source content and one project undo step.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: native frame bounds trim audio inside its current audible region with conservative tick rounding and preserved timeline/source alignment. Core rounding/rejection/unchanged-state checks and GUI trim/project undo pass.

---

## Phase 71 — Sample Selection Export and Edited Copy Adoption

### Goal
Export selected frames or save the complete edited source into a new mono float32 WAV; optionally relink the selected clip with project undo and cleanup on failed preparation. Never overwrite source/destination files.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: no-clobber mono float32 selection export and full-source copy adoption, preserving frame/rate alignment. Preparation failures remove the newly written copy and retain the original project; successful adoption is project-undoable. Exact exported frames, existing destination protection and GUI failed/successful adoption/undo pass.

---

## Phase 72 — Reversible Sample Range Reversal

### Goal
Reverse a selected source frame range in an independent sample snapshot, with bounded local undo/redo and save-copy adoption.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: immutable whole-source snapshots reverse only selected frames; the editor provides one-level local undo/redo and save-copy adoption. Exact partial-range and double-reversal tests, unmodified surrounding samples and GUI processing/undo pass.

---

## Phase 73 — Sample Polarity Inversion

### Goal
Invert selected samples without altering frames outside the selection, with reversible local processing and no implicit clipping.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: selected-range polarity inversion preserves source length and every surrounding sample, supports local undo/redo and full-copy adoption. Exact signs, two inversions restoring input and focused GUI processing/undo pass.

---

## Phase 74 — DC Offset Removal

### Goal
Measure and subtract the selected range mean using double precision accumulation, preserve other frames and reject invalid ranges atomically.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: double-precision selected-range mean subtraction in a new sample snapshot; nonfinite results reject without mutation. Core residual mean/exact surrounding samples and GUI processing/undo pass.

---

## Phase 75 — Offline Sample Fade Curves

### Goal
Apply linear or equal-power fade-in/out over selected source frames with exact endpoint behavior, local undo and explicit distinction from nondestructive clip fades.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: selected-range linear/equal-power fade-in/out processing with explicit endpoints, one-frame rejection and unchanged surrounding frames. Core curve/interior/endpoint checks and GUI local undo pass.

---

## Phase 76 — Sample Range Gain and Normalization

### Goal
Process selected sample gain or peak normalization with finite bounded parameters, whole-result validation, silence rejection and reversible edits.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: selected sample gain (0..16) and peak normalization (target >0..1, gain cap 16) with silence/NaN/parameter rejection and finite result validation. Exact selected/unselected samples, retained values above unity and GUI processing/undo pass.

---

## Phase 77 — Silence Boundary Detection

### Goal
Find audible selected-range bounds using a user threshold and padding; select detected bounds for export or nondestructive clip trimming. Silence is an explicit no-result error.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: threshold-based audible-range detection with bounded padding and atomic selection updates. Exact threshold/padding, silent no-result, NaN and GUI unchanged/successful selection checks pass.

---

## Phase 78 — Zero Crossing Selection Snapping

### Goal
Find nearest bounded mono zero crossings around selection boundaries with deterministic ties; adjust selection without crossing or inventing samples.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: deterministic nearest zero-sample/sign-crossing boundary search with bounded radius, earlier ties and atomic two-endpoint snapping. Core edge/radius/no-result/tie cases and GUI selection snapping pass.

---

## Phase 79 — Transient Detection and Transactional Audio Slicing

### Goal
Detect threshold attacks with a refractory gap, inspect their source positions, and split the original clip at representable interior source transients in one undoable transactional operation. Qualify integrated rollback, persistence, rendering and GUI behavior.

### Tasks and acceptance criteria
- [x] Implement bounded C99 analysis/processing and accessible FLTK controls.
- [x] Preserve source files, atomic error handling, history and callback safety.
- [x] Pass meaningful core and GUI checks; document exact behavior and limits.

### Implementation status
Implemented: hysteretic amplitude attack detection with refractory gaps, source-frame markers and transactional nearest-tick slicing with one project undo step. Capacity failures preserve clips/IDs; core render comparison and persistence reload, GUI slicing/undo, allocation rollback, sanitizer, static-analysis, plugin/JACK and installation checks pass. See integrated validation and AUDIO_EDITOR.md for explicit mono, timing and detector limits.


### Integrated validation for Phases 69–79

Each of the eleven phases has its own tested implementation commit. The final
warning-enabled core/offline suite and focused sample-editor GUI checks cover
native frame selection, trim rounding, local processing/undo, selection export,
failed/successful copy adoption, project undo and slicing. The native-rate GUI
case trims through the actual editor callback using the fixture's 22.05 kHz rate.
Core regressions verify exact range samples, curve endpoints, residual DC,
silence/zero-crossing ties, threshold hysteresis, attack capacity, partial-slice
capacity rollback/ID preservation, an aligned no-fade render comparison and
saved-slice reload. Oversized source, overflow and gain-cap failures are explicit.

Allocation-failure injection covers every processing operation, source loading,
WAV save cleanup and slicing preparation. Full GUI and LADSPA/CLAP/VST2/VST3
effect/instrument fixtures, software JACK lifecycle, ASan/UBSan core and focused/
full GUI, Clang analysis and both staged install layouts passed. Sanitizer GUI
runs retain only the existing system Fontconfig leak suppression. The public
sample API, docs and two real editor captures are included in the repository.

No dependency or project-format migration was added (writer 16, reads 1–16).
All sample I/O, allocation and processing run on the control thread. The editor
uses the existing mono downmix, bounded snapshots and one local undo/redo step;
project trims/slices remain musical-tick based. Long-file streaming, stereo
source editing, audition/scrubbing, time stretching, spectral processing,
physical listening/hardware and arbitrary third-party plugins remain unqualified.
See [AUDIO_EDITOR.md](AUDIO_EDITOR.md) for precise workflows and limits.

---

## Phase 80 — Compact Creation and Optional Track Inspector

### Goal
Replace the large creation sidebar with a sequencer Create dropdown. Keep all creation actions and shortcuts, and provide an optional track inspector to reclaim horizontal editing space.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: sequencer Create menu retains empty/audio/MIDI track creation, WAV import, instrument loading and MIDI editing. The inspector is hidden by default and available under View/Track inspector, reclaiming 204 pixels. Core baseline and full Xvfb GUI suite passed, including menu callbacks, creation/undo, layout sizes and floating panels. Inspector visibility is session-local.

---

## Phase 81 — Persistent Track Insert Chains

### Goal
Add a bounded C99 per-track insert model with validation, clone/history/duplicate support and backward-compatible project persistence. Loading metadata must not load plugin binaries.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: eight validated metadata-only insert slots per non-bus track, including enabled/wet/output values, format 17 persistence and reads of formats 1–16 with empty chains. Clone/history use copied state; duplicate/move/remove retain track association. Full warning-enabled core suite and dedicated metadata, persistence and invalid-value tests passed. See TRACK_INSERTS.md. Playback integration follows in phase 82.

---

## Phase 82 — Prepared Track Insert Processing

### Goal
Compile track inserts into serial modular graphs before track gain/pan. Cover audio and MIDI rendering, export, bypass, cleanup and callback safety; explicitly reject unsupported routing.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: generated serial graphs process summed pre-fader audio or MIDI per track; prepared renderer plans feed JACK/export and post-effect meters. Wet/dry branches, bypass and output gain are compiled on the control thread. Exact impulse/delay, overlapping clips, block continuity, seek reset, MIDI samples and hybrid rejection pass. Full core suite and allocation-failure/callback guards pass. Bus/hybrid inserts reject explicitly; external adapters retain mono/zero-latency limits. See TRACK_INSERTS.md.

---

## Phase 83 — Track Inserts in the Modular Workspace

### Goal
Offer a selected-track insert view alongside the global graph, with clear signal order and transactional Add effect actions.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: Ctrl+4 opens the track insert rack and actual generated modular graph, alongside the global graph. Track selection and Add effect provide internal devices and the existing four-format plugin library; candidate preparation and undo are transactional. Warning-enabled GUI build and focused adoption/undo/failed preparation/missing module/save-reload tests passed. Generated wiring is read-only.

---

## Phase 84 — Searchable Effect Discovery

### Goal
Make LADSPA, VST2, VST3 and CLAP effects easy to find and add, including Linux VST3 bundles, format filters and clear compatibility errors.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: case-insensitive path/name search and All/LADSPA/VST2/VST3/CLAP filters in the shared plugin library, with recursive Linux VST3 bundle discovery, deduplication and bounded traversal. Listing executes no module code; inspection checks ABI/layout. Ambiguous .so candidates appear in both LADSPA and VST2 filters. Warning-enabled GUI build and focused discovery-filter/adoption tests passed.

---

## Phase 85 — Insert Chain Editing

### Goal
Expose move up/down, remove and bypass with one undo step per action and safe prepared-plan adoption.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: selected insert Up/Down, bypass and removal, preserving effect metadata and selection on reorder. Every successful edit prepares a candidate and records one undo step. Focused GUI checks cover boundary rejection, order, bypass, removal/undo and saved chain reload; warning-enabled build passed.

---

## Phase 86 — Insert Inspection and Controls

### Goal
Show selected effect identity and supported generic controls. Provide reset where supported and clearly identify unavailable native editors/parameters.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: selected insert Inspect/edit verifies identity and shows generic controls with reset/defaults through transactional preparation. Zero-parameter adapters explicitly explain default configuration and unavailable native editors; reset is disabled there. Focused real modal reset/apply/cancel, adoption, undo and reload tests passed with a warning-enabled GUI build.

---

## Phase 87 — Reusable Effect Chain Presets

### Goal
Save and load portable chain metadata with bounded validation, transactional replacement and explicit missing-plugin errors at preparation.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: atomic chain preset save/load reuses the versioned project container with exactly one non-bus track and no clips/instrument. Metadata load never opens modules and preserves output on failure; GUI adoption prepares all effects before replacement. Core roundtrip/malformed tests, full core suite and GUI replacement/missing-file/reload checks passed. Presets reference installed binaries; opaque plugin states are not captured.

---

## Phase 88 — Parallel Insert Mix and Chain Output

### Goal
Expose per-slot wet/dry and chain output gain with finite bounded values and render tests for endpoints and ordering.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: selected insert wet amount (0–1) and chain output gain (0–4) controls; parallel dry/wet gain branches and pre-fader output scaling. Track-chain tempo follows project tempo during assignment and changes. Exact dry/wet endpoint and fractional impulse tests, full core/reliability suite and GUI mix/invalid-value/tempo/preset tests passed. Mono mix controls use linear amplitude blending.

---

## Phase 89 — Host VST3 Gallery and Integrated Qualification

### Goal
Load compatible installed host VST3 effects in real track chains, capture screenshots, update usage documentation and qualify integration, persistence and real-time boundaries.

### Tasks and acceptance criteria
- [x] Implement the described workflow with validated errors and safe ownership.
- [x] Pass relevant core and/or GUI tests.
- [x] Document behavior and limitations; commit this phase separately.

### Implementation status
Implemented: installed host ZamEQ2, ZamAutoSat and ZamDelay VST3 effects load together, render finite nonzero output and export a non-silent WAV. A bounded VST3 output-parameter sink fixes host assertion logging; the fixture verifies notification/reset/capacity behavior. Actual format labels and scrollable compact insert graphs are verified. All 52 prior screenshots were refreshed and five real compact/VST3 captures added. Full core/reliability, four-format insert GUI, full effect/instrument GUI matrix, JACK lifecycle, ASan/UBSan core and focused/full GUI, static analysis and both staged install layouts passed. See TRACK_INSERTS.md and screenshots/README.md for exact limits and reproduction.

---

### Integrated validation for Phases 80–89

All ten phases have separate tested implementation commits. Verification used
`make BUILD_DIR=build/audio-editor all test test-reliability gui`,
`test-gui-track-fx`, the full `test-gui`, `test-gui-modern-plugins`,
`test-gui-instruments`, `test-gui-plugins` and `test-gui-jack` targets,
`analyze`, `test-install` and `test-install-layout`. Clang ASan/UBSan core,
allocation guards and focused/full GUI checks passed using only the existing
system Fontconfig leak suppression. The normal GCC build is warning-free;
Clang/FLTK emits the existing redundant-instrumentation warning.

The opt-in `XTC_TEST_HOST_VST3=1` core check loaded the installed Zam VST3
binaries, rendered their serial MIDI-track chain and validated non-silent WAV
export. The screenshot tool refreshed the complete prior gallery; its
`XTC_CAPTURE_HOST_VST3=1` mode captured the real loaded chain, identity view,
parallel branches, compact workspace and creation menu. Metadata-only CLI
inspection tests cover insert dependencies, malformed/overflow records,
nonfinite values, missing modules and v16 migration without executing modules.

No dependency was added. Writer format is 17, reads 1–17. Inserts remain bounded
mono effects with zero reported latency, control-thread edits and no native
plugin editors or modern parameter/state persistence. Bus/hybrid inserts reject
preparation. These tests qualify host ownership and the named configurations;
physical hardware, arbitrary third-party plugins and feature parity with mature
DAWs are not claimed. See TRACK_INSERTS.md and KNOWN_LIMITATIONS.md.

---

## Phase 90 — Selected Track Effect Access

### Goal
Open the sequencer or mixer selection directly in Track inserts with a dedicated shortcut, preserving the piano-roll shortcut and rejecting bus/no selection.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: selected sequencer/mixer track opens directly in the insert workspace with Ctrl+5; the original piano-roll Ctrl+4 is preserved. Invalid/no track leaves the view unchanged and buses reject. Baseline core suite, warning-enabled GUI build and focused selection/context/shortcut tests passed.

---

## Phase 91 — Duplicate Effect Slots

### Goal
Duplicate an effect adjacent to its slot with copied parameters, automation, wet amount and bypass; prepare transactionally, enforce the eight-slot limit and support undo.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: bounded C99 metadata duplication and Rack actions/Duplicate effect create an adjacent independent slot, preserving parameters, automation, wet/bypass and gain. Warning-enabled core checks cover aliasing, independent edits and capacity rollback; GUI duplication, selection and undo checks passed.

---

## Phase 92 — Track Chain Clipboard

### Goal
Copy and paste independent chain metadata between tracks, with explicit replacement, undo and document-lifecycle cleanup. Clipboard operations must not load modules.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: session-local independent chain copy/paste with explicit destination replacement, output-gain preservation and prepared undoable adoption. Paste readiness is visible in the menu and successful New/Open clears the clipboard. Focused GUI tests passed for independence, cross-track paste, undo, failed preparation and lifecycle cleanup.

---

## Phase 93 — Effect Chain A/B Comparison

### Goal
Capture and recall two track-bound effect configurations, with clear readiness indicators, safe preparation, undo and cleanup on document replacement.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: two independent track-bound chain comparison slots, with disabled Recall until captured on the current track. Capture is metadata-only; recall prepares fresh instances and records one undo edit. GUI capture/recall, A/B values, undo, cross-track rejection and New cleanup checks passed with a warning-enabled build.

---

## Phase 94 — Creative Chain Templates

### Goal
Offer original dependency-free Slapback, Dub Echo and Ambient Space starting points using internal devices, including safe replacement and editable controls.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: Slapback, Dub Echo and Ambient Space templates use original internal Delay/Reverb configurations with editable controls and explicit chain replacement. C99 generation validates tempo/index, preserves errors and loads no external modules. All templates compile/render finite nonzero output; GUI template adoption and undo checks passed.

---

## Phase 95 — Bulk Rack Actions

### Goal
Enable all inserts, bypass all inserts or clear a chain as single undoable prepared edits, retaining output gain and respecting recording/error restrictions.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: bounded C99 enable-all, bypass-all and clear transforms preserve output gain and support in-place metadata use. Rack actions prepare one undoable replacement; failed enable preparation preserves the old chain. Core metadata/invalid-action checks and GUI bypass/enable/clear/undo/rollback checks passed.

---

## Phase 96 — Live Meters in the Insert Workspace

### Goal
Display selected-track stereo sample peaks and a resettable clip indicator from the existing single backend meter reader, with clear post-fader labeling and offline/stopped handling.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: UI-only stereo peak display in the insert workspace shares the existing backend meter snapshot, with post-fader/pre-bus labels, 20 dB/s release and click-to-clear sticky clipping. Stopped/missing/offline readings show the floor and track changes reset history. GUI dB conversion, clipping, stopped/reset and selection checks passed; no extra backend reader was added.

---

## Phase 97 — Tap Tempo

### Goal
Provide a transport Tap button backed by a bounded C99 rolling interval estimator, with timeout/reset, sensible tempo limits and undoable project tempo adoption.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: transport Tap uses a bounded C99 four-interval estimator, 20–300 BPM, monotonic timestamps and a three-second restart gap. Invalid/fast/backward taps preserve estimator/output; accepted tempo edits use normal prepared project adoption and undo. Core rolling-average/timeout/invalid tests and GUI tempo/undo/New reset checks passed with a warning-enabled build.

---

## Phase 98 — One-Action Audio Crossfades

### Goal
Apply matching linear boundary fades to two partially overlapping audio clips on one track, preserving source files and opposite fades. Reject ambiguous layouts transactionally and provide one undo step.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: allocation-free C99 validation applies paired linear overlap fades atomically, retaining opposite fades, media, gains and positions. Ambiguous layouts reject. Exact overlapping-wave render and invalid-selection preservation checks passed, as did GUI two-clip crossfade/undo and warning-enabled builds.

---

## Phase 99 — MIDI Chord Strumming

### Goal
Spread simultaneous chord notes in pitch order with a user-selected tick spacing and direction, preserving original ends and rejecting source overflow atomically. Expose a musical editing command with undo.

### Tasks and acceptance criteria
- [x] Implement the workflow with bounded validation, safe preparation and documented limits.
- [x] Pass meaningful core and/or GUI checks, including error and undo behavior.
- [x] Document results and commit this phase separately.

### Implementation status
Implemented: transactional C99 chord strumming groups source onsets by clip/channel, orders by pitch with stable-ID ties, preserves original note ends and rejects invalid durations atomically. Core ascending/descending/channel/singleton/mixed-selection/rollback checks, allocation-failure injection and real GUI editing/undo passed. A bounded spacing/direction dialog exposes the operation; source notes hidden by trims remain editable.

---

## Integrated Validation for Phases 90–99

Completed on 2026-11-06 with `BUILD_DIR=build/audio-editor`:
warning-enabled `all test test-reliability`, `test-gui-creative`,
`test-gui-track-fx`, full `test-gui`, modern-plugin/instrument/LADSPA GUI fixtures,
and `test-gui-jack`. Clang static analysis and both staged install layouts passed,
including C/C++ pkg-config consumers. ASan/UBSan creative core, allocation-failure
and focused/full GUI checks passed using only the existing Fontconfig leak
suppression; Clang/FLTK retains its existing instrumentation warning.

Four additional real screenshots show the Dub Echo rack, actions menu, strum
dialog and piano-roll result. Earlier gallery captures remain labeled Phase 89.
See [creative workflows](CREATIVE_WORKFLOWS.md) and
[the gallery](../screenshots/README.md) for reproduction and limits. Chains and
A/B snapshots copy supported metadata, not opaque plugin states or DSP histories.
Crossfades use existing linear envelopes; strumming is a source-note edit.
Project format remains 17, readable from versions 1–17; no dependencies were added.

## Phase 100 — Complete Application Configuration Persistence

### Goal
Load ~/.xtc.conf before creating projects or audio backends; save all application preferences and workspace defaults on Apply and clean exit. Preserve malformed files until explicitly replaced.

### Tasks and acceptance criteria
- [x] Implement and document the workflow with bounded validation and safe ownership.
- [x] Pass meaningful core and GUI checks, including errors and persistence or undo.
- [x] Commit this phase separately after validation.

### Implementation status
Implemented: ~/.xtc.conf is loaded before project/backend creation and saved atomically on Preferences Apply and clean exit. Workspace position, inspector visibility, snap/zoom, loop and note defaults are collected. Invalid startup files are preserved until explicit Apply. Configuration roundtrip/permissions tests, focused startup/exit/malformed-file GUI checks and full GUI suite passed.

---

## Phase 101 — MIDI Device Input and Output Backend

### Goal
Expose JACK MIDI source/destination discovery, routing, input filtering and external MIDI output with bounded callback work and panic safety.

### Tasks and acceptance criteria
- [x] Implement and document the workflow with bounded validation and safe ownership.
- [x] Pass meaningful core and GUI checks, including errors and persistence or undo.
- [x] Commit this phase separately after validation.

### Implementation status
Implemented: public JACK MIDI discovery/naming/routing/options APIs, a prepared bounded note-output schedule, optional filtered live thru and output channel override. Seek/loop discontinuities chase notes; panic/stop/overflow send all-notes-off. Core and allocation-failure suites and real JACK input/thru/receiver checks passed; deterministic backend checks cover event offsets, filtering, routing, panic and seek/note-off. See MIDI_WORKFLOWS.md for shared-output, transport-active and device-loss limits.

---

## Phase 102 — MIDI Preferences and Device Defaults

### Goal
Provide device dropdowns and refresh in Preferences, persistent default input/output ports, live channel filters and MIDI thru; retain editing and controller defaults in ~/.xtc.conf.

### Tasks and acceptance criteria
- [x] Implement and document the workflow with bounded validation and safe ownership.
- [x] Pass meaningful core and GUI checks, including errors and persistence or undo.
- [x] Commit this phase separately after validation.

### Implementation status
Implemented: a MIDI preferences tab provides editable source/destination dropdowns, device refresh, input filtering, output channel defaults and optional thru. All choices use the strict shared configuration schema and ~/.xtc.conf. Play/Record restores selected routes; missing devices reject startup without losing choices. Settings roundtrip/invalid-value, GUI discovery/refresh/persistence/missing-device checks and the full GUI suite passed. MIDI help explains host bridge exposure, channel numbering and existing note/CC defaults.

---

## Phase 103 — Export Selected Clips as Standard MIDI Files

### Goal
Export the audible part of a selected MIDI clip as an atomic Standard MIDI File with note timing, channels, velocities and project tempo.

### Tasks and acceptance criteria
- [ ] Implement and document the workflow with bounded validation and safe ownership.
- [ ] Pass meaningful core and GUI checks, including errors and persistence or undo.
- [ ] Commit this phase separately after validation.

### Implementation status
Planned.

---

## Phase 104 — Import Standard MIDI Files

### Goal
Import type 0/1 PPQN MIDI notes onto the selected track or a new track, with safe parsing, explicit limits, tempo policy and one undoable prepared adoption.

### Tasks and acceptance criteria
- [ ] Implement and document the workflow with bounded validation and safe ownership.
- [ ] Pass meaningful core and GUI checks, including errors and persistence or undo.
- [ ] Commit this phase separately after validation.

### Implementation status
Planned.

---

## Phase 105 — MIDI Workflow Screenshots and Qualification

### Goal
Capture current MIDI preferences, file workflows and imported notes, refresh the gallery, and qualify configuration, MIDI I/O and file workflows together.

### Tasks and acceptance criteria
- [ ] Implement and document the workflow with bounded validation and safe ownership.
- [ ] Pass meaningful core and GUI checks, including errors and persistence or undo.
- [ ] Commit this phase separately after validation.

### Implementation status
Planned.

---

## Recommended Execution Order

Reorder the phases when the audit reveals a blocking dependency. Do not mark a phase complete merely because code exists: its acceptance criteria must be demonstrated by builds, tests, or documented manual verification.

## Definition of Done for Each Phase

A phase is complete only when:

- The project builds with warnings enabled.
- Relevant automated tests pass, and manual tests are documented where automation is impractical.
- Error paths, resource ownership, and thread boundaries have been reviewed.
- Real-time audio constraints remain satisfied.
- Documentation is updated alongside API or behavior changes.
- No unrelated functionality was silently removed.
- Untested behavior and known limitations are reported honestly.
- The phase's acceptance criteria are explicitly checked off.

Do not skip phases without documenting why and preserving acceptance criteria.