RAVENFORGE

SPECTRALFORGE / BENCH NOTES / BN02

SpectralForge Chimera Entwicklungstagebuch Teil 2

Neu gefasste Entwicklungsmaßstäbe bei der Erweiterung eigener Amp- und Cabinet-Modelle

12. Oktober 2026 · Berichtszeitraum: 23. September bis 12. Oktober 2026

Abbildung 1. Matrix-Ansicht des Presets Crom Cruach mit den Verstärkern und Boxen für die LOW-, MID- und HIGH-Rigs. Tatsächliche Aufnahme einer nativen UI-Komponente unter Linux aus Chimera 1.3.1-beta.1. ^[12]

Im ersten Entwicklungstagebuch habe ich festgehalten, wie Classic, Dual und Matrix als unterschiedliche Signalstrukturen umgesetzt wurden. Dabei ging es darum, die Aufgaben eines einzelnen Rigs, zweier paralleler Rigs und eines in drei Frequenzbänder aufgeteilten Rigs zu bestimmen und diese Unterschiede auch in der Oberfläche erkennbar zu machen. Am Ende standen die nächsten Aufgaben: die tatsächlichen PRE- und POST-Ketten sowie die Klangabstimmungen von Amps und Cabinets erweitern und wiederholbare Vergleichsbedingungen schaffen. ^[1]

Seitdem hat Chimera eigene Gitarren- und Bassverstärker sowie Cabinet- und Mikrofonmodelle erhalten und die öffentliche Beta 1.3.1 erreicht. Im Mittelpunkt dieses Eintrags stehen die Entwurfsentscheidungen, die sich auf diesem Weg verändert haben. Eigenständige Reaktionen der Kanäle, Verzerrung bei erhaltenem Bassfundament und die Übereinstimmung zwischen Klangbedienung und tatsächlicher Audioverarbeitung wurden zu konkreten Entwicklungsaufgaben. ^[7]

1 Sofort brauchbare Grundeinstellungen nach der Amp-Auswahl

Mit dem Ausbau der PRE- und POST-Effekte und der Presets wurde der Ausgangspunkt für ein tatsächlich nutzbares Rig wichtiger. Wenn ein High-Gain-Amp mit zu wenig Gain startet oder ein Preset-Wechsel einen großen Lautstärkesprung verursacht, muss der Nutzer zuerst die Einstellungen korrigieren, bevor sich der Klangcharakter vergleichen lässt. Die Grundeinstellungen mussten deshalb Teil der Klangabstimmung des Produkts werden.

Für 1.1.2 habe ich Sättigung und Kompression bei schwachen Eingangssignalen erneut gemessen und die High-Gain-Grundeinstellungen angepasst. Als Vergleichsbasis dienten 174 NAMs aus 22 Modellfamilien. Die Referenzen wurden mit dem offiziellen NAM Core gerendert und den Reaktionen der nativen Amps von Chimera gegenübergestellt. ^[2]

Dabei habe ich auch die Aussagegrenzen der Referenzen festgehalten. Selbst innerhalb derselben Verstärkerfamilie hat ein Capture je nach Kanal, Modifikation und Abgriff am Vorverstärkerausgang oder am Ausgang des vollständigen Verstärkers eine andere Bedeutung. Ich habe unterschieden, welche Aspekte sich mit dem vorhandenen Material kalibrieren ließen und welche mangels einer exakten Referenz offenbleiben mussten. Chimeras Engine wurde durch diese Arbeit nicht auf die Wiedergabe von NAMs umgestellt. ^[2]

Der in dieser Phase festgelegte Maßstab war, zuerst die Vergleichsbedingungen anzugleichen. Bei unterschiedlichen Ein- oder Ausgangspegeln wird der lautere Klang leicht als der bessere wahrgenommen. Gain-Struktur und Grundlautstärke müssen zunächst mit wiederholbaren Eingangssignalen geprüft werden. Anschließend ist beim Spielen echter Instrumente zu überprüfen, ob die Ergebnisse Bestand haben.

2 Die Maßstäbe hinter den Kanälen von Náströnd und Niflheimr

Bei den eigenen Amps musste es einen klaren Grund geben, den Kanal zu wechseln. Die fünf Kanäle von Náströnd wurden so entwickelt, dass sie sich in Anschlagsreaktion, Kompression, Dichte der unteren Mitten und Ausklingverhalten unterscheiden. Ausgehend von Fenrirs schneller, straffer Reaktion habe ich die interne Verteilung des Drives und den Frequenzgang so angepasst, dass die anderen Kanäle Mitten für Leads, einen rauen Grind, eine langsame Erholung und tiefen Druck im Anschlag entfalten. ^[3]

