# DeepPluck V0.11.5 – CPU-Profiling / DSP-Optimierung

Status: **Praxistest vom Benutzer bestätigt; Fortsetzung laut Roadmap gewünscht.
Effizienz belegt, technisches Echtzeit-Gate weiterhin FAIL; Ursachenklärung
zurückgestellt. Keine nachträgliche technische Gesamtfreigabe.**

## Benutzerbestätigung und Fortsetzung am 03.09.2026

Nach dem angeforderten Debug-/Release-Build von V0.11.5 bestätigt der Benutzer:
„es funktioniert alles, wir machen laut roadmap weiter“. Dies wird als erfolgreiche
praktische Funktionsabnahme des aktuellen Builds und Wunsch zur Fortsetzung
festgehalten. Die genaue Host-/Audio-MIDI-/A/B-Einzelcheckliste wurde dabei nicht
aufgeschlüsselt; keine zusätzlichen vom Agenten ausgeführten Hörtests behaupten.
Die elf früheren Timing-Ausreißer und sämtliche Rohdaten bleiben dokumentiert.
Die neue Benutzerbestätigung ersetzt kein gemessenes Performance-PASS und löst
keinen automatischen Commit aus; eine weitere Diagnose wird jetzt nicht gestartet.

Laut Roadmap folgt V0.12.0 Factory Presets, danach V0.13.0 Release Candidate
und V1.0.0 Final Release. Fundstelle: Abschnitt 30 des vorhandenen V0.10.0-
Masterprompts; die eingefügte Reihenfolge 0.11.0 -> 0.11.25 -> 0.11.5 -> 0.12.0
ist im V0.11.5-Masterprompt bestätigt. Eine konkrete V0.12.0-Spezifikation liegt
noch nicht vor. In dieser Statusfortschreibung wurden keine Presets, Parameter,
DSP-Quellen, Versionsnummern oder vorhandenen Benutzerdateien geändert.

## Aktueller Prüfstand am 03.09.2026

Aktueller Kandidat: `oscillator-settled-mix-02`, Version 0.11.5. Die einzige
produktive DSP-Änderung ist der enger gefasste Wellenform-Smoother-Pfad in
`Source/Synth/DeepPluckOscillator.h`. Hinzu kommen drei inerte Test-Friend-
Deklarationen. Parameter-, Editor-, Processor- und FX-Implementierungen sind
unverändert; der verworfene Filter-Cache wurde exakt zurückgenommen. Quellen,
gemessene Hilfsprogramme und unveränderte Compiler-Policies sind abgeglichen.

Ergebnis der beiden **unabhängigen** Neun-Paar-Läufe (Median der Paargewinne):

| Fall | Lauf 1 | Lauf 2 |
| --- | ---: | ---: |
| Typical B | +4,0748 % | +3,9150 % |
| Dense C | +8,2548 % | +7,7219 % |
| vorab gewählter Worst D | +5,4330 % | +5,0126 % |

Worst-D-95%-Intervalle: [4,8287; 6,0554] % und [4,3478; 5,2993] %.
Damit ist die Mindest-Effizienz zweimal belegt, **nicht jedoch die komplette
Performancefreigabe**. Im zweiten Lauf traten elf Kandidaten-Blockfristverletzungen
auf, maximales Zeit-/Fristverhältnis 2,1429. Der erste hatte keine Kandidaten-
Verletzung. Keine Messung wurde entfernt oder als extern kontaminiert umetikettiert.

Der anschließend vorgeplante vollständige **39-Fälle-/Fünf-Paar-Vergleich** dauerte
142,478 s. Alle 39 Fälle sind schneller (Medianverhältnisse +1,27 bis +9,78 %),
keine >3%-Regressionsverdachtsfälle, keine Blockfrist- oder reinen Lifecycle-
Phasenverletzungen auf beiden Seiten. Worst-D-Kandidat: Median-RTF 0,2330451,
Maximalblock 276,8 µs bei einer Frist von 666,7 µs. Diese saubere spätere Messung
hebt die vorherigen elf Verletzungen ausdrücklich **nicht** auf. Alle P99-/Max-
Änderungen und 390 Timer-Kalibrierungen wurden separat geprüft; keine Subtraktion
des Timeraufwands. Der formale Prüfer meldet deshalb `performancePass=false`.
Die weichen RTF-Ziele werden in dieser abschließenden kurzen Matrix erreicht:
Typical maximal 0,009707 pro Wiederholung (Ziel <=0,20), D-Familie maximal
0,234419 (Ziel <=0,50; harte D-RTF-Grenze <=0,90). Dies ist ausdrücklich keine
Freigabe der früher verletzten einzelnen Blockfristen oder der realen Hostwiedergabe.

| Weitere Prüfung | Tatsächlicher Stand |
| --- | --- |
| 39 × zwei frische Renders je Debug/Release | exakt audio-/phasen-/lifecycle-identisch zu S |
| alle 420 vollen Übergänge je Debug/Release | exakt identisch zu erhaltenen Vollreferenzen |
| vier vollständige 128-s-Tails je Debug/Release | exakt identisch zu erhaltenen Vollreferenzen |
| 711 Tone-Renders und echte bidirektionale State-Reader | Debug und Release PASS |
| aktuelle normale Builds | Debug PASS, 24,54 s; Release PASS, 26,89 s; keine neuen Compilerwarnungen |
| alle 33 CTests | Debug 33/33 PASS, 659,37 s; Release 33/33 PASS, 203,16 s |
| Artefaktversionen, lokale Kopien, negative Checkerproben | Debug und Release PASS |
| Standalone-Fensterstart/normales Schließen | Debug und Release PASS, Exit 0, kein erzwungenes Beenden |
| echte native Vorher-/Nachher-Profile | B/C/D auf beiden Seiten vollständig; PDB/Quellen bestätigt, keine verlorenen Ereignisse |
| manuelles A/B-Material | 20 echte, pegelgleiche und byte-identische Float-WAV-Paare bereit |

Aktueller Evidenz-Unterordner innerhalb des unten genannten Evidenzlaufs:
`experiments/oscillator-settled-mix-02/`. Wichtig sind `final-pairs-01-analysis/`,
`final-pairs-01-phases/`, `latency-review-01.json`, `performance-gate-01.json`,
`source-artifact-audit-01.json`, `regression-01/` und `listening-01/README.md`.

**Historischer Diagnosezugangs-Blocker, durch Benutzer-Admin-Lauf überbrückt:** Die ursprünglichen CPU-Profile enthalten
keine CSwitch-/ReadyThread-/DPC-/ISR-Ereignisse. Das installierte Windows-WPR
scheitert mit `0xc5585011` am fehlenden Systemprofilrecht; auch der aktuelle
unsandboxed Benutzertoken enthält kein `SeSystemProfilePrivilege`. Die verfügbaren
VS-CPU-Konfigurationen liefern dafür keinen belegten Ersatz. Dies verhindert
im damaligen Agentenkontext eine belastbare Zuordnung der normalen Timing-Ausreißer zu Scheduler/
Treibern; es beweist **nicht**, dass Windows sie verursacht hat. Keine automatische
Rechte-/Policy-/Treiber-/Power-Änderung oder Installation. Der Benutzer wurde
gefragt, ob später eine vorbereitete kurze Admin-Diagnose möglich ist.
Der erneute rein lesende Nachweis liegt in
`verification/diagnostic-access-final-01.json`: unverändertes installiertes WPR,
erfolgreiche Berechtigungs-/Konfigurationsabfrage, weiterhin fehlendes Recht.
Eine spätere autorisierte Systemaufzeichnung wäre eine **Diagnose**, kein
ungeprofilierter Performance-PASS. Sie muss zuerst einen konkreten Ursachenbefund
liefern; weder neue Traces noch weitere günstige Timing-Läufe dürfen die elf
historischen Verletzungen stillschweigend ersetzen.

