Chimera Amp Matrix Entwicklungslog Vol.1
| Code | BN01 |
|---|---|
| Projekt | SpectralForge — Chimera Amp Matrix |
| Fokus | Routing-Architektur · JUCE / CMake · Classic / Dual / Matrix · LR4-Crossover · Matrix Band Tone · CI / Test-Artefakt |
| Source of record | GitHub Repository · PR #2 v1.0/rebuild · GitHub Actions |
| Status | 1.0-Testbuild-Entwicklung. Run #111 auf allen Plattformen grün; im aktuellen Run #112 ist die Windows-UI-Verifikation noch offen. |
| Datum | 2026-09-23 |
1. Ausgangspunkt — Routing selbst zum Instrument machen, statt nur einen weiteren Amp hinzuzufügen
Chimera begann nicht mit dem Ziel, einfach mehr Amp-Modelle anzubieten. Entscheidend war, drei tatsächlich verschiedene Architekturen in einem Produkt abzubilden: ein konventionelles Full-Range-Rig, zwei vollständige Full-Range-Rigs parallel und ein frequenzgeteiltes System, in dem unterschiedliche Amp/Cab-Ketten unterschiedliche Spektralbereiche übernehmen.
Die erste 1.0-Frage lautete deshalb nicht „ist der Amp-Klang fertig?“, sondern implementieren die drei Modi wirklich unterschiedliche Signal-Topologien? Pre/Post FX, Voicing, Presets und IR-Workflows müssen auf diesem Vertrag aufbauen.
2. Classic, Dual und Matrix dürfen nicht nur drei unterschiedlich benannte Presets sein
| Mode | Signal | Lanes | Tone Control | Crossover |
|---|---|---|---|---|
| Classic | Full-Range | 1 | Full-Range-Amp-EQ + Presence / Resonance | kein |
| Dual | Full-Range × 2 parallel | 2 | Full-Range-Amp-EQ je Rig | kein |
| Matrix | LOW / MID / HIGH Split | 3 | Drive · Level · bandbezogener Tone | LR4, 24 dB/Okt., zwei Übergänge |
Im aktuellen Engine läuft Classic über eine Full-Range-Lane. Dual kopiert dasselbe Eingangssignal in zwei Full-Range-Lanes und summiert sie parallel. Nur Matrix verwendet den Crossover. Die Default-Referenzpunkte liegen ungefähr bei 150 Hz und 1,2 kHz; beim Verschieben ändern sich die tatsächlichen Eingangsbereiche der LOW-, MID- und HIGH-Lanes.
3. Erster UI-Fehler — verschiedene Engines wirken gleich, wenn die Oberfläche gleich aussieht
Die erste Testoberfläche stellte Funktionen schnell über wiederverwendbare Lane-Panels bereit. Dadurch sahen Classic, Dual und Matrix jedoch zu ähnlich aus. Es war nicht klar genug, welches Signal eine Lane erhält, wann ein Crossover überhaupt relevant ist und warum ein Single-Rig-Modus wie eine Matrix aussehen sollte.
Die Revision zeigt in Classic ein FULL-RANGE RIG, in Dual FULL-RANGE RIG A/B und in Matrix LOW / MID / HIGH BAND. Crossover-Regler sind nur in Matrix sichtbar; jede Matrix-Lane zeigt zusätzlich ihren aktuell aus den Crossover-Werten abgeleiteten Eingangsbereich.
4. Warum Matrix zunächst den 4-Band-EQ erbte — und warum er wieder entfernt wurde
Die ersten Matrix-Lanes übernahmen fast den gesamten Classic/Dual-Amp-Strip: Drive, Level, Bass, Low Mid, High Mid, Treble, Presence und Resonance. Für die Implementierung war das bequem, weil die vorhandene Amp-Tone-Stage einfach weiterverwendet werden konnte.
Matrix begrenzt eine Lane jedoch bereits am Eingang auf einen Spektralbereich. Ein Full-Range-4-Band-EQ auf einer reinen LOW-Lane erzeugt Regler für Energie, die möglicherweise gar nicht in die Lane gelangt, und verwischt die Rollen von Crossover und Klangformung.
4.1 Band Tone ist kein weiterer Crossover
Der Ersatzregler heißt Band Tone. Er ist weder ein zusätzlicher Bandpass noch ein dritter Übergangspunkt, sondern ein bandbezogener Tilt nach dem Split und vor der Amp-Verzerrung. Negative Werte verschieben die Balance dunkler, positive heller.
Der Pivot folgt dem geometrischen Zentrum des durch die aktuellen Crossover-Werte definierten Bereichs und ist nicht auf eine feste Frequenz gesetzt. Dadurch ändert sich beim Verschieben des Crossovers sowohl der Eingangsbereich der Lane als auch der Referenzpunkt des Tone-Reglers. Die Full-Range-EQ-Parameter von Classic/Dual bleiben im State erhalten und werden in Matrix nur bypassed.
5. Über „bei mir kompiliert es“ hinaus — auch die Build-Pipeline ist Teil des Produkts
Der erste Bootstrap-PR wurde verworfen; PR #2 startete sauber von main als v1.0/rebuild.
Das Ziel war nicht nur Quellcode, sondern ein reproduzierbarer Prozess, der auf einer anderen Maschine ein testbares Artefakt erzeugt.
| Layer | 1.0-Testfundament |
|---|---|
| Framework | JUCE 8.0.8 · C++20 · CMake 3.22+ |
| Formate | VST3 + Standalone · AU unter macOS |
| CI | Windows / Ubuntu / macOS Matrix Build |
| DSP-Verifikation | ChimeraTests über CTest |
| Windows-UI-Verifikation | ChimeraUITests + gerenderte UI-Snapshots |
| Distributionstest | Windows ZIP + SHA256-Manifest |
Unter Windows wurde außerdem das normale Warnverhalten für ein unsigniertes Development-Binary in Chrome/SmartScreen sichtbar. Der Testbuild wird deshalb ausdrücklich als unsigned gekennzeichnet und zusammen mit einem SHA256-Manifest ausgeliefert.
6. Erster vollständiger Checkpoint — Run #111
Run #111 bestand Build und CTest auf Windows, Ubuntu und macOS. Der Windows-Job erzeugte zusätzlich
Chimera-Amp-Matrix-1.0.0-test-win64.zip und das zugehörige SHA256-Manifest.
Damit existierte erstmals nicht nur Source, sondern ein reproduzierbares, getestetes und herunterladbares 1.0-Testartefakt.
7. Nach dem Erfolg wieder brechen — aktuelle Windows-Regression in Run #112
Nach #111 wurde der Full-Range-EQ in Matrix durch Band Tone ersetzt und die mode-spezifische Sichtbarkeit der Controls neu aufgebaut.
Der aktuelle Code baut auf Ubuntu und macOS und besteht dort CTest. Auch Windows kompiliert erfolgreich und rendert die UI-Snapshots,
aber ChimeraUITests scheitert mit „Wrong controls for routing mode“. Der Packaging-Schritt wird deshalb absichtlich nicht ausgeführt.
Zum Zeitpunkt dieses Logs ist die Regression offen. ChimeraTests für den DSP bestehen,
wodurch sich der Fehler auf den Vertrag zwischen neuer mode-spezifischer UI und den Windows-UI-Test-Erwartungen eingrenzen lässt.
Der nächste Schritt ist die konkrete Visibility-/State-Abweichung zu beheben und nicht den Test zu umgehen.
8. Aktuelle Designposition und Übergabe an Vol.2
Vol.2 soll diesen Vertrag stabilisieren, bevor die Feature-Liste wächst:
- Windows-Regression in
ChimeraUITestsbeheben und den nächsten vollständig grünen Build erreichen; - automatisierte Tests für Crossover-Summe, Phase und Pegelkonsistenz bei bewegten Übergangspunkten erweitern;
- Lane-Latenz, Oversampling und Merge-Alignment verifizieren;
- Pre FX / Post FX als echte Modulkette ausbauen, ohne die Mode-Grenzen aufzuweichen;
- Amp/Cab-Voicing und IR-Workflow über wiederholbare Referenzen und A/B-Validierung statt nur über Modellanzahl entwickeln.