Anfangs unterschieden sich die Kanäle nicht ausreichend; Fenrir wirkte lauter, und Fimbulvetr klang dumpf. Während Fenrir unverändert blieb, habe ich die Pegel der anderen Kanäle korrigiert und bei Fimbulvetr sowohl die Betonung der unteren Mitten vor der Verzerrung als auch die Höhendämpfung reduziert. Ziel war ein erkennbarer Anschlag bei erhaltener langsamer Erholung. Dabei entstand auch die Regel, OUTPUT in den Presets auf 0 dB zu setzen. Das ist die Referenzeinstellung des Ausgangsreglers und bedeutet keine Normalisierung des Signals auf 0 dBFS. ^[3]

Abbildung 2. Náströnd mit ausgewähltem Fenrir-Kanal in der vergrößerten Frontansicht. Zu sehen sind die fünf Kanalwahlen sowie die tatsächlichen Regler und Beschriftungen zur Laufzeit. Native UI-Komponentenaufnahme unter Linux aus 1.3.1-beta.1. ^[13]

Beim Bassverstärker Niflheimr war ein zentrales Problem, dass starke tiefe Frequenzen die Verzerrungsstufen und Detektoren so stark anregten, dass auch die oberen Frequenzbereiche verwaschen wurden. Die Bässe nach der Verzerrung wieder hinzuzufügen konnte die bereits entstandenen Wechselwirkungen zwischen den Frequenzbereichen nicht rückgängig machen. Deshalb habe ich den Pfad zum Erhalt des Bassfundaments von den klangformenden BODY- und EDGE-Pfaden getrennt und das Signal vor dem Eintritt in die Verzerrungsstufen aufbereitet. ^[4]

Das bisherige Verhalten von Hrímfaxi und Nidavellir blieb erhalten. Garmr, Ymir und Hel wurden dagegen aufgrund der Rückmeldungen zur mangelnden Klarheit überarbeitet. Dabei sollte Hels langsame, dichte Reaktion nicht in das Verhalten eines schnellen Kanals umgewandelt werden. Die Überarbeitung beschränkte sich darauf, die Konturen der Töne zu verbessern und zugleich die jeweilige Aufgabe der Kanäle zu bewahren. ^[4]

Abbildung 3. Niflheimr mit ausgewähltem Hrímfaxi-Kanal in der vergrößerten Frontansicht. Die frontseitigen Bedienelemente einschließlich BLEND gehören zur Produkt-UI. Native UI-Komponentenaufnahme unter Linux aus 1.3.1-beta.1. ^[13]

Auch der BLEND-Regler von Niflheimr ist innerhalb dieser Struktur zu verstehen. Er mischt einen aufbereiteten CLEAN-Pfad mit dem verzerrten Pfad und entspricht nicht dem Anteil eines unveränderten DI-Signals, das den Verstärker umgeht. Position und Aufgabe unterscheiden sich außerdem von der separaten DI/AMP-Mischung in Matrix LOW. ^[4]

3 Strukturelle Grenzen beim NAM-Training

Die Entwicklung mit Bezug zu NAM umfasst zwei getrennte Arbeitsstränge. Der zuvor beschriebene Vergleich mit externen NAMs dient der Kalibrierung der nativen Amps. Das parallel laufende Náströnd-NAM-Projekt erfasst dagegen die bereits entwickelte eigene Engine und trainiert fünf NAMs, die deren Verhalten für den Export nachbilden sollen. ^[2] [5]

Im zusätzlichen Trainingsexperiment vom 11. Oktober wurde die ESR verglichen, also das Verhältnis der Fehlerenergie zur Energie des Referenzsignals. Die mittlere ESR bei den neuen Testeingaben sank von 0,099505 auf 0,088075. Das entspricht einer Verringerung des Fehlers um 11,49 %. Dennoch verfehlten alle fünf Kanäle die vollständigen Anforderungen an die Wiedergabetreue. Ein erfolgreicher Dateiexport und eine erfolgreiche Rekonstruktion in der vorgesehenen Ziel-Engine belegten für sich genommen noch keine ausreichend genaue Nachbildung des Klangs. ^[5]