### Ergänzung: Benutzer-Admin-Diagnose am 03.09.2026

Der Benutzer hat die vorbereitete lokale Diagnose ausgeführt und mit „fertig“
bestätigt. WPR-Start, Status, beide eingefrorenen S-/C-Workloads und WPR-Stop
sind mit nativen Exits 0 abgeschlossen. Keine Berechtigungs-, Treiber-, Energie-,
Prioritäts- oder Affinitätsänderung. Es ist daher **nicht mehr richtig, die
Auswertung dieser Aufnahme als am Admin-Zugang blockiert zu bezeichnen**.

Evidenz: `profiling/system-diagnostic-20260903T121221Z-32d82ed0/`.
ETL: 483.393.536 Bytes, SHA-256
`4B76E4392F365412849A6F7B9E0B04D544B60ACCB766503018DE22FAAC705BE0`.
Workloads: derselbe festgelegte Worst-D-Fall, S 35,431 s / 71 Wiederholungen,
C 35,160 s / 74 Wiederholungen. Dies sind diagnostische Symbol-Binaries und
sequentielle S-/C-Aufrufe, **keine** neuen Effizienzmessungen.

Die lokale Auswertung mit der vorhandenen Visual-Studio-TraceEvent-Bibliothek
liest 4.472.891 Ereignisse, darunter 1.147.445 Context-Switches und 294.791
ReadyThread-Ereignisse. Die zusammengeführte ETL meldet jedoch **191.072 verlorene
Ereignisse**, null verlorene Buffer. Sechs erhaltene Verlustmeldungen betreffen
den WPR Event Collector im Nachlauf; daraus darf weder abgeleitet werden, dass
sämtliche Verluste nur dort auftraten, noch dass der Scheduler-Datenstrom
lückenlos ist. DPC-/ISR-Ereignisse fehlen in diesem Aufnahmeprofil. Die unveränderten
sechs ursprünglichen B/C/D-CPU-Profile bleiben davon unabhängig verlustfrei.

Die beiden hauptsächlich rechnenden Threads wurden über CPU-Samples identifiziert.
Für die Scheduler-Prüfung wurden die erste Wiederholung und alle Setup-/Zwischen-
fenster ausgeschlossen; beide Enden eines Paars müssen im selben vorhandenen
DSP-Schleifenfenster liegen. Paare mit widersprechenden CPU-Samples wurden
ausgeschlossen (S drei, C eins). Die globale Switch-Kettenprüfung findet keine
Unterbrechung, ist aber kein Beweis für Vollständigkeit einer verlustbehafteten ETL.

| Erhaltene, lokal konsistente Beobachtung | S: Referenz | C: Kandidat |
| --- | ---: | ---: |
| geprüfte Schleifenfenster nach Warm-up | 70 | 73 |
| Switch-out-/Switch-in-Paare innerhalb dieser Fenster | 3.159 | 2.512 |
| längste beobachtete Unterbrechung | 693,5 µs | 325,7 µs |
| beobachtete Unterbrechungen über 666,7 µs | 1 | 0 |

Die längste Unterbrechung der Referenz beginnt im Zustand `Ready`: Der Thread
war ausführbar, wurde zwischenzeitlich aber nicht ausgeführt. Damit sind
Scheduler-Unterbrechungen in dieser Diagnose konkret beobachtet. Das jeweils
unmittelbar nachfolgende Programm wird **nicht** als alleiniger Verursacher
ausgegeben. Die vorhandenen Marker begrenzen ganze DSP-Schleifen, keine einzelnen
Audioblöcke; diese Tabelle ist deshalb weder ein Blockfrist-Test noch eine
nachträgliche Kausalerklärung der elf früheren Kandidaten-Misses. Insbesondere
ist die Null in der Kandidatenspalte kein Freigabenachweis.

Roh-Exporte und Header: `analysis-08/`; Paarprüfung mit Ausschlussgründen:
`scheduler-review-01/paired-gaps.csv` und `review.json`. Unvollständige lokale
Ausleseversuche sind ebenfalls erhalten; nur Analysehelfer wurden angepasst,
keine Aufnahme, Source-/Build-/Benchmark-Eingaben oder ursprünglichen Ergebnisse.
Die alte `verification/handoff.json` bleibt als datierte historische Quittung
unverändert; der neue Diagnose-Follow-up hält die aktuellen Hashes fest.

**Folgerung:** Zugangsproblem für diese Aufnahme gelöst, Diagnose nur teilweise
belastbar, Performance-Gate weiterhin FAIL. Ein identischer erneuter 35-s-Lauf
würde die fehlende zeitliche Zuordnung nicht nachliefern. Ein gezielter Folgeschritt
benötigt reduzierte Scheduler-/DPC-/ISR-Erfassung und direkt dazu korrelierbare
Block-Zeitstempel, separat von der normalen Performance-Abnahme. Eine erneute
erhöhte Aufnahme bedarf der Benutzer-Mitwirkung. Keine weitere Aufnahme oder
Bestätigungsserie wurde automatisch gestartet; keine Grenzwerte gelockert.

Kein Staging, Commit, Push oder technische Fertigmeldung: HEAD bleibt
`4b4d0e5867799f66b9e3db95eb70cad195b57d33`. Die nachfolgenden Abschnitte dokumentieren
Scope und chronologischen Weg; ältere Zwischenstände sind keine aktuelle Freigabe.

### Benutzer-Build zum Praxistest am 03.09.2026

Auf „ok, bau die änderungen, dann sehen wir weiter“ wurde ausschließlich der
vorhandene Kandidat erneut in Debug und Release gebaut, ohne weitere DSP-Änderung,
Diagnose, Benchmarkserie oder Commit. Der erste Sandbox-Build scheiterte vor dem
Kompilieren an MSBuild FileTracker `E_ACCESSDENIED`; derselbe Build außerhalb
der Sandbox war erfolgreich. Debug 9,600 s, Release 4,986 s, jeweils nativer
Exit 0 und keine Compilerfehler oder neuen Compilerwarnungen im erfolgreichen Lauf.
Die Artefakt-CTests sind in beiden Konfigurationen erneut PASS. Alle 18 geprüften
physischen Artefakte und 91 Source-Einträge entsprechen exakt dem bereits vollständig
getesteten Stand; die vorhandenen 33/33-Funktionstest-Ergebnisse je Konfiguration
werden deshalb wiederverwendet. Lokale VST3-Bundles und Standalone-Dateien unter
`Artifacts/Debug` und `Artifacts/Release` tragen Version 0.11.5. Schutzprüfung
erneut PASS; keine Systeminstallation, kein Staging. Evidenz:
`verification/user-build-20260903-01/`. Der Benutzer-Build ist keine Freigabe der
weiterhin offenen harten Echtzeitgrenze; die weiterführende Diagnose ist vertagt.

### Getrennte Skalierungsbefunde

