Chimera Amp Matrix Development Log Vol.1
| Code | BN01 |
|---|---|
| Project | SpectralForge — Chimera Amp Matrix |
| Focus | routing architecture · JUCE / CMake · Classic / Dual / Matrix · LR4 crossover · Matrix Band Tone · CI / test artifact |
| Source of record | GitHub repository · PR #2 v1.0/rebuild · GitHub Actions |
| Status | 1.0 test-build development. Run #111 all-platform green; latest Run #112 Windows UI-verification regression remains open. |
| Date | 2026-09-23 |
1. Starting point — make routing itself the instrument, not merely add another amp
Chimera did not begin as a plan to increase the number of amp models. The central problem was to put three genuinely different architectures in one product: a conventional full-range rig, two complete full-range rigs in parallel, and a frequency-split system in which different amp/cab chains can own different portions of the spectrum.
The first 1.0 question was therefore not “does the amp sound finished?” but do the three modes actually implement different signal topologies? Pre/Post FX, voicing, presets and IR workflows must sit on top of that contract rather than compensate for an unclear router.
2. Classic, Dual and Matrix cannot be three presets with different names
| Mode | Signal | Lanes | Tone control | Crossover |
|---|---|---|---|---|
| Classic | full-range | 1 | full-range amp EQ + presence / resonance | none |
| Dual | full-range × 2 parallel | 2 | full-range amp EQ per rig | none |
| Matrix | LOW / MID / HIGH split | 3 | Drive · Level · band-relative Tone | LR4, 24 dB/oct, two crossover points |
In the current engine, Classic runs one full-range lane. Dual copies the same input into two full-range lanes and sums them in parallel. Only Matrix invokes the crossover. The default reference points are around 150 Hz and 1.2 kHz, and moving them changes the input range owned by each LOW, MID and HIGH lane.
3. First UI failure — different engines still look identical when the screen does
The first test interface exposed functionality quickly around reusable lane panels. The problem was that Classic, Dual and Matrix looked too similar. The screen did not clearly communicate what each lane was receiving, when a crossover mattered, or why a single-rig mode should resemble a three-column matrix.
The revised interface shows one FULL-RANGE RIG in Classic, FULL-RANGE RIG A/B in Dual, and LOW / MID / HIGH BAND in Matrix. Crossover controls exist visually only in Matrix, while each Matrix lane displays the actual input range derived from the current crossover values.
4. Why Matrix inherited a four-band EQ — and why it had to lose it
The first Matrix lanes inherited almost the entire Classic/Dual amp strip: Drive, Level, Bass, Low Mid, High Mid, Treble, Presence and Resonance. That was implementation-friendly because the existing amp tone stage could simply be called for every lane.
But Matrix has already restricted each lane to a portion of the spectrum. A full-range four-band EQ on a LOW-only lane creates controls for energy that may not even enter the lane, and it blurs the conceptual boundary between crossover placement and tone shaping. More controls looked more flexible while making the responsibility of each lane less legible.
4.1 Band Tone is not another crossover
The replacement control is Band Tone. It is not another band-pass stage or a third crossover point. It is a band-relative tilt placed after the split and before amp distortion. Negative values bias the band darker; positive values bias it brighter.
Its pivot follows the geometric center of the range defined by the live crossover values instead of using a single fixed frequency. Moving the crossover therefore changes both the lane's actual input range and the reference point of its Tone control. Classic/Dual full-range EQ parameters are retained in state and merely bypassed in Matrix so mode switching does not destroy prior settings.
5. Beyond “it compiles on my machine” — the build pipeline is part of the product
The initial bootstrap PR was abandoned, and PR #2 restarted cleanly from main as v1.0/rebuild.
The target was not just source code, but a repeatable pipeline capable of producing a testable artifact on another machine.
| Layer | 1.0 test foundation |
|---|---|
| Framework | JUCE 8.0.8 · C++20 · CMake 3.22+ |
| Formats | VST3 + Standalone · AU on macOS |
| CI | Windows / Ubuntu / macOS matrix build |
| DSP verification | ChimeraTests through CTest |
| Windows UI verification | ChimeraUITests + rendered UI snapshots |
| Distribution test | Windows ZIP + SHA256 manifest |
Windows also exposed the normal warning behavior of an unsigned development binary in Chrome/SmartScreen. Rather than present the test package as a signed production release, the package README explicitly identifies it as unsigned and ships a SHA256 manifest for integrity checking.
6. First complete checkpoint — Run #111
Run #111 passed build and CTest on Windows, Ubuntu and macOS. The Windows job also produced the packaged
Chimera-Amp-Matrix-1.0.0-test-win64.zip and its SHA256 manifest.
This was the first point at which the project had more than source code: it had a reproducible, tested and downloadable 1.0 test artifact.
7. Break it again after success — the current Run #112 Windows regression
After #111, the Matrix full-range EQ was replaced by Band Tone and the mode-specific visibility/label model was rewritten.
The latest code builds and passes CTest on Ubuntu and macOS. Windows also compiles successfully and produces the UI snapshots,
but ChimeraUITests fails with “Wrong controls for routing mode”. Packaging is therefore intentionally skipped.
At the time of this note the regression is still open. The DSP smoke suite ChimeraTests passes,
which narrows the problem away from a basic engine compile failure and toward the contract between the new mode-specific UI and the Windows UI test expectations.
The next step is to resolve the exact visibility/state mismatch and restore a green build rather than bypass the test.
8. Current design position and what moves to Vol.2
Vol.2 should stabilize this contract before expanding the feature list:
- fix the Windows
ChimeraUITestsrouting-mode visibility regression and obtain the next all-green build; - strengthen automated tests for crossover summing, phase and level consistency while crossover points move;
- verify lane latency, oversampling and merge alignment;
- extend Pre FX / Post FX into a real module chain without weakening mode boundaries;
- develop amp/cab voicing and IR workflow around repeatable references and A/B validation rather than model count alone.