Abbildung 4. Mittlerer ESR vor und nach dem zusätzlichen Náströnd-A2-Training, über fünf Kanäle mit neuen Testsignalen gemittelt. ESR ist die Fehlerenergie geteilt durch die Energie des Referenzsignals. Die 11,49 % bezeichnen eine Fehlerreduktion, weder eine Ähnlichkeit noch eine Bestehensquote. Alle fünf Kanäle verfehlen weiterhin die vollständigen Kriterien der Wiedergabetreue. ^[5]

Bei Fimbulvetr zeigte sich außerdem ein Abschnitt, der sich nicht allein durch längeres Training lösen ließ. In einer bestimmten Ausklingphase war die gesamte Eingangshistorie, auf die A2 als die hier verwendete NAM-Modellarchitektur zugreifen kann, bereits null, während der Originalklang weiter ausklang. Für diese Eingabe und unter den festgelegten Bewertungskriterien konnte die gegenwärtige A2-Architektur mit ihrer begrenzten Gedächtnislänge die Anforderung nicht erfüllen. ^[5]

Die nächsten Versuche müssen deshalb auch Architekturen mit längerem Gedächtnis oder Ansätze mit rekursiven Filtern prüfen. Diese Schlussfolgerung lässt sich nicht auf jeden Kanal und jedes Eingangssignal übertragen. Sie setzt aber der Annahme eine klare Grenze, das aktuelle Paket aus fünf Kanälen könne allein durch zusätzliche Trainingsdurchläufe die Anforderungen erfüllen. Die Veröffentlichung der trainierten Modelle und die Hörbewertung mit echten Instrumenten stehen noch aus. ^[5]

4 Cabinets und Mikrofone direkt kombinieren

Bei der Cabinet-Entwicklung wollte ich eine Struktur schaffen, in der Nutzer Lautsprecher, Mikrofone und Abnahmepositionen direkt auswählen und einstellen können. Ergänzend zum IR-Loader, in dem eine Datei ausgewählt wird, habe ich den eigenen CAB-Pfad ausgebaut. Änderungen innerhalb des Cabinets sollten dadurch sowohl in der Oberfläche als auch im Klang nachvollziehbar werden.

Das aktuelle Modell definiert unter anderem Resonanz und Dämpfung des Lautsprechers, sein Hochtonverhalten sowie Frequenzeigenschaften und Nahbesprechungseffekt des Mikrofons jeweils separat. Für Mic A und Mic B lassen sich unterschiedliche Mikrofone wählen und auf denselben oder auf verschiedene Lautsprechertreiber ausrichten. Position und Abstand gehen in die tatsächliche Berechnung des Frequenzgangs ein. Die Oberfläche zur Platzierung der beiden Mikrofone und der DSP beziehen sich damit auf dieselben Objekte. ^[6]

Auch die Proportionen der Cabinets und die Anordnung der Lautsprecher wurden überarbeitet. Mit der 6×10-Konfiguration und festgelegten kompatiblen Lautsprecherdurchmessern pro Cabinet wurden Unstimmigkeiten beseitigt, etwa ein Gehäuse, das allein durch die Auswahl eines anderen Lautsprechers größer wurde. Ein gemeinsamer Maßstab für Verstärkerköpfe und Cabinets, die Darstellung der Lautsprecher von vorn sowie Hörner und Gehäusematerialien waren für eine nachvollziehbare Auswahl und Bedienung erforderlich. ^[11]

Abbildung 5. Schematisches Beispiel für Mic A und Mic B an verschiedenen Lautsprechern einer 6×10-Box. Beide können auch denselben Lautsprecher anvisieren. Dargestellt sind nur die unabhängigen Einstellungen von Mikrofontyp, Lautsprecher, Position und Abstand. Die Grafik ist weder eine tatsächliche UI noch eine vermessene Maß- oder Frequenzgangzeichnung. Raumakustik bleibt eine spätere Entwicklungsaufgabe. ^[6] [11]

Diese Umsetzung ist ein lineares Modell reduzierter Ordnung auf der Grundlage selbst festgelegter numerischer Annahmen. Sie ist weder eine vollständige Nachbildung eines bestimmten vermessenen Cabinets noch ein Modell, das auch die thermische Kompression der Lautsprecher berücksichtigt. Die Räume in Dual und Matrix dienen derzeit der Anordnung von Geräten und dem Öffnen ihrer Detailansichten. Eine Raumakustik, die Reflexionen und Nachhall berechnet, bleibt Gegenstand späterer Entwicklung. ^[6] [10]