Normale Release-Binaries, fünf abwechselnde S/C-Paare, Median-RTF. Innerhalb einer
Zeile wird nur die genannte Dimension verändert; alle übrigen Werte entsprechen
dem gemeinsamen M-Anker. Zahlen sind **keine Cubase-CPU-Prozentwerte**. RTF ist
Callback-Rechenzeit geteilt durch erzeugte Audiozeit.

| Dimension, Reihenfolge der Werte | S: 0.11.25 | C: 0.11.5 |
| --- | --- | --- |
| Stimmen 1 / 4 / 8 / 16 | 0,008747 / 0,018526 / 0,031520 / 0,058777 | 0,008385 / 0,017533 / 0,029524 / 0,054984 |
| Unison 1 / 2 / 4 | 0,027251 / 0,031520 / 0,042596 | 0,026409 / 0,029524 / 0,038430 |
| Buffer 64 / 128 / 256 / 512 | 0,031979 / 0,031520 / 0,031313 / 0,031019 | 0,030044 / 0,029524 / 0,029211 / 0,029146 |
| Rate 44,1 / 48 / 96 kHz | 0,029195 / 0,031520 / 0,062313 | 0,027225 / 0,029524 / 0,058599 |
| FX aus / Chorus / Delay / Reverb / alle | 0,026532 / 0,028377 / 0,028062 / 0,028632 / 0,031520 | 0,024875 / 0,026689 / 0,025952 / 0,027231 / 0,029524 |

Stimmen- und Sample-Rate-Skalierung zeigen den erwarteten Lastanstieg; größere
Buffer reduzieren hier leicht den relativen Aufrufaufwand. Unison enthält
weiterhin gemeinsame Arbeit pro musikalischer Stimme und skaliert daher nicht
linear mit der Slotzahl. Osc2 aus ist im Kandidatenanker mit RTF 0,029655 nicht
billiger als an (0,029524): der bestehende bypassierte Oszillator läuft absichtlich
weiter, um Phasen-/Einschaltverhalten zu erhalten. Kein unzulässiger Bypass-Fastpath
wurde für bessere Zahlen eingeführt. Einzelne kleine Messunterschiede sind kein
Beweis für einen zusätzlichen DSP-Effekt. Die vollständigen Fall-/Phasenwerte,
Wiederholungen, P99/Max und Kalibrierungen liegen in den JSON-/CSV-Rohberichten.

### Rechner, Messgrenzen und unveränderter Klangvertrag

Gemessen auf Windows 11 Pro x64, Build 26200, Intel Core i5-14600K
(14 physische / 20 logische Kerne), rund 32 GB RAM. Bestätigte Toolchain:
Visual Studio 2026 (Installation 18.9.12120.119), MSVC 19.51.36256 / Tools
14.51.36231, Windows SDK 10.0.26100.0, CMake/CTest 4.4.3, JUCE 9.0.1, C++20,
Generator `Visual Studio 18 2026`, x64. Das bestehende Energieschema „Ultimative
Leistung“, normale Prozesspriorität und uneingeschränkte Scheduler-Affinität
wurden nicht verändert. Kein Fast-Math-, FP-, ISA-, PGO-/LTO- oder Qualitätswechsel.
Die Symbol-Builds sind getrennte Diagnosen, niemals Quelle der Effizienzzahlen.
Momentane CPU-Temperatur und tatsächlicher Kern-Turbotakt sind nicht belastbar
gemessen; WMI-Taktangaben wären dafür kein Ersatz. Keine universelle Host- oder
Echtzeitgarantie aus diesem einzelnen Rechner ableiten.

Die 62 Parameter, vier Factory-Snapshots, 10.000 deterministischen Random-/Undo-
Aktionen, 101-Punkte-Mapping-/Textgitter und echten bidirektionalen neun State-
Prefix-Fixtures sind unverändert. Je Konfiguration umfasst der strikte Tone-
Vergleich 669 Full-Processor- und 42 Partition-Fälle, insgesamt 98.862.480 Frames.
Maximalfehler, RMS- und Fensterfehler sind null; keine Ausnahme für geänderte
Float-Auswertungsreihenfolge erforderlich. Es wurde nichts normalisiert,
abgeschnitten oder abgesenkt. Die bestehenden Musik-/FX-/Filter-Headroomtests
bleiben unverändert und bestehen. Extreme Lastfixtures behalten ihre bereits
vorhandenen Rohpeaks über 0 dBFS; sie sind keine normalen Factory-Pegelgrenzen.

Realtime-Codeprüfung des einzigen neuen Produktpfads: ein lokales Boolean und
ein festes Stack-Array, keine neue persistente Datenstruktur, Allokation, Sperre,
Datei-/Netzwerkoperation, Logausgabe oder GUI-/APVTS-Suche. Jeder Array-Lesezugriff
steht unter demselben Initialisierungs-Guard. Aktive Mix-Rampen, einschließlich
Frequenz null und gebrochener Sample-Rate, werden unverändert weitergeführt;
Pulse-Width-Smoother, Triangle-Rekurrenz, Phasen und Summationsreihenfolge bleiben
erhalten. Weder Callback-Instrumentierung noch Offline-Sonderklang gelangt ins
auszuliefernde Plugin. „Realtime-sicherer Code“ ersetzt nicht das separat
fehlgeschlagene Blockfrist-Gate.

Normale gemessene Benchmark-Binaries, SHA-256:

- S: `EBEF100DEEEE182AB51D8836CB82AB716A0D128B2BE6C622E51B80801ED2429E`
- C: `6C89CE9D74470C7D3A219AE7608298839054673D6400827C8608D0139DF0DD0D`

Release-Standalone C: `2DDB7F51F1335A44EB87306E4B7BBA4D4FB954E0F4AFC42E859E0486BE8CA726`.
Debug-Standalone C: `B89F14C7999A74A431A77FA7028AC7141AA89D5AC5541FBA5FE7C6978F00850C`.
Vollständige Quellen-/Projekt-/Compiler-/Bundle-Provenienz steht in den eingefrorenen
Metadaten und `source-artifact-audit-01.json`; der abschließende Status wird unter
`verification/handoff.json` erfasst. Es gibt weiterhin keinen Implementierungscommit.

### Ergänzung beim Abschlussaudit

Die 35 bereits geprüften Übergänge am 48-kHz-/128-Sample-Anker ersetzen nicht
die unabhängige funktionale Übergangssuite über alle zwölf Rate-/Bufferpaare.
Diese 420 kurzen Übergänge wurden deshalb zusätzlich als reine Audiovergleiche
gegen die vorhandenen Vollreferenzen geprüft: **beide Konfigurationen PASS**,
Release 67,49 s, Debug 486,57 s, native Exits 0. Ein Aufruf je Konfiguration
spart den Startaufwand hunderter Einzelprozesse. Bereits vorhandene Ergebnisse
bleiben erhalten; nur die 35 Ankerfälle werden dabei zur Vollständigkeitsprüfung
erneut gelesen/gerendert. Dies erweitert **nicht** die 39-Fälle-CPU-Matrix und
erzeugt keine neue Timing- oder Profilpflicht. Die vier langen E-Tails bleiben
separat am repräsentativen Anker geprüft. Übergänge, Tails und der 711-Fälle-
Tone-Corpus behalten ihre volle Dauer, weil verkürzte Ausgaben Fehler verdecken
könnten. Der tatsächliche Abschlussstatus steht oben; keine vorweggenommene Freigabe.

