3805 lines
157 KiB
Markdown
3805 lines
157 KiB
Markdown
# Roadmap
|
||
|
||
Build commands in Phases 0–107 are historical qualification records from the
|
||
Makefile era. The current supported commands are in [BUILD.md](BUILD.md);
|
||
Phase 108 replaces that build with CMake and CTest.
|
||
|
||
## Phase 0 — Baseline
|
||
|
||
### Goal
|
||
|
||
Inspect repository/toolchain, verify Makefile and minimal executable, document
|
||
dependencies. No system changes without permission.
|
||
|
||
### Implementation status
|
||
|
||
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
|
||
|
||
### Goal
|
||
|
||
Graph data structures, validation, cycle detection, topological ordering,
|
||
preallocated buffers, test oscillator, gain and offline render tests.
|
||
|
||
### Implementation status
|
||
|
||
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
|
||
|
||
### Goal
|
||
|
||
Choose and implement a Linux backend. Document callback semantics, start/stop,
|
||
device errors, shutdown, and safe graph publication.
|
||
|
||
### Implementation status
|
||
|
||
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
|
||
|
||
### Goal
|
||
|
||
Main window, transport controls, view switching, backend status, clean startup
|
||
and shutdown through the C API.
|
||
|
||
### Implementation status
|
||
|
||
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
|
||
|
||
### Goal
|
||
|
||
Draw nodes/ports/edges; create, move and connect nodes; reject invalid edges;
|
||
safely submit edits to the C core.
|
||
|
||
### Implementation status
|
||
|
||
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
|
||
|
||
### Goal
|
||
|
||
Versioned persistence, stable IDs, tracks, clips, timeline, selection, zoom,
|
||
scrolling, and transport synchronization.
|
||
|
||
### Implementation status
|
||
|
||
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
|
||
|
||
### Goal
|
||
|
||
Audio import/playback, recording through bounded buffers, missing-asset
|
||
handling, no file I/O in callbacks.
|
||
|
||
### Implementation status
|
||
|
||
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
|
||
|
||
### Goal
|
||
|
||
MIDI input/events/clips, simple internal instrument, note-off/panic handling,
|
||
then a basic piano roll.
|
||
|
||
### Implementation status
|
||
|
||
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
|
||
|
||
### Goal
|
||
|
||
Gain/pan, meters, mute/solo, automation, undo/redo, keyboard workflow.
|
||
|
||
### Implementation status
|
||
|
||
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
|
||
|
||
### Goal
|
||
|
||
Native node API, evaluate plugin hosting, licensing review, packaging,
|
||
installation tests, performance and recovery tests.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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.
|
||
|
||
### Implementation status
|
||
|
||
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 were initially saved only with Apply; Phase 100 also saves on clean
|
||
exit. 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.
|
||
|
||
### Integrated validation for 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.
|
||
|
||
### Follow-up fix
|
||
|
||
MIDI dropdown labels now use dialog-owned backing strings because FLTK copies
|
||
menu items but borrows their labels. Menus are cleared before refresh or string
|
||
destruction. The regression test reproduces the previous heap use-after-free
|
||
under AddressSanitizer and verifies both lists, literal names with slashes,
|
||
selection/save, repeated refresh, offline selection retention and None.
|
||
`test-gui-midi-labels`, `test-gui-midi-workflows`, full `test-gui` and the
|
||
focused ASan/UBSan/leak check pass; the GUI application was rebuilt without
|
||
warnings.
|
||
|
||
---
|
||
|
||
## 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
|
||
|
||
- [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 C99 atomic type-0/960-PPQN SMF exporter and GUI save chooser
|
||
export one selected MIDI clip, preserving note channels/velocities, project
|
||
tempo, clip name and trailing silence. Trim-crossing notes crop to audible
|
||
boundaries; out-of-trim notes omit. Independent byte/event checks,
|
||
invalid/audio/destination preservation checks, bounded external scheduling
|
||
overflow checks and focused GUI export/nonmutation tests passed with
|
||
warning-enabled builds.
|
||
|
||
---
|
||
|
||
## 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
|
||
|
||
- [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: bounded C99 type 0/1 PPQN notes import with running status,
|
||
channel/velocity preservation, tick conversion, track merging and retained
|
||
project tempo. File/Import MIDI and Create/Import MIDI add at the cursor on the
|
||
current or a new track through one prepared undo edit. Export/import roundtrips,
|
||
independent type-1 fixture, every truncation prefix,
|
||
malformed/unsupported/bus/overflow rejection, allocation-failure rollback and
|
||
GUI import/undo/redo/new-track/failed-adoption checks passed, together with the
|
||
full core/reliability suite. Notes-only limits are explicit in
|
||
MIDI_WORKFLOWS.md.
|
||
|
||
---
|
||
|
||
## 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
|
||
|
||
- [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: all 66 gallery PNGs were refreshed, including five new MIDI
|
||
preferences/help/file-menu/import captures through real C/GUI workflows. A
|
||
real-process isolated-home test proves ~/.xtc.conf creation, startup reload and
|
||
malformed-file preservation. Final routing qualification adds bounded PipeWire
|
||
publication retry and holds transport until chosen routes exist, preserving
|
||
notes at position zero; deterministic callback and real receiver checks pass.
|
||
Full core/reliability, GUI/plugin/JACK, optional-backend builds, ASan/UBSan,
|
||
static analysis and staged installation checks passed.
|
||
|
||
### Follow-up screenshot
|
||
|
||
[open MIDI input device
|
||
dropdown](../screenshots/preferences-midi-input-devices.png) shows actual host
|
||
MIDI sources after the label-lifetime fix. The reproducible
|
||
`XTC_CAPTURE_MIDI_INPUT_ONLY=1` capture uses the real preferences dropdown and
|
||
leaves device routing/configuration unchanged. Warning-enabled capture build,
|
||
successful capture and visual inspection confirmed readable device names.
|
||
|
||
### Integrated validation for Phases 100–105
|
||
|
||
Completed on 2026-11-06. Normal builds use `BUILD_DIR=build/audio-editor`:
|
||
`all gui test-reliability`, `test-gui-midi-workflows`, `test-gui-creative`,
|
||
`test-gui-track-fx`, full `test-gui`, modern-plugin/instrument/LADSPA GUI
|
||
fixtures, `test-gui-jack`, `test-jack-midi`, and `test-configuration-startup`
|
||
passed. The final routed-start change was rechecked with core/reliability,
|
||
full/focused GUI, live MIDI first-note receipt and real-process configuration
|
||
startup tests.
|
||
|
||
`BUILD_DIR=build/midi-minimal PKG_CONFIG=false FLTK_CONFIG=false all test`
|
||
passed. Clang ASan/UBSan full core/reliability and focused/full GUI checks
|
||
passed using only the existing Fontconfig leak suppression. The existing
|
||
Clang/FLTK redundant instrumentation warning remains; normal warning-enabled
|
||
builds are clean. Clang static analysis (including a final backend recheck),
|
||
default/custom staged install layouts and C/C++ pkg-config consumers passed.
|
||
|
||
The full gallery and host VST3/creative/MIDI capture modes regenerated 66 PNGs.
|
||
File import is notes-only type 0/1 PPQN and retains project tempo. MIDI devices
|
||
are JACK/PipeWire ports; physical hardware/bridge compatibility is not claimed
|
||
from software-port tests. No dependencies or project-format change were added.
|
||
See [MIDI_WORKFLOWS.md](MIDI_WORKFLOWS.md), [PREFERENCES.md](PREFERENCES.md) and
|
||
[the gallery](../screenshots/README.md) for reproduction and exact limits.
|
||
|
||
---
|
||
|
||
## Phase 106 — Steinberg VST SDK and ASIO Integration
|
||
|
||
### Goal
|
||
|
||
Use the official Steinberg SDKs to qualify and extend xtc's VST hosting and
|
||
prepare native Windows ASIO audio I/O, with runnable examples. Keep the C99
|
||
engine and public C API; SDK-specific C++ belongs in optional tools/examples or
|
||
an isolated platform bridge. This is a staged phase, **in progress**, not a
|
||
claim that every VST extension or ASIO driver is supported.
|
||
|
||
### Tasks and acceptance criteria
|
||
|
||
- [x] Add an opt-in external VST3 SDK CMake build, official validator target,
|
||
and original SDK-built gain effect and MIDI instrument examples. Ordinary
|
||
builds must remain offline and SDK-independent.
|
||
- [x] Load conventional Linux VST3 bundles as well as inner binaries, preserving
|
||
the chosen bundle path in plugin metadata and existing module ownership.
|
||
- [x] Supply VST3 process context with sample position, sample rate, tempo and
|
||
musical position for effect and instrument processing, including seeks.
|
||
- [x] Provide a headless C example rendering the SDK synth through the gain
|
||
effect to a no-clobber WAV, and automated SDK/xtc interoperability checks.
|
||
- [ ] Qualify the ASIO SDK device/channel/format/latency diagnostic example on
|
||
native Windows with a real installed driver. Explicit driver selection;
|
||
no automatic installation, sample-rate changes or device routing.
|
||
- [ ] Add VST3 edit-controller lifecycle/connection handling, normalized
|
||
parameters, sample-accurate input automation and parameter feedback to
|
||
xtc's existing controls and undo paths; test with SDK and real plugins.
|
||
- [ ] Add bounded component/controller opaque-state persistence and transactional
|
||
reload, with relocation/missing-module and corrupt-state tests.
|
||
- [ ] Extend the graph/host contract for native stereo, multiple buses,
|
||
sidechains, latency compensation, tails and float64 negotiation; retain
|
||
explicit rejection until each layout is supported and tested.
|
||
- [ ] Embed native VST3 editors with Linux run-loop/resize ownership, close and
|
||
reopen tests, and main/audio-thread separation. Extend note expression,
|
||
MIDI mapping and process-context requirements without inventing timing.
|
||
- [ ] Extend legacy VST2 interoperability (parameters/state/editor/transport)
|
||
against user-supplied licensed plugins. The discontinued VST2 SDK is not
|
||
supplied by VST3 and must not be presented as a downloadable dependency.
|
||
- [ ] Introduce a native Windows ASIO backend behind the C backend interface:
|
||
explicit driver/device selection, buffer negotiation, integer/float sample
|
||
conversion, double buffers/time-info callbacks, channel mapping, latency,
|
||
reset/resync/rate-change recovery and callback quiescence. First establish
|
||
a Windows build of the C engine; do not pretend ASIO is a Linux backend.
|
||
- [ ] Qualify ASIO start/stop/reopen, playback/capture, MIDI coexistence, format
|
||
conversion and failure cleanup with deterministic driver tests and real
|
||
Windows hardware loopback; record SDK, OS, driver and hardware versions.
|
||
- [ ] Audit SDK licenses/notices and packaging for each enabled integration;
|
||
update examples, user documentation and the compatibility matrix after
|
||
each completed slice. No third-party plugin redistribution implied.
|
||
|
||
### Implementation status
|
||
|
||
The first slice adds optional SDK builds/examples, Linux bundle resolution and
|
||
VST3 transport context. See [STEINBERG.md](STEINBERG.md) and
|
||
[examples/steinberg](../examples/steinberg/README.md) for reproduction and exact
|
||
limits. The optional ASIO diagnostic source uses a separately supplied SDK;
|
||
Windows compilation and hardware validation remain pending. The application
|
||
still uses JACK/PipeWire on Linux. Controller/editor/opaque-state, richer bus
|
||
layouts and the native Windows backend remain open acceptance criteria above.
|
||
|
||
### Validation of the initial slice
|
||
|
||
On 2026-11-06, `make BUILD_DIR=build/steinberg-host all test` passed with
|
||
warnings enabled. The optional official-SDK target passed Steinberg validator
|
||
**94/94** plus xtc gain/synth, sample-offset and bundle-path save/reload checks
|
||
against SDK revision `3cdf9ca5d1f5b1b21e0a86832aa4abe55607bd96` (3.8.1).
|
||
Focused Clang ASan/UBSan module-path, modern-host and SDK interoperability tests
|
||
passed; static analysis of path resolution and the host facade reported no
|
||
findings. Independent WAV checks confirmed float32/mono/48 kHz, 96000 frames,
|
||
note-off silence and no-clobber destination preservation. Metadata inspection
|
||
accepts readable bundle binaries without executing them. Linux ASIO-option
|
||
configuration correctly rejects the unsupported platform; no Windows build or
|
||
ASIO hardware result is claimed.
|
||
|
||
|
||
---
|
||
|
||
## Phase 107 — JUCE Audio, Plugin, DSP and Interface Examples
|
||
|
||
### Goal
|
||
|
||
Use JUCE's relevant audio framework capabilities with the actual xtc C99 engine:
|
||
AudioProcessor/plugin wrappers, standalone audio/MIDI devices, a native editor,
|
||
parameter/state management, DSP effects, MIDI files, WAV export and VST3 hosting.
|
||
Keep this integration optional and externally supplied. This user-requested
|
||
phase can proceed alongside the unfinished platform work in Phase 106; it does
|
||
not replace the main FLTK application or move the C engine into C++.
|
||
|
||
### Tasks and acceptance criteria
|
||
|
||
- [x] Add an offline-by-default external JUCE build and explain its
|
||
AGPLv3/commercial licensing, dependencies and packaging boundary.
|
||
- [x] Build working VST3 and standalone synth targets using xtc Soft Keys through
|
||
the public C API; negotiate mono/stereo and handle variable host blocks.
|
||
- [x] Provide a native JUCE editor with attached host parameters, on-screen MIDI
|
||
keyboard, peak display, panic and transactional versioned preset files.
|
||
- [x] Use JUCE DSP for a low-pass filter, reverb and smoothed output gain, with
|
||
all processing storage prepared outside processBlock.
|
||
- [x] Implement bounded MIDI queues/overflow panic and preserve host MIDI sample
|
||
offsets without callback allocation, I/O, GUI calls or host-side locks.
|
||
- [x] Provide a console example for Standard MIDI File import with tempo
|
||
conversion and float32 stereo WAV rendering with atomic no-clobber output.
|
||
- [x] Demonstrate explicit JUCE VST3 discovery, parameter inspection, state
|
||
capture/restore and actual MIDI processing against the built example.
|
||
- [x] Test C-render equivalence, stereo/mono, variable blocks, reset, invalid
|
||
preparation, queue overflow, preset recovery, editor rendering/reopening
|
||
and loading the JUCE VST3 from xtc's existing C host.
|
||
- [x] Build with warnings enabled, run the focused integration checks and retain
|
||
ordinary C/FLTK builds/tests without a JUCE dependency.
|
||
|
||
### Implementation status
|
||
|
||
Implemented and qualified on Linux with external JUCE 9.0.4 revision
|
||
`3fb5cbc0340758596dac39f7c8de47d562b4896e`. See [JUCE.md](JUCE.md) and
|
||
[examples/juce](../examples/juce/README.md) for reproduction.
|
||
|
||
Validation (2026-11-06):
|
||
|
||
- `make -j4 all test`: ordinary C/FLTK build and regression suite passed.
|
||
- `make JUCE_ROOT=/path/to/JUCE test-juce`: warning-enabled VST3, standalone
|
||
and CLI builds; processor/JUCE-host CTests; file/editor acceptance checks;
|
||
and the existing C-host integration test passed under Xvfb.
|
||
- Steinberg VST 3.8.1 validator: 47 tests passed, zero failed.
|
||
- Rendered the demo to a 216000-frame 48 kHz stereo float32 WAV; inspected
|
||
the actual 1560 × 980 editor snapshot. No physical audio device was opened.
|
||
- C-host all-off uses individual note-offs, so acceptance checks finite release
|
||
and eventual silence; the JUCE host also verifies immediate MIDI all-off timing.
|
||
|
||
Broader adoption in
|
||
the main DAW, additional plugin formats, Windows/macOS portability, native ASIO
|
||
and physical-device latency/loopback qualification remain separate work. Merely
|
||
building JUCE's standalone wrapper does not establish hardware acceptance.
|
||
|
||
---
|
||
|
||
## Phase 108 — Complete CMake Build Migration
|
||
|
||
### Goal
|
||
|
||
Replace the hand-written root Makefile with a full CMake project and CTest,
|
||
preserving C99/C++17 boundaries, optional dependencies, SDK examples, fixtures,
|
||
developer tools and the audited installation/release workflows. This explicitly
|
||
requested build migration can proceed alongside remaining hardware/platform
|
||
qualification in earlier phases.
|
||
|
||
### Tasks and acceptance criteria
|
||
|
||
- [x] Define target-based core, CLI, GUI, example and plugin-fixture builds with
|
||
warnings, generated dependencies and optional JACK/FLTK/LADSPA discovery.
|
||
- [x] Register offline/unit/integration and GUI checks with CTest; keep live
|
||
JACK workflows opt-in and retain linker-based fault injection.
|
||
- [x] Provide separate debug/release/minimal/sanitizer presets, screenshot,
|
||
analysis, benchmark, stress and focused test targets.
|
||
- [x] Build optional Steinberg/JUCE SDK examples through root CMake; eliminate
|
||
JUCE's recursive Make dependency while retaining standalone SDK entry points.
|
||
- [x] Preserve staged install/uninstall, configurable layouts, pkg-config,
|
||
license inventory, reproducible source exports and binary-package checks.
|
||
- [x] Remove the root Makefile and update current documentation, examples,
|
||
third-party build guidance and agent instructions to use CMake/CTest.
|
||
- [x] Validate GNU Makefiles and Ninja, a minimal C-only build, GUI checks,
|
||
sanitizer tests, SDK interoperability and release/install/package workflows.
|
||
|
||
### Implementation status
|
||
|
||
Completed on 2026-11-06 with CMake 4.4.5, GCC 16.2.1, Clang 23.1.4 and
|
||
both Unix Makefiles and Ninja. The original build-rule Makefile was removed; see
|
||
[BUILD.md](BUILD.md), [RELEASING.md](RELEASING.md) and
|
||
[third-party guidance](../third_party/README.md).
|
||
|
||
Validation:
|
||
|
||
- Debug CMake build with JACK/FLTK: all 55 registered offline/GUI tests passed.
|
||
- Ninja Release build with GUI/JACK/LADSPA disabled: all 41 tests passed; the
|
||
configuration enabled only C, and `BUILD_TESTING=OFF` also built successfully.
|
||
- Clang ASan/UBSan: all 42 offline tests passed, including one million virtual
|
||
playback blocks. Clang static analysis passed for all C core sources.
|
||
- Default/custom staged install and removal, C/C++ installed pkg-config consumers,
|
||
symlink protection, prefix spaces and minimal/no-JACK installation passed.
|
||
Binary archive contents, hashes, relocation and repeat packaging passed.
|
||
- Two independent source-export Release builds (including the GUI and CTest)
|
||
produced byte-identical `libxtc.a`, `xtc-check`, `xtc` and repacked archives.
|
||
The check used an isolated temporary Git index to include the new CMake files
|
||
without staging the user's working index; normal `dist` still exports indexed
|
||
files as documented.
|
||
- Root Steinberg SDK build: host interoperability and official validator CTests
|
||
passed. Root JUCE build: all four C-host, file/editor, processor and JUCE-host
|
||
CTests passed. The standalone JUCE entry point also configured and built its
|
||
CMake core target successfully. The bridge does not invoke Make.
|
||
- CMake screenshot capture produced four actual creative-workflow images in the
|
||
ignored binary tree. Preview targets wrote the expected WAV files; graph and
|
||
project benchmark drivers ran successfully (timings were not used as a gate
|
||
while compilation was running). Three minimal-build CPU stress rounds passed.
|
||
- Five opt-in live JACK/workflow tests were registered and inspected; they were
|
||
not rerun as hardware acceptance. External SDK sources can emit upstream
|
||
warnings; the normal project builds were warning-free.
|
||
|
||
A subsequent user-requested convenience Makefile forwards configure/build,
|
||
CTest, GUI/run and clean commands to CMake. It has no compilation rules or source
|
||
inventory; CMake remains authoritative. See [quick shortcuts](BUILD.md#quick-make-shortcuts).
|
||
|
||
Historical validation above remains as recorded. This migration adds no
|
||
Windows/macOS, physical-device, native ASIO, or additional plugin-format
|
||
qualification.
|
||
|
||
---
|
||
|
||
## Phase 109 — Expandable Track Velocity Lanes
|
||
|
||
### Goal
|
||
|
||
Expand arrangement tracks downward with a small disclosure arrow and edit MIDI
|
||
note velocities directly below their clips. This user-requested GUI increment
|
||
uses the existing C note-editing, persistence and history contracts.
|
||
|
||
### Tasks and acceptance criteria
|
||
|
||
- [x] Add a small arrow beside each track name; independently expand/collapse
|
||
tracks downward and reposition following clips and instrument selectors.
|
||
- [x] Draw velocity bars for visible note starts in each track's MIDI clips,
|
||
respecting clip offsets, timeline zoom and scrolling.
|
||
- [x] Drag a bar's cap vertically to preview and commit velocity (1–127), preserving
|
||
note timing, pitch and channel; Escape cancels and undo/redo restores edits.
|
||
- [x] Preserve expansion by track ID through reordering and ordinary edits;
|
||
reset it on project replacement. Expansion is temporary GUI state.
|
||
- [x] Verify real FLTK arrow gestures, lane edits, coincident notes, cancellation,
|
||
undo/redo, shifted clip selection and track reordering in GUI integration tests.
|
||
- [x] Update README guidance and capture actual expanded and compact sequencer
|
||
screenshots; regenerate the promotional overview.
|
||
|
||
### Implementation status
|
||
|
||
Implemented on 2026-11-06 in the FLTK sequencer using the existing C API; no
|
||
engine or project-format changes. Audio-only tracks and buses can expand but
|
||
have no MIDI note bars. Notes beginning before a trimmed clip's visible source
|
||
range are omitted. Coincident notes with different velocities can be selected
|
||
by their caps; fully overlapping caps select one note, with individual editing
|
||
still available in the piano roll. Track expansion is not saved in projects.
|
||
|
||
Validation: warning-enabled CMake build, CTest GUI integration and offline
|
||
checks, plus rendered screenshot inspection. See [the gallery](../screenshots/README.md).
|
||
|
||
---
|
||
|
||
## Phase 110 — Continuous Audio Velocity Editing in the Sequencer
|
||
|
||
### Goal
|
||
|
||
Extend the sequencer's downward-expanding velocity lanes to audio tracks, with
|
||
level editing at arbitrary timeline positions using the existing C gain
|
||
automation, playback, persistence and history contracts.
|
||
|
||
### Tasks and acceptance criteria
|
||
|
||
- [x] Display a connected audio level envelope beneath audio tracks using the
|
||
same disclosure arrows and row layout as MIDI velocity lanes.
|
||
- [x] Add points anywhere, independently of snap and note positions; drag caps
|
||
vertically to adjust gain between silence and 400%, and right-click to remove.
|
||
- [x] Preview edits locally, cancel with Escape, and commit once per gesture
|
||
through the arrangement edit hook and undo/redo publication path.
|
||
- [x] Share saved gain automation with the mixer, respecting existing Linear/Hold
|
||
segments and preserving interpolation mode when editing an existing point.
|
||
- [x] Verify off-grid point creation, edits, clamping, removal, cancellation,
|
||
undo/redo, save/reopen and rendered audio levels in GUI integration tests.
|
||
- [x] Capture the real audio envelope beside MIDI velocity bars, add it to the
|
||
complete screenshot gallery and document the workflow.
|
||
|
||
### Implementation status
|
||
|
||
Implemented on 2026-11-06 without engine, dependency or project-format changes.
|
||
Audio velocity controls track gain (0–4 linear, displayed as 0–400%); it is not
|
||
MIDI note velocity. Empty tracks, buses and tracks containing audio display the
|
||
gain envelope; tracks containing only MIDI retain their note velocity bars.
|
||
On mixed audio/MIDI tracks the gain envelope affects both sources, and individual
|
||
MIDI velocities remain editable in the piano roll. Automation replaces static
|
||
track gain and holds its first/last values beyond its endpoints. New points use
|
||
Linear interpolation; existing Hold segments remain supported. An initial point
|
||
therefore sets the whole track's level until further points shape the curve.
|
||
Points stay at their timeline position during vertical drags; add/remove points
|
||
to change timing. The existing project-wide 1024-point automation limit applies.
|
||
Envelope edits are saved; track disclosure state remains temporary GUI state.
|
||
|
||
Validation: warning-enabled CMake build, CTest checks including real FLTK
|
||
lane gestures and comparison of rendered audio against the unautomated source,
|
||
and inspection of the actual [audio envelope capture](../screenshots/audio-velocity-expanded.png).
|
||
|
||
---
|
||
|
||
## Phase 111 — Sequencer Master and Child Widgets
|
||
|
||
### Goal
|
||
|
||
Split the sequencer GUI into focused components. Keep `SequencerWidget` as the
|
||
master with real nested FLTK track, header, clip, velocity and ruler widgets,
|
||
preserving current editing behavior, the C domain boundary and saved projects.
|
||
|
||
### Tasks and acceptance criteria
|
||
|
||
- [x] Make the master own ruler and track groups; each track owns its header,
|
||
instrument selector, clip widgets and velocity lane through FLTK ownership.
|
||
- [x] Move child drawing and local input into dedicated track/header, clip,
|
||
velocity and ruler implementation files. Keep shared coordinates, selection,
|
||
scrolling and cross-track gesture completion in the master.
|
||
- [x] Extract editing commands/dialogs, instrument support and waveform caching
|
||
into separate source files and register them explicitly in CMake.
|
||
- [x] Reconcile views by stable C IDs, preserving surviving track identity through
|
||
reorder/undo and moving clip views into the destination track hierarchy.
|
||
- [x] Cancel gestures on project replacement and defer removed widget deletion
|
||
until event handlers can return; preserve instrument focus and shortcuts.
|
||
- [x] Exercise real parent/child membership, cross-track movement, velocity edits,
|
||
undo/redo, removal and project replacement through GUI integration tests,
|
||
including FLTK window-level event dispatch.
|
||
- [x] Update the architecture/component map, GUI guide, build guidance, README
|
||
and integration-test documentation.
|
||
|
||
### Implementation status
|
||
|
||
Implemented on 2026-11-06. The master now delegates track/header, clip, velocity
|
||
and ruler drawing/input to child classes; commands and support code are separate
|
||
translation units. See [the ownership and source map](ARCHITECTURE.md#sequencer-widget-ownership).
|
||
FLTK owns the hierarchy; indexes and captured-gesture pointers are borrowed.
|
||
Child views hold copied C metadata rather than pointers into project snapshots.
|
||
Removed children are detached/hidden and deleted through FLTK's deferred queue.
|
||
The master remains the single selection and edit/publication coordinator.
|
||
|
||
No dependency, core API, persistence or intended visual/workflow change is
|
||
introduced. Existing screenshots continue to describe the same interface.
|
||
Validation: the warning-enabled CMake build succeeds, all 55 existing CTests
|
||
pass, and the added `gui-sequencer` hierarchy/dispatched-gesture check passes.
|
||
The final build's main GUI and focused hierarchy tests were also rerun successfully.
|
||
The focused hierarchy/lifetime test passes Clang ASan/UBSan with leak detection
|
||
disabled for the unsanitized system FLTK library. Both audio-envelope captures
|
||
remain pixel-identical to the existing gallery. Physical hardware qualification
|
||
is unaffected.
|
||
|
||
---
|
||
|
||
## Phase 112 — Playback without production MIDI devices
|
||
|
||
### Tasks and acceptance criteria
|
||
|
||
- [x] Reproduce the playback failure caused by disconnected saved MIDI devices.
|
||
- [x] Skip unavailable MIDI input/output routes in the GUI without changing saved
|
||
preferences; connect available counterparts and retry devices on each start.
|
||
- [x] Show a nonblocking warning while allowing built-in instruments and audio
|
||
playback. Preserve genuine enumeration, activation and routing failures.
|
||
- [x] Add a self-contained four-bar `examples/projects/playback-test.xtc` song.
|
||
- [x] Cover absent input/output/both, returning devices, retained preferences and
|
||
real backend failures in the fake-backend GUI regression.
|
||
- [x] Verify the example offline and test real Play/Stop/Space, playhead movement
|
||
and finite nonzero stereo output through a private JACK software probe.
|
||
- [x] Update MIDI/preferences help, example and integration-test documentation.
|
||
|
||
### Implementation status
|
||
|
||
Implemented on 2026-11-06. The saved-device failure was reproduced with the live
|
||
GUI test before the fix. GUI starts now enumerate optional MIDI routes before
|
||
calling the strict backend start API. Missing devices warn without preventing
|
||
playback; the C backend API retains its strict routing contract. No settings
|
||
format or audio callback changes are required. The example uses only a built-in
|
||
sine instrument, needs no external files or plugins, and renders eight seconds
|
||
at 120 BPM. Audio outputs still require normal JACK routing to hear speakers.
|
||
The live regression connects only to a private software probe and uses temporary
|
||
preferences; no physical listening/hardware qualification is claimed.
|
||
|
||
Validation: the warning-enabled CMake build and all 57 default CTests passed,
|
||
including offline example rendering and GUI MIDI-device regressions. The live
|
||
Play/Stop/Space/stereo check also passed. See the integration-test guide for commands.
|
||
|
||
---
|
||
|
||
## Phase 113 — Optional JUCE workstation frontend
|
||
|
||
### Tasks and acceptance criteria
|
||
|
||
- [x] Preserve the FLTK sources and default build; add an independently optional
|
||
`XTC_BUILD_JUCE_GUI` workstation under `src/gui/JUCE`.
|
||
- [x] Require a user-supplied SDK through `XTC_JUCE_ROOT`, with an explicit error
|
||
when enabled without the SDK and no SDK discovery/download in normal builds.
|
||
- [x] Port the main window, sequencer/master and child views, graph, mixer,
|
||
automation, piano roll, velocity editing, sample editor, plugin dialogs,
|
||
insert chains, preferences, searchable commands and support widgets.
|
||
- [x] Use JUCE components, controls, graphics, native events, dialogs and timers;
|
||
keep project/history/DSP/backend/plugin APIs in C and preserve `.xtc` files.
|
||
- [x] Allow JUCE-only, FLTK-only, both and core-only configurations; share the
|
||
externally supplied SDK with the independently optional plugin examples.
|
||
- [x] Include the JUCE binary in the owned install/uninstall inventory when selected.
|
||
- [x] Pass the retained GUI regression workflows against JUCE, including failure
|
||
rollback, child ownership, gestures, preferences and MIDI device fallback.
|
||
- [x] Verify native JUCE transport events and finite stereo playback with the
|
||
bundled test song and missing saved MIDI devices.
|
||
- [x] Validate the original FLTK build/tests and document final build results.
|
||
|
||
### Implementation notes
|
||
|
||
The frontend retains the original C-facing command structure and filenames.
|
||
`ui.*` maps the retained coordinates and callback conventions to JUCE, with no
|
||
FLTK headers or runtime dependency. Native controls may look different. Both
|
||
frontends continue to use the existing JACK/PipeWire backend. See the
|
||
[frontend source and build guide](../src/gui/JUCE/README.md).
|
||
JUCE is an optional external AGPLv3/commercial SDK; normal builds do not link it.
|
||
Qualification is for Linux, rather than a new cross-platform audio backend.
|
||
The original 57 FLTK/core tests, core-only build, missing-SDK diagnostic, shared
|
||
SDK configuration and staged install/uninstall checks passed. The frontend was
|
||
built with warnings enabled against external JUCE 8.0.15. Native Play/Stop/Space,
|
||
expanded track rendering and finite stereo playback passed with missing saved
|
||
MIDI devices. All 12 JUCE GUI workflows passed, with focused reruns after the
|
||
native focus/blur adjustments. The [workstation capture](../screenshots/juce-workstation.png)
|
||
comes from this real-backend regression, with no physical routes changed.
|
||
|
||
---
|
||
|
||
## 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.
|