Der IR-Loader behält seine eigene Aufgabe. Eine importierte IR ist eine Aufzeichnung mit bereits festgelegten Abnahmebedingungen. Sie lässt sich daher nicht auf dieselbe Weise neu mikrofonieren, wie eine Mikrofonbewegung in der eigenen CAB-Oberfläche das Modell verändert. Die Oberfläche muss deutlich machen, welchen Pfad der Nutzer gerade bearbeitet. ^[6]

5 Den Klang direkt an der Verstärkerfront einstellen

Mit der konkreteren Ausarbeitung der Verstärkerkopf-Bilder wurden auch Unstimmigkeiten der Bedienelemente sichtbar. Der Verstärkerkopf wirkte räumlich, während seine Regler flach und losgelöst erschienen. Unterschiedliche Reglergrößen und Abstände zwischen den Modellen erschwerten zudem die Lesbarkeit. Auch die oberen Gehäuseecken, die Griffe und die Tiefenwirkung mussten überarbeitet werden. ^[7]

In 1.3.1 wurde für Classic, Dual und Matrix ein Ablauf umgesetzt, bei dem sich ein Verstärkerkopf auswählen und vergrößern lässt, um seine Frontregler direkt zu bedienen. Form und Materialwirkung der Regler wurden auf das jeweilige Modell abgestimmt und die Kontraste der Beschriftungen angepasst. Zahlenwerte erscheinen während der Bedienung oder bei direkter Eingabe. Die wesentlichen Eingriffe erfolgen an der Front, von dort führen die Wege zu den detaillierten Bedienelementen. ^[7]

Signal Path zeigt derzeit die Verzweigungen und Zusammenführungen des Signals und führt zur jeweiligen Bearbeitungsansicht. Die detaillierte Darstellung des Signalwegs sorgt allerdings dafür, dass auch Hilfsfunktionen wie Gate und Transpose in der Standardansicht zu viel Raum einnehmen. Für eine spätere Überarbeitung ist deshalb geplant, die Anzeigedichte zu reduzieren: Die wichtigsten Bearbeitungsschritte sollen im Vordergrund stehen, während sich der detaillierte Pfad bei Bedarf aufklappen lässt. ^[7] [10]

Dahinter steht dieselbe Frage wie in Teil 1. Auch wenn intern viele Module wiederverwendet werden, muss sich die Oberfläche an den Aufgaben orientieren, die der Nutzer verstehen soll. Maßgeblich ist, ob die Unterschiede der Modi, das gerade bearbeitete Gerät und der nächste mögliche Schritt unmittelbar nachvollziehbar sind. ^[1]

6 EQ-Analyse und Bearbeitungsablauf

Tone EQ und Final EQ verfügen jeweils über eine unabhängige Bank mit 12 Bändern, sieben Filtertypen, eine Frequenzgangkurve sowie Ein- und Ausgangsspektren. Die Grundlage zur Einstellung von Frequenz, Gain und Q über die Grafik und Zahlenwerte ist implementiert. Die Lesbarkeit der Analyseansicht und der Bearbeitungsablauf in der Praxis blieben jedoch hinter den Erwartungen zurück. ^[8]

Der bisherige Analyzer verwendet eine FFT mit 2048 Punkten und einen festen Anzeigebereich. Bei 48 kHz beträgt der Abstand der Frequenz-Bins ungefähr 23,44 Hz. Das begrenzt die Detailerkennbarkeit im Tieftonbereich; eine glatter gezeichnete Linie erhöht die tatsächliche Auflösung nicht. Zusätzlich braucht es ein Zeitverhalten, das Anschlag und Ausklingen lesbar macht, eine klare Unterscheidung von Ein- und Ausgang sowie eine visuelle Hierarchie, in der die EQ-Kurve gut erkennbar bleibt. ^[8]

Der Entwurf für die nächste Überarbeitung umfasst eine größere Bearbeitungsansicht für den ausgewählten EQ, Einstellungen für Analyseauflösung und zeitliche Glättung, Freeze und Peak Hold, das Hinzufügen und Löschen von Bändern, Mehrfachauswahl und das Abhören einzelner Bänder sowie Undo und Redo auf EQ-Ebene. Diese Punkte sind Verbesserungsspezifikationen und werden hier nicht als bereits fertige Funktionen geführt. ^[8]