Beim anschließenden Nachher-Profilaufbau brach Windows PowerShell 5 an der
nativen stderr-Ausgabe des Compiler-Banners ab (`NativeCommandError`, Koordinator
Exit 1). Es gab noch keinen Build-Abschlussnachweis und anschließend keinen
verbliebenen eigenen Build-/Benchmark-/Collector-Prozess. Der unvollständige
Ordner `profile-symbols` und sämtliche Fehlerlogs bleiben erhalten. Nur dieser
unvollständige Schritt wird mit der bereits installierten PowerShell 7 und neuem
Ausgabeordner `profile-symbols-02` fortgesetzt; kein C++-/Compiler-/DSP-Wechsel,
keine Neuinstallation, kein Wiederholen der fertigen Übergänge oder CPU-Paare.
Nachweis: `after-profiles-recovery-02.json` und dessen eigener Koordinatorlog.
Die Fortsetzung ist abgeschlossen (Exit 0): Symbol-Build 119,58 s, alle 39
Symbol-/Normal-Audiovergleiche exakt, alle drei tatsächlichen Nachher-Profile PASS.

### Tatsächliche Nachher-Profile

Wie vorab festgelegt nur B/C/D, je 35 Sekunden Workload angefordert; die gemessenen
nativen Prozesslaufzeiten einschließlich Vor-/Nachlauf liegen bei 37,55–37,78 s.
Aufnahme, native Exits 0, PDB-GUID/Alter und Quellenzuordnung sind geprüft,
verlorene Ereignisse jeweils null. Nachher akzeptierte Callback-Samples:
B 24.930, C 31.935, D 33.632.

| Fall | Unison Self vorher | Unison Self nachher | Unison inkl. vorher | Unison inkl. nachher |
| --- | ---: | ---: | ---: | ---: |
| Typical B | 12,07 % | 10,18 % | 12,16 % | 10,28 % |
| Dense C | 40,78 % | 37,38 % | 41,12 % | 37,67 % |
| Worst D | 30,89 % | 29,57 % | 61,36 % | 59,80 % |

Der Oszillator ist in diesem Build in den Unison-Pfad inline eingebettet. Die
verringerten Sample-Anteile passen zum gewählten Ansatz, sind aber **keine
absoluten Millisekunden und kein zusätzlicher Effizienz-Prozentnachweis**.
Inklusive Anteile nicht addieren. Der relative Filteranteil steigt entsprechend
(B 17,26→17,55 %, C 22,91→24,98 %, D 17,69→19,08 %); daraus allein lässt sich
keine absolute Filter-Verlangsamung ableiten. Die Produkt-Filterquellen sind
nachweislich unverändert. Die verbindlichen Gewinne und Fristverletzungen stammen
ausschließlich aus den normalen, ungeprofilten gepaarten Release-Läufen.

Rohtraces, Quelldaten, Call Trees, Hot Paths, adressgenaue Samples und ausgeschlossene
Warm-up-/Setup-Phasen bleiben in `profile-{B,C,D}-01/analysis-01/` erhalten.
Einige externe Runtime-/Kernel-Blätter haben weiterhin nur Adresssymbole; keine
falsche Behauptung, sämtliche Systembibliotheken seien vollständig aufgelöst.

## Verbindliche Scope-Anpassung vom 03.09.2026

### Geänderter Projektumfang und Abnahmeregel

- `Source/Synth/DeepPluckOscillator.h`: genau eine isolierte CPU-Optimierung;
  drei weitere Source-Header enthalten ausschließlich inerte Test-Friends.
- `CMakeLists.txt`: Version 0.11.5 als einzige Quelle, echter Offline-Benchmark,
  getrennte Symbolkonfiguration und vier zusätzliche Harness-CTests.
- `Tests/Benchmark/` und zugehörige PowerShell-Werkzeuge: deterministische Inputs,
  Audio-/Phasen-/Lifecyclevergleich, serialisierte Zeitmessung, feste gepaarte
  Statistik, Profilaufnahme/-auswertung, unveränderliche Provenienz, JSON/CSV und
  WAV-Export. Kein Timer oder Diagnose-Logging im ausgelieferten Callback.
- `Tests/TestMain.cpp`: gezielte zusätzliche Filter-Reset-/Rate-/Grenz- und
  Wellenform-Rampenproben; bestehende Erwartungen nicht gelockert.
- `Tests/ToneVoicingAudit.cpp`: strikter CPU-Nullvergleich und tatsächlicher
  alter/neuer State-Reader, unabhängig von früher erlaubten Tonänderungsgrenzen.
- `Tests/VerifyGeneratedVersion.ps1` / `Tests/VerifyArtifacts.ps1`: alle aktuellen
  Hilfsziele, tatsächliche Windows-Versionen, Bundle-Mitglieder und negative
  synthetische Proben; keine Änderung gesicherter Referenzen für Tests.
- `README.md`, `ARCHITECTURE.md`, `Tests/CPUProfilingBenchmark.md` und dieser
  Bericht: tatsächlicher Scope, Verhalten, Reproduktion, Vergleich und offene
  Freigabe. `AGENTS.md`, Sound Manifest, geschützte Masterprompts und alle
  Benutzerdateien werden nicht umgeschrieben.

Die Funktions-/Klang-, Build-, Artefakt- und Diagnose-Nachweise sind getrennte
Teilprüfungen. Sie können ein fehlgeschlagenes hartes Performancegate nicht
kompensieren. Die aktuelle Effizienzschwelle ist zweimal erreicht; technische
Gesamt-DoD und damit automatische lokale Commits bleiben wegen der elf
Blockfristverletzungen gesperrt. Die erste autorisierte Systemaufnahme ist jetzt
ausgewertet; es fehlt weiter die belastbare blockgenaue Ursachenklärung, nicht
eine gelockerte Deadline.
Der Benutzer-Praxistest ist inzwischen bestätigt; eine detaillierte Einzelabnahme
der vorbereiteten Hör-/Cubase-/Audio-MIDI-Checklisten wurde nicht genannt.

### Definition of Done: getrennte Bewertung

| Anforderung nach Scope-Anpassung | Ergebnis / Nachweis |
| --- | --- |
| Startstand, Vorgaben, Sound Manifest, Toolchain | PASS; ursprüngliches Schutzinventar und gemessene Metadaten |
| Unveränderte ausführbare R25-/S-Referenzen | PASS; Originale und Adapter mit eingefrorenen Quellen/Hashes erhalten |
| Deterministischer echter Headless-Harness | PASS; Manifest-, Determinismus-, Negativ- und externe Audio-Referenztests |
| Repräsentative CPU-Abdeckung statt Vollprodukt | PASS; 39 Fälle × fünf wechselnde S/C-Paare; getrennte Skalierung |
| Baseline und tatsächlicher Profilbeleg vor Optimierung | PASS; G1 und native B/C/D-Traces; Baseline-Misses transparent |
| Mindestens ein zweimal bestätigter Effizienzgewinn | PASS als Teilkriterium; D +5,4330 % / +5,0126 %, beide Intervalle >0 |
| Harte Echtzeitgrenzen / Spitzen | **FAIL**; elf Kandidaten-Misses in Bestätigung 2, späterer sauberer Lauf kein Ersatz |
| Strikte Audio-/Numerikgleichheit | PASS; 39 × zwei, 420 Übergänge, vier volle Tails und 711 Tone-Fälle je Konfiguration |
| Gefrorene Parameter/Identity/States/Presets/Random | PASS; eingefrorener Vertrag, alte/neue Reader und bestehende Regression |
| Engine-/Headroom-/GUI-/Realtime-Code-Regression | automatisierte Prüfungen PASS; allgemeiner Praxistest vom Benutzer bestätigt; hartes Timing-Gate bleibt separat FAIL |
| Aktuelle Debug-/Release-Builds und sämtliche CTests | PASS; je 33/33, keine neuen Compilerwarnungen |
| Physische Artefakte / lokale Kopien / Version 0.11.5 | PASS; PE, VST3-Klassen, vollständige Bundle-Hashes und negative Selbstproben |
| Beide Standalone-Prozess-Smokes | PASS; echtes Hauptfenster, reguläres Close, Exit 0, keine Restinstanz |
| Vorher-/Nachher-Profile und maschinenlesbarer Abschluss | sechs B/C/D-Profile PASS; separater Admin-Trace unvollständig; datiertes `verification/handoff.json` plus Diagnose-Follow-up |
| Benutzerdateien, Referenzen, JUCE, Git-/Installationsschutz | Schutzprüfungen PASS; abschließende Hash-/Statusliste im Handoff; kein Staging/Commit/Push/Install |
| Manuelle Prüfung / Benutzerabnahme | allgemeiner Praxistest am 03.09.2026 bestätigt; 20 A/B-Paare vorbereitet, einzelne Checklistenpunkte nicht separat bestätigt |

**Automatable Gesamt-DoD: FAIL / nicht freigegeben.** Effizienz belegt,
Ursache der Blockfristüberschreitungen ungeklärt; Benutzer-Admin-Trace ausgewertet,
aber mit Ereignisverlusten und ohne rückwirkende Zuordnung zu den elf Misses.
Für V0.11.5 liegt jetzt eine eigene Benutzer-Praxisbestätigung vor; das technische
Gesamt-Gate wird dadurch nicht rückwirkend auf PASS gesetzt.

### Maßgebliche neue Benutzeranweisung

Die neue direkte Benutzeranweisung ersetzt die kartesische Pflichtmatrix und
langen CPU-Messungen des ursprünglichen Masterprompts. Kein Reset/Checkout und
kein Neustart des Milestones: HEAD, Produktionsstand, Referenzen, bisherige
Prüfungen und alle Rohdaten bleiben erhalten. Der alte Masterprompt ist eine
geschützte Benutzerdatei und wird nicht überschrieben.

Neues festes Protokoll `DeepPluck-CPU-Representative-20260903-Rev1`:

- 39 Fälle: 19 M-Skalierungs-/Stressfälle, fünf Wellenformen und 15 Referenzfälle
  (Dry/Typical/Dense je einmal, zwölf ausgewählte D-Stressvarianten).
- Getrennte Ein-Faktor-Reihen: Polyphonie 1/4/8/16, Unison 1/2/4, Buffer
  64/128/256/512, 44,1/48/96 kHz, FX Off/Chorus/Delay/Reverb/All. Gemeinsamer
  Skalierungsanker: 48 kHz, 128 Samples, acht Stimmen, Unison 2, FX All, Osc2 an.
  Unison 3 bleibt zusätzlich in der bestehenden Funktionsregression erhalten.
- Messfenster: unveränderte erste zwei Sekunden der vorhandenen Eingaben, auf
  ganze Blöcke aufgerundet. Keine Zeitkompression, kein neuer Klangzustand.
  Warm-up: 0,5 Sekunden auf einer verworfenen frischen Instanz; der bisherige
  identische 0,25-Sekunden-Preroll bleibt. Fünf Wiederholungen und gepaarte
  Vergleiche, zwei unabhängige Neun-Paar-Bestätigungen bleiben verbindlich.
- Echte Profile nur Typical, Dense und dem langsamsten gemessenen Fall der
  zwölf ausgewählten D-Fälle. „Worst“ bedeutet nicht alle denkbaren Einstellungen.
  Keine E0- oder M/W/X-Profilerpflicht mehr. Je Profil weiter mindestens 30 s.
- Die vollständigen 7.920 Audio-Referenzen pro Konfiguration, 711 Tone-Renders
  pro Konfiguration und bereits bestandene Tests werden weiterverwendet. Neue
  Kurzfenster erhalten eigene IDs mit `-short2` sowie ursprüngliche IDs im Manifest.
  Kurzaudio wird gegen die entsprechenden unveränderten Referenzpräfixe geprüft;
  alte volle RTF-Werte werden nicht als neue Kurzfensterwerte umetikettiert.
- Lange Tail-/Übergangsnachweise bleiben Funktionsregression, sind keine Pflicht
  zu einer erneuten vollständigen CPU-Matrix. Keine DSP-/Klang-, Parameter-,
  Headroom-, numerische oder Echtzeitgrenze wird gelockert.

Der heute gestartete Vollmatrix-Koordinator (PID 16444) und dessen eigener
Benchmark (PID 11724) wurden nach Identitätsprüfung um 11:39:44 Uhr beendet.
227/248 Fälle des ersten Teilpakets waren vollständig protokolliert; der
Gesamtlauf ist unvollständig und bleibt unverändert erhalten. Ebenso bleibt der
gestrige 718-Fälle-Teilstand erhalten. Diese Zeitdaten können ergänzende historische
Lastbefunde liefern, ersetzen aber keine vergleichbare neue Messung.

## Fortsetzung: repräsentative Baseline und erste Optimierung

Die neue Baseline ist vollständig: 39 Fälle mit je zwei frischen Audiorenders in
Debug und Release, unabhängig gegen die ersten Samples der erhaltenen alten
Vollreferenzen geprüft. Audio, Phasen und Voice-/FX-Lifecycle sind exakt gleich.
Die normale Release-Zeitmessung (39 × fünf) dauerte 44,65 Sekunden. Alte lange
Messungen bleiben unverändert erhalten und werden nicht mit Kurzfenstern vermischt.
Evidenz: `baseline/representative-01` unter dem oben genannten Evidenzlauf.

G1 erlaubt Profiling, ist aber keine Performancefreigabe: Bereits die unveränderte
Baseline enthält insgesamt 50 Block-Deadline-Überschreitungen. Kein Messwert wurde
entfernt. Der langsamste ausgewählte D-Fall nach Median-RTF ist
`D-r96000-b64-wave3-order0-short2` (0,24722); der größte einzelne Block stammt
aus einem anderen D-Fall. Diese unterschiedlichen Befunde werden getrennt behandelt.

Drei echte, jeweils 35 Sekunden lange Visual-Studio-CPU-Profile wurden erfasst:
Typical B, Dense C und der gemessene Worst-D-Fall. Native PDB-Zuordnung und
Produktionsquellzeilen sind bestätigt; keine verlorenen ETW-Ereignisse. Der erste
Workload-Durchlauf wird als Warm-up ausgeschlossen, Setup/Dateizugriffe gehören
nicht zur Callback-Auswertung. Einige externe CRT-/Kernel-Blätter bleiben
Adresssymbole; inklusive Sample-Anteile sind nicht addierbar und keine gemessenen
Millisekunden. Filter-Anteil inklusive Unterfunktionen: B 17,26 %, C 22,91 %,
D 17,69 %. Rohtraces, Call Trees und Hot Paths: `profiling/representative-*-01`.