Mit einer verbesserten Analyseansicht entsteht auch Rechenaufwand, der berücksichtigt werden muss. Änderungen an Auflösung und Reaktionsgeschwindigkeit des Analysefensters dürfen dem Audiopfad keine zusätzliche Latenz hinzufügen. Der Zustand der Anzeige muss von den Einstellungen getrennt bleiben, die den gespeicherten Klang bestimmen. Bestehende Projektparameter und Automationsdaten müssen bei der Überarbeitung erhalten bleiben. ^[8]

7 Die entscheidenden Messwerte für Echtzeitverarbeitung

Bei Echtzeitaudio muss jeder Audioblock vor seiner nächsten Verarbeitungsfrist fertig sein. Auch bei geringer durchschnittlicher CPU-Auslastung kann ein selten auftretender langer Callback während des Spielens Probleme verursachen. Deshalb habe ich sowohl das Bestehen der festgelegten Leistungskriterien als auch die Zahl der tatsächlich überschrittenen Fristen festgehalten.

Bei den CAB-Messungen am endgültigen Quellstand von 1.3.1 erfüllten alle drei Betriebssysteme die p99-Kriterien für sämtliche 66 Pfade. p99 bezeichnet das 99. Perzentil der Verteilung der Verarbeitungszeiten. Unter macOS überschritten jedoch 54 der 105.600 gemessenen Callbacks ihre jeweilige Frist. Die folgenden Werte sind Beobachtungen für diesen Quellstand und die verwendeten CI-Umgebungen. ^[7]

Die maximale verstrichene Callback-Laufzeit unter macOS betrug ungefähr 29,9 ms. Da das p99-Kriterium einen festgelegten Punkt der Verteilung bewertet, bedeutet sein Bestehen nicht, dass auch sämtliche seltenen Verzögerungen ausgeschlossen sind. Bedienung, Zustandswiederherstellung und Beenden müssen zusätzlich auf realer Hardware und in DAWs geprüft werden. ^[7]

Bei Transpose bleibt eine andere Form der Latenz zu bearbeiten. Die algorithmische Latenz beträgt etwa 46,4 ms bei 44,1 kHz und 42,7 ms bei 48 kHz. Das Ziel von höchstens 10 ms ist damit noch nicht erreicht. Ebenfalls offen bleibt die Hörrückmeldung, dass der Klangkörper des Tons und aufeinanderfolgende Anschläge verschwimmen, wenn die tiefe H-Saite des Basses um zwei Halbtöne nach unten transponiert wird. ^[9]

Abbildung 6. Algorithmische Transpose-Latenz bei zwei Abtastraten und das Ziel von höchstens 10 ms. Diese Ausgangswerte sind von der gesamten Roundtrip-Latenz einschließlich Interface und DAW sowie von der CAB-Callback-Ausführungszeit zu unterscheiden. Die Qualität tiefer Töne und die Latenz müssen gemeinsam neu bewertet werden. ^[9]

Dieses Problem verlangt eine gemeinsame Bewertung von Qualität im tiefen Register und Latenz. Auf Basis desselben DI-Signals müssen Tonhöhe, Anschlag und Sustain von Original und transponiertem Signal verglichen und der Einfluss des Gates getrennt untersucht werden. Eine Verkleinerung des FFT-Fensters, die lediglich den Latenzwert senkt, muss sich im tatsächlichen Spielvergleich bewähren. Auch die Latenzkompensation einer DAW beseitigt nicht die beim Spielen über einen Live-Eingang spürbare Wartezeit. ^[9]

8 Wöchentliche Updates und eine gemeinsame Grundlage für weitere Produkte

Auch meine Einschätzung des Entwicklungstempos hat sich verändert. Mehrere Funktionen und Prüfpläne in kurzer Zeit parallel zu verfolgen machte es notwendig, den Umfang der Updates neu zu bestimmen. Künftig soll jede Woche eine tatsächliche Verbesserung oder ein Wartungsergebnis bringen. Zugleich möchte ich den Umfang jedes Updates und seine Prüfbedingungen konkreter festlegen. ^[10]

Der Zeitplan braucht Ziele für Test-Builds und öffentliche Veröffentlichungen. Wenn sich Arbeit verzögert, muss der nächste Umfang angepasst werden. Dabei soll der Grundsatz bestehen bleiben, unvollständige Prüfungen nicht nachträglich als bestanden zu führen, sondern die offenen Probleme festzuhalten. ^[10]