Erstes vorab registriertes Experiment `filter-coefficient-cache-01`:
Wiederverwendung der bisherigen Filterkoeffizienten ausschließlich bei exakt
identischem bereinigtem Float-Cutoff und identischer Sample Rate. Jede Bewegung
wird weiterhin sampleweise berücksichtigt. Keine Approximation, geänderte
Summationsreihenfolge, Smoothing-/Gain-/State- oder Parameteränderung. Die erste
Berechnung bleibt im Verarbeitungskontext; Reset ändert weiterhin Zustand und
Smoother, braucht unveränderte Koeffizienten aber nicht zu verwerfen.
Gezielte Tests prüfen Reset, erneutes Prepare, Rückkehr zur alten Rate, Grenzen
und einen Cutoff-Schritt von nur einem Float-Wert. **Noch nicht akzeptiert:**
Builds, exakter Nullvergleich und zwei unabhängige Neun-Paar-Vergleiche für B/C/D
müssen den Nutzen und ausbleibende Regressionen erst belegen. Erst jetzt wurde
`project(... VERSION ...)` auf 0.11.5 gesetzt; die Referenzen bleiben 0.11.25.

Umgebungsvergleich: Das Windows-CPU-Set-Flag `Parked` (Bit 0 gemäß installiertem
SDK) ist eine momentane Scheduler-Beobachtung, keine andere Hardware/Power-Policy.
Nur dieses Bit wird aus einem **zusätzlichen** Vergleichshash ausgeschlossen.
Alle originalen Metadaten, Flag-Werte und vollständigen Hashes bleiben erhalten.
Topologie, Allocation-/Realtime-Bits, Priorität, Power-Plan und Toolchain werden
weiter strikt verglichen. Positive und negative synthetische Tests sichern dies;
es wurde keine System-/Scheduler-Einstellung verändert.

### Experimententscheidung und nächste isolierte Prüfung

Filter-Cache: beide Builds PASS (Debug 132,63 s; Release 147,40 s), keine neuen
Compilerwarnungen. Alle 39 × zwei Renders sind in beiden Konfigurationen exakt
identisch zur unabhängigen kurzen Referenz, einschließlich Lifecycle und Phasen.
Der erste reale Neun-Paar-Lauf ergibt aber nur +3,2488 % im Worst-D-Fall
(95%-Intervall +2,6878 bis +3,7673 %), Typical −0,5790 %, Dense −1,4010 %.
Damit ist die vorregistrierte Mindestverbesserung von 5 % verfehlt. Zusätzlich
bleiben vier Kandidaten- und drei Referenz-Blockfristverletzungen erhalten.
**Verworfen:** beide Filterdateien wieder exakt auf ihren gesicherten Ausgangsinhalt
gebracht und SHA-256 geprüft. Kein zweiter Lauf, um einen zu kleinen Gewinn durch
Wiederholen doch noch akzeptieren zu können. Messungen/Binaries bleiben erhalten;
die nützlichen Reset-/Rate-Regressionstests bleiben bestehen.

Danach separat vorregistriert: `oscillator-settled-mix-01`. Die echte, inline im
Unison-Profil erscheinende Oszillatorarbeit liest bisher fünf bereits vollständig
eingeschwungene Wellenform-Mix-Smoother pro Sample. Bei beendetem vorhandenen
Ramp-Counter kann diese wirkungslose Arbeit entfallen. Aktive Crossfades werden
unverändert fortgesetzt, auch bei Frequenz null; Pulse Width, Triangle-Zustand,
Wellenformen, Phasen und Float-Ausdrücke bleiben unverändert. Der konservative
Counter verwendet round, JUCE-Smoother floor; auch gebrochene Ramp-Längen werden
getestet. Dies ist keine eingefrorene Modulation und keine reduzierte Klangqualität.
Die zweite Idee ist noch in Prüfung; keine Effizienzfreigabe und kein Commit.

### Oszillatorvarianten: tatsächliche Entscheidungen

`oscillator-settled-mix-01` bestand Builds, frische doppelte Kurzrenders und
gezielte Regression. Der erste Neun-Paar-Lauf erreichte jedoch im vorab gewählten
D-Fall nur **4,98710896 %**, trotz positivem 95%-Intervall [4,6425561; 5,7931063] %.
Das wurde nicht auf 5 % aufgerundet. Typical: +3,4175 %, Dense: +6,6859 %;
vier Kandidaten- und eine Referenz-Blockfristverletzung bleiben dokumentiert.
Diese Variante wurde nicht akzeptiert und nicht unverändert erneut gemessen.

Danach wurde `oscillator-settled-mix-02` separat vorregistriert: dieselbe
funktionale Abkürzung, aber ohne unnötige Nullinitialisierung des temporären
Fünf-Float-Arrays im stabilen Pfad. Derselbe lokale `crossfading`-Guard schützt
Initialisierung und sämtliche Lesezugriffe. Der vorhandene Rampenzähler bleibt
maßgeblich; der laufende Rampenpfad verwendet dieselben Werte in derselben
Reihenfolge. Das ist eine tatsächliche Codeverfeinerung, kein geänderter Test,
Hotspot, Grenzwert oder verworfener Ausreißer. Die vorherige Messung wurde nicht
als Bestätigung der neuen Variante verwendet. Die beiden vollständig neuen
Neun-Paar-Läufe und die weiterhin fehlende harte Freigabe sind oben angegeben.

Beide Vorgängervarianten mitsamt Quell-Sicherungen, Binaries, Logs, Messungen und
Entscheidungen bleiben unverändert unter `experiments/` erhalten. Im aktuellen
Produktcode liegt nur Variante 02 als uncommitteter Prüfkandidat; kein deaktivierter
Filter-Cache und keine Sammlung ungemessener Optimierungen.

### Historische Zwischenstände (nicht aktueller Ausführungsstatus)

Die unten folgenden Abschnitte sind chronologische frühere Zwischenstände.
Ihre frühere Vollmatrixpflicht und aktiven Prozessangaben gelten nicht mehr.

Fortsetzung am 03.09.2026 auf „weiter“: Schutz-, Referenz- und Adapterprüfungen
erneut bestanden. Die vollständige unveränderte Release-CPU-Baseline wird jetzt
in 32 seriellen, separat nachgewiesenen Teilpaketen mit jeweils fünf Wiederholungen
gemessen. Der gestrige Teillauf wird nicht als vollständige Baseline angerechnet.
Noch keine Produktionsoptimierung, G1-Freigabe, Versionsumstellung oder Commit.

Pause am 02.09.2026 um 21:36 Uhr (Europe/Berlin): eigene Hintergrundmessung und
Koordinator wurden beendet; alle Ergebnisse und Zwischenstände bleiben erhalten.
Die CPU-Zeitmessung ist mit 718/7.920 abgeschlossenen Fällen unvollständig und
gilt nicht als bestandene Gesamt-Baseline. Die vollständigen Audio-Referenzen
und die erfolgreichen 33/33 Debug- sowie 33/33 Release-Tests sind gesichert.
Während der Pause keine Weiterarbeit, kein Commit und keine Automation.
Wiederaufnahmepunkt: `Artifacts/V0.11.5/20260902T144826Z/verification/CURRENT_CHECKPOINT.md`.

Dieser Bericht wird mit tatsächlich abgeschlossenen Prüfschritten ergänzt.
Fehlende Messungen sind ausdrücklich kein PASS. Eine Produktionsoptimierung und
die Versionsumstellung erfolgen erst nach der vollständigen Baseline und echtem
Profilingnachweis. Derzeit bleibt PROJECT_VERSION deshalb 0.11.25.