Die Pläne, Náströnd und Niflheimr jeweils als eigenständige, schlanke Plug-ins anzubieten, beginnen mit denselben Maßstäben. Sie sollen die vorhandenen Engines gemeinsam nutzen und die Bedienelemente und Effekte auf den jeweiligen musikalischen Einsatzzweck beschränken. Zusätzlich benötigten DSP möchte ich in gemeinsamen Modulen entwickeln, die auch Chimera verwenden kann. Die eigenständigen Produkte, NAM-Pakete und AAX-Unterstützung bleiben spätere Arbeiten, die jeweils eine eigene Umsetzung und Prüfung erfordern. ^[10]

Für Gitarren-PRE hat derzeit ein Booster Vorrang, der vor dem Amp den Tieftonbereich, den Anschlag und den Eingangspegel formt. TRIAX kommt der gesuchten Rolle als Referenz am nächsten. Sobald das benötigte Verhalten konkret definiert ist, werde ich beurteilen, welche Teile die vorhandene Engine abdecken kann und welche neu entwickelt werden müssen.

Der nächste Entwicklungseintrag sollte die Ergebnisse der tatsächlichen EQ-Bearbeitung und des Spielens mit dem verbesserten EQ, die Vergleichseingaben für Transpose im tiefen Register und die Versuche mit alternativen NAM-Architekturen dokumentieren können. Ich möchte dabei auch festhalten, unter welchen Bedingungen die hier erkannten Grenzen im nächsten Build erneut bewertet wurden.

Belege und aktueller Befund

Nächste Forschung und Prüfbedingungen

EQ: Mit demselben Eingangssignal die Lesbarkeit tiefer Frequenzen, Bearbeitungsschritte und das zeitliche Anzeigeverhalten der bisherigen und überarbeiteten Ansicht vergleichen. Die Latenz im Audiopfad und die Kompatibilität bestehender Automation ebenfalls prüfen. ^[8]

Transpose: Vergleichs-DI und Einstellungen für die um zwei Halbtöne abgesenkte tiefe H-Saite des Basses festlegen. Den Einfluss des Gates getrennt untersuchen und Tonhöhe, Anschläge, Ausklänge sowie algorithmische Latenz dokumentieren. ^[9]

NAM: Längere Eingangshistorien und Alternativen mit rekursiven Filtern anhand derselben Testsignale und Kriterien vergleichen. Erfolgreichen Export und Wiederherstellung getrennt vom Bestehen der Wiedergabetreue berichten. ^[5]

Quellen und Entwicklungsaufzeichnungen

Implementierungs- und Messberichte beziehen sich auf die jeweils verlinkten Quellstände. UI-Abbildungen belegen Anordnung und Bedienung; sie ersetzen keine Leistungsmessungen. Die neuen Infografiken stellen dokumentierte Werte oder ausdrücklich gekennzeichnete Konzepte dar. Roadmap und EQ-Spezifikationen beschreiben Folgepläne mit Stand vom 12. Oktober 2026.

[1] Chimera Amp Matrix: Entwicklungstagebuch, Band 1

[2] Öffentliche Beta 1.1.2 und Umfang der Kalibrierung nativer Amps

[3] Náströnd: Kanalcharakter und Korrekturen an Pegel und Klarheit

[4] Niflheimr: native Umsetzung und verbesserte Klarheit im Tieftonbereich

[5] Náströnd A2: Bericht zu zusätzlichem Training und strukturellen Grenzen vom 11. Oktober 2026

[6] Erweiterte CAB-Modelle für Lautsprecher und Mikrofone

[7] Öffentliche Beta 1.3.1: Funktionen und Beobachtungen zur Echtzeitleistung

[8] Verbesserungsspezifikation für EQ-Analyzer und Bearbeitungsablauf

[9] Langfristige Transpose-Verbesserungen und Latenzkriterien

[10] Entwicklungsroadmap von Oktober 2026 bis Dezember 2027

[11] Cabinet-Anordnung und Regeln für kompatible Lautsprecherdurchmesser

[12] Herkunft der nativen Matrix-UI-Aufnahme für Beta 1.3.1

[13] Herkunft der nativen Verstärker-UI-Aufnahmen für Beta 1.3.1