## Ausgangspunkt und Schutz

- R25 = S = `4b4d0e5867799f66b9e3db95eb70cad195b57d33`, Branch master.
- V0.11.25 wurde vom Benutzer mit „0.11.25 test bestanden“ manuell akzeptiert.
  Diese Freigabe gilt nicht vorweg für V0.11.5.
- Sound Manifest v1.0 gelesen und verbindlich; eingefrorener 62-Parameter-Vertrag,
  Plugin-Identität, 16 Stimmen, Klang, Presets und Zustände bleiben unverändert.
- Evidenzlauf: `Artifacts/V0.11.5/20260902T144826Z`.
- Vor Fresh-Konfiguration wurden 417 Referenzdateien einschließlich Original-
  Artefakten, Shared-Code/Objekten, verfügbaren Symbolen und Quellen gesichert.
- 19 Benutzerdateien einschließlich untracked Vorgaben und Cubase-Dateien wurden
  mit Pfad/Größe/SHA-256 geschützt. Kein JUCE-Eingriff, keine Systeminstallation.

## Bestandsprüfung

Die unveränderte Baseline wurde in der bestätigten Visual-Studio-2026-x64-
Developer-Umgebung frisch konfiguriert und in beiden Konfigurationen gebaut.

| Prüfung | Ergebnis |
| --- | --- |
| ursprüngliche Debug-CTests | 29/29 PASS, 343,36 s |
| ursprüngliche Release-CTests | 29/29 PASS, 54,63 s |
| Benchmark-Inventar, früher Release-Selbsttest | 7.920 valide Fälle |
| frühe doppelte Quick-Audiorenders | Debug und Release bitidentisch |
| früher Übergangs-Audiolauf Release | 420/420 ohne Fehler abgeschlossen |

Die frühen Harness-Tests sind Entwicklungsfeedback, keine komplette Baseline-
oder Performanceabnahme. Später ergänzte Diagnosefelder erfordern neue eingefrorene
Referenzläufe. Logs fehlgeschlagener Versuche bleiben erhalten.

## Messwerkzeuge und bisherige Änderungen

Neues Console-Target DeepPluckBenchmark mit echter processBlock-Verarbeitung,
expliziten Raw-Snapshots, festem Inventar, diagnostischer Voice-/FX-Erfassung,
Audio-Nullvergleich, getrenntem Timing, Metadaten und festen Bootstrap-Regeln.
Details und Syntax: `Tests/CPUProfilingBenchmark.md`.

Der Produktionscode hat bisher ausschließlich interne Test-Friend-Deklarationen
erhalten; keine neue Datenstruktur, Callback-Arbeit oder Klangfunktion wurde
eingeführt. Der vorhandene Tone-Audit kann zusätzlich seinen vollständigen Raw-
Corpus exportieren. Versionstests werden auf alle Hilfsprogramme und alle VST3-
Klassen erweitert. Alte Reports und die Sound-Abstimmung bleiben unangetastet.

Entwicklungsbefunde: Der erste Harness-Build hatte C++-Integrationsfehler, die
korrigiert wurden. Ein Sandbox-Zugriffsfehler von MSBuild erforderte den regulären
Build außerhalb dieser Einschränkung. Eine CMake-Generator-Umgebungswarnung wurde
durch explizite, nur prozesslokale Generatorangabe beseitigt. Die erste Parameter-
Selbstprüfung modellierte nur einen Konvertierungsschritt; sie folgt nun dem
realen zweistufigen JUCE-APVTS-Roundtrip und protokolliert die tatsächlichen Werte.

## Offene technische Gates

Vollständige eingefrorene Baseline einschließlich aller Wiederholungen, echte
symbolisierte Profile, registrierte isolierte Optimierung, zweimalige neun-Paar-
Bestätigung, kompletter R25/S/C-Nullvergleich, finale fünf-Paar-Performanceabnahme,
abschließende Debug-/Release-Builds/CTests, Versions-/Artefakt-/Dateischutzprüfung
und Standalone-Smokes sind noch nicht als abgeschlossen ausgewiesen.

Es gibt bisher keinen belegten Effizienzgewinn und keinen Milestone-Commit.
Die bloße Bereitstellung eines Benchmarks erfüllt das Optimierungsziel nicht.

## Laufende Referenzarbeit und Fortsetzung

Der unveränderte Referenz-Harness ist zusätzlich mit 118 Dateien unter
`reference-benchmark` eingefroren. Dessen Hashes und alle 19 geschützten
Benutzerdateien wurden während der Arbeit erneut vollständig geprüft: unverändert.
Die vollständigen frischen Doppelrenders sind in beiden Konfigurationen fertig.
Der anfangs monolithische
Debug-Audiolauf wurde zur schnelleren Durchführung durch acht deterministische
Teilmengen ersetzt; seine unvollständigen Daten bleiben ausdrücklich als
`debug-monolithic-superseded.json` gekennzeichnet erhalten. Das ist ausschließlich
Audioprüfung, keine nebenläufige CPU-Zeitmessung.

`verification/CompleteBaseline.ps1` führt derzeit die vollständigen Referenzen
unter `baseline/audio-complete` zusammen und
prüft sie. Die unabhängigen Tone-Referenzen wurden zur Zeitersparnis parallel zu
den reinen Audiorenders erstellt: Release 711 Fälle / 94,49 s, Debug 711 Fälle /
598,99 s, jeweils Exitcode 0 und `run.json` mit null Fehlern. Ihre eigenen
Programm-, Argument- und Lognachweise werden vom Koordinator vor Wiederverwendung
geprüft. Der vorher ausschließlich wartende Koordinator wurde dafür kontrolliert
ersetzt; `baseline/coordinator-03-replaced.json` hält dies fest. Die acht
Audio-Worker wurden nicht verändert oder unterbrochen. Aktuelles Koordinatorlog:
`baseline/pipeline-04.log`.

Danach folgen die neuen 33 CTests in beiden Konfigurationen und der allein
laufende fünffache Release-Zeitlauf. Betriebssystemseitige Takt-/Lastinformationen
werden zusätzlich unmittelbar vor und nach diesem Zeitlauf erfasst.
`baseline/g1-data-collected.json` bedeutet nur Datensammlung abgeschlossen; G1
verlangt anschließend die Prüfung der tatsächlichen Ergebnisse. Kein Profiling,
keine DSP-Optimierung und kein Commit werden durch diesen Koordinator gestartet.

Die Auswertungs-Selbsttests wurden mit klar gekennzeichneten synthetischen Daten
unter Windows PowerShell 5 und PowerShell 7 geprüft. Ein dabei entdeckter
Sortierfehler bei internen Paar-Tabellen wurde vor realen Paarmessungen behoben.
Fehlversuchsdateien wurden nicht entfernt. Die Zusammenführung wurde zusätzlich
an echten Quick-Audiodaten inklusive externem Sample-Nulltest geprüft.

Der komplette Release-Doppelrender hat inzwischen alle 7.920 Fälle erfolgreich
beendet (Exitcode 0). Auch dessen vollständige Rohdaten-/Coverage-Prüfung besteht:
21.705.952.032 Byte erneut gehasht, 6.192 einzigartige Matrixeingaben und alle 720
zusätzlichen identischen Eingabefälle mit gleichen Audiohashes. Nach der späteren
Zusammenführung wird dieser Nachweis erneut geprüft. Auch alle acht Debug-Shards
haben jeweils 990 Fälle zweimal vollständig gerendert; letzter Abschluss am
02.09.2026 um 20:24:35 Uhr Ortszeit. Die zusammengeführten Integritätsprüfungen
bestehen inzwischen für beide Konfigurationen vollständig (Prüfer-Exitcode jeweils
0). Ein nachträglicher Prozessbeobachter konnte Exitcode 0 für Shards
0, 2, 3 und 7 bestätigen. Bei 1, 4, 5 und 6 waren die Windows-Prozessobjekte
bereits entfernt: deren native Exitcodes sind nicht mehr verfügbar und werden
nicht aus abgeschlossenen Renderdateien abgeleitet. Nachweis:
`baseline/debug-native-exits.json`. Künftige Wrapper-Aufrufe sichern den echten
nativen Exitcode sofort als `invocation.json`; der Quick-Test
`verification/wrapper-native-exit-01` besteht mit Exitcode 0. G1 ist noch offen.
Der symbolisierte unveränderte Release-Adapter ist getrennt eingefroren. Quick-
Audio und ein vollständiger 128-Sekunden-E0-Ausklang stimmen bitidentisch mit dem
normalen Adapter überein. Eine tatsächliche Profileraufnahme hat noch nicht
stattgefunden.

Ein ergänzender synthetischer Auswertungstest hat eine Windows-PowerShell-5-
Besonderheit offengelegt: JSON-Zahlen können als Decimal eingelesen werden und
dadurch einen falschen Ungleichheitsbefund gegenüber float64-Rohzeiten erzeugen.
Der exakte Maximalwertvergleich verwendet jetzt ausdrücklich denselben float64-
Zahlenbereich. Keine Klanggrenze oder Messtoleranz wurde gelockert. Fehlversuche
`analysis-unit-07` und `-08` bleiben erhalten; `analysis-unit-09` besteht inklusive
getrennter weicher/harter Lastziel-Auswertung.

Die vollständige Release-Audiotabelle liegt unter `baseline/audio-export/Release`.
In der unveränderten maximalen M-Stressmatrix liegen sechs einzelne Kanal-Samples
in sechs Fällen über 0 dBFS; höchster Betrag ist 1,03162491321563721 bei
`M-r48000-b512-p16-u1-stress1-fx1-osc20` (linker Kanal). Dies ist bereits in S/R25
vorhanden, kein neuer Optimierungsfehler. Die Rohwerte werden weder normalisiert
noch begrenzt; dieser Milestone ändert zur Verbesserung einer Messzahl keinen
Ausgangspegel. A–E, W, X und die Übergangsreferenzen haben in diesem Durchgang
keine Samples über 0 dBFS. Dies ersetzt nicht die getrennten bestehenden
Normal-/Stress-Headroom-Tests oder eine manuelle Lautheitsbeurteilung.

`ExportCPUListeningWave.ps1` ergänzt einen bytegetreuen Float32-WAV-Export für
später ausgewählte Extremfälle. Synthetische Container-/Rohdaten-Rücklesetests
und sechs negative Fälle bestehen und sind in benchmark_manifest integriert.
Ein echter Export des genannten maximalen M-Referenzfalls wurde ebenfalls
byteweise verifiziert (`listening/reference-extreme-01`). Das ist ausschließlich
S/R25-Material, kein vorweggenommener Kandidatenrender oder Hörtest.

Die erneute Schutzprüfung `verification/protected-evidence-01.json` bestätigt
19 Benutzerdateien, 417 ursprüngliche Referenzdateien, 118 normale und 86
symbolisierte Adapterdateien unverändert per Größe/SHA-256. JUCE ist unverändert;
kein verbotener Pfad ist gestagt.

## Neuer Prüfstand am 02.09.2026, 21:05 Uhr

Der frische Debug-Build des vollständigen Messsystems besteht. Die erste komplette
Debug-Serie endet mit 32/33: ausschließlich `benchmark_manifest` scheitert am
fehlenden `Get-FileHash`-Import in einer Windows-PowerShell-5-Instanz, die über
VS/cmd den Modulpfad von PowerShell 7 geerbt hat. Der Fehler ist reproduziert.
`CPUReportIO.ps1` lädt jetzt das Standardmodul aus dem `PSHOME` des tatsächlich
laufenden Hosts; globale Einstellungen bleiben unverändert. Der isolierte
Wiederholungstest besteht mit nativem Exitcode 0 (89,73 s). Alle 33 Debug-Tests
werden zur Absicherung erneut ausgeführt, danach Release. Ursprüngliche Fehlerlogs
bleiben erhalten. Aktueller Koordinator: `verification/ResumeBaselineAfterHarness.ps1`,
Log `baseline/pipeline-05.log`. Die normale vollständige CPU-Messung steht noch aus.

Der VS-Profilingzugang ist separat an einem eigenen kurzen arithmetischen
Testprozess geprüft. Sein JSON-Konfigurationslader scheitert an der installierten
Newtonsoft-Assemblyversion; mit registriertem direktem CPU-Agenten und vorher
angelegten lokalen Ausgabeordnern funktioniert die Aufzeichnung. Native Exitcodes
allein reichen bei diesem Werkzeug nicht, da es auch Fehler mit 0 beendet. Der
echte Testtrace enthält 5.190 Samples des eigenen Prozesses, davon 5.189 mit
Aufrufstapel, bei 1-ms-Sampling; Prozess-Exit 0. Der eingefrorene native PDB lässt
sich lokal ohne Netzwerk-Symbolsuche öffnen. Nachweise: `profiling/tool-access-probe-05`
und `profiling/pdb-reader-probe-02`. Dies sind Werkzeugprüfungen, keine DSP-Profile.
Windows WPR fehlt im aktuellen Token das Profilingrecht; der funktionierende
direkte VS-Zugang macht dies derzeit nicht zum externen Blocker. Es wurde nichts
installiert und keine Windows-Sicherheitsrichtlinie verändert.

## Aktualisierung: 21:20 Uhr

Die vollständige Debug-Wiederholung besteht mit 33/33; Release-Build und alle
33 Release-Tests bestehen ebenfalls. Release-CTest: 208,16 s. In den beiden
aktuellen Buildlogs sind keine C-/LNK-/MSB-Compiler- oder Buildwarnungen/-fehler
gefunden. Die erneuten Schutz-, Quellcodegleichheits- und Provenienzprüfungen
bestehen (`protected-evidence-02`, `normal-adapter-code-equivalence-02`,
`reference-provenance-03`). Die allein laufende normale Release-CPU-Baseline über
7.920 Fälle mit fünf Wiederholungen hat nach Erfassung der Betriebsbedingungen
begonnen. Während dieses Laufs keine weiteren Builds, Audioprüfungen, Auswertungen
oder Profiler-Aufnahmen. Eine bestandene G1-Freigabe oder Effizienzverbesserung
wird damit noch nicht behauptet.

## Manuelle Prüfungen

Neue klangliche A/B-Abnahme, Lautheits-/Klickvergleich, Cubase-Last-/ASIO-Prüfung,
Automation/Projekt-Recall und praktischer Standalone-Audio-/MIDI-Test bleiben für
V0.11.5 offen. Automatisierte Offline-Renders ersetzen keine dieser Prüfungen.
