DEEPPLUCK - MASTER IMPLEMENTATION SPECIFICATION
MILESTONE V0.3.0 - FILTER ENGINE
REVISION 1

Verbindlicher Entwicklungsauftrag für Codex
Dokumentstatus: vollständig, eigenständig, copy-ready
Zielsprache des Codes: Englisch
Zielsprache der Projektdokumentation: bestehende Projektsprache beibehalten

===============================================================================
0. DOKUMENTCHARAKTER UND AUFTRAG
===============================================================================

Dieses Dokument ist die vollständige und allein maßgebliche Implementierungs-
spezifikation für DeepPluck Milestone V0.3.0 - Filter Engine. Es ist kein
Patch, kein Nachtrag und keine lose Ideensammlung. Frühere Master-Prompts sind
nur historische Referenz. Bei Widersprüchen gilt die in Abschnitt 2 definierte
Priorität.

Du arbeitest als verantwortlicher C++-/JUCE-Audioentwickler im vorhandenen
lokalen Git-Repository von DeepPluck. Implementiere V0.3.0 vollständig auf
Basis des tatsächlich vorgefundenen, bestätigten V0.2.0b-Stands.

Ziel ist ein fokussierter, hochwertiger subtraktiver Filterpfad, der aus der
bereits musikalischen PolyBLEP-Saw einen warmen, weichen, runden und emotionalen
Deep-House-Pluck formt. Implementiert wird genau ein 24-dB-Tiefpass mit
Resonanz, Pre-Filter Drive, Key Tracking, bipolarer Filter-Envelope-Intensität
und eigener Live-Filter-Hüllkurve. Qualität, Sweet Spots und Spielgefühl haben
Vorrang vor Funktionsanzahl und Extremwerten.

Arbeite selbstständig bis zur vollständigen automatisierbaren Definition of
Done. Erfinde keine Ergebnisse. Ein nicht selbst ausgeführter Hör-, GUI- oder
Cubase-Test ist exakt als

MANUAL VERIFICATION REQUIRED

zu kennzeichnen. Behaupte niemals einen erfolgreichen Build, Test, Benchmark,
Host-Test, Hörtest oder eine Sichtprüfung, wenn er nicht tatsächlich stattfand.

Keine Systeminstallation, kein Download, kein Push und keine Änderung außerhalb
des Repositorys. JUCE nicht verändern. Das VST3 nicht automatisch in einen
Systemordner installieren. Bestehende Benutzeränderungen niemals verwerfen,
verstecken, automatisch stashen oder ungefragt überschreiben.


===============================================================================
1. PROJECT VISION UND ENTWICKLUNGSPHILOSOPHIE
===============================================================================

DeepPluck ist ein spezialisiertes Softwareinstrument für inspirierende,
hochwertige Pluck-Sounds in Deep House, Melodic House, Organic House,
Progressive House und angrenzenden Stilen.

DeepPluck ist kein allgemeiner Synthesizer und keine Technologie-Demonstration.
Die Anzahl der Features ist kein Qualitätsmerkmal. Das Instrument soll warm,
weich, fokussiert, kontrolliert, elegant, emotional, modern und sofort spielbar
wirken.

Der Filter muss:

- den trockenen PolyBLEP-Saw musikalisch formen statt nur Höhen abzuschneiden
- den charaktertragenden Mittenbereich bewahren
- hohe Frequenzen weich und seidig statt scharf oder gläsern gestalten
- den Bass kontrolliert und definiert halten
- durch Envelope, Resonanz, Drive und Key Tracking lebendig reagieren
- breite musikalische Sweet Spots statt spektakulärer Extremzustände liefern
- Dynamik, Velocity-Reaktion und Headroom des Instruments erhalten

Jede Entscheidung muss mindestens einem dieser Ziele dienen:

- bessere musikalische Ausdruckskraft
- bessere trockene Klangqualität
- klarerer Workflow
- höhere Stabilität oder Wartbarkeit

Bei zwei technisch korrekten Lösungen gewinnt die hörbar musikalischere
Lösung, sofern Realtime-Sicherheit, Stabilität und Kompatibilität gewahrt sind.
Mathematische Eleganz allein rechtfertigt keine schlechter klingende Lösung.

Verbindliche Priorität:

1. Sicherheit und Schutz vorhandener Arbeit
2. Realtime-Sicherheit
3. musikalische Qualität und Sound Manifest
4. technische Korrektheit und Stabilität
5. Rückwärts- und State-Kompatibilität
6. Wartbarkeit und Lesbarkeit
7. messbare Performance
8. Feature-Wachstum

Der trockene Grundklang hat Vorrang. Effekte dürfen später veredeln, aber nie
einen schwachen Oszillator-, Envelope- oder Filterpfad kaschieren.


===============================================================================
2. NORMATIVE DOKUMENTE UND PRIORITÄT
===============================================================================

Vor Planung, Codeänderung oder Build vollständig lesen:

- AGENTS.md
- Docs/Sound/DeepPluck_Sound_Manifest_v1.0.md
- README.md
- ARCHITECTURE.md
- Docs/DeepPluck_V0.2.0b_MasterPrompt_Rev2.txt
- Docs/DeepPluck_V0.2.0b_Implementation_Report.md
- vorhandene ältere Master-Prompts nur als Historie
- CMakeLists.txt
- alle betroffenen produktiven Dateien unter Source/
- alle vorhandenen Tests und die CTest-Registrierung
- .gitignore

Das Sound Manifest ist ein normatives Produkt- und Klangdokument. Es ist keine
optionale Inspiration. Der Filter muss insbesondere dessen Filter-, Dynamics-,
Tonal-Balance-, Modulation-, CPU-, GUI- und Preset-Philosophie erfüllen.

Priorität bei echten Widersprüchen:

1. Sicherheit, aktuelle Benutzeranweisung und bindende AGENTS.md
2. Sound Manifest für Produkt-, Klang- und Musikalitätsentscheidungen
3. diese Master-Spezifikation
4. validierte bestehende Architektur und Kompatibilitätsverträge
5. lokale JUCE-9-API und vorhandener Projektstil

Wenn eine technische Detailvorgabe nachweislich nicht zur lokalen JUCE-Version
oder zur validierten Architektur passt, wähle die kleinste fachlich gleichwertige
Lösung. Abweichung, Grund, Auswirkungen und Tests müssen im Abschlussbericht
stehen. Scope-Erweiterungen sind dadurch nicht erlaubt.

Der Abschlussbericht muss ausdrücklich beantworten:

Does this make DeepPluck a better instrument for emotional Deep House plucks?


===============================================================================
3. BESTÄTIGTER AUSGANGSZUSTAND V0.2.0b
===============================================================================

V0.2.0b ist gebaut, automatisiert verifiziert und manuell hinsichtlich der
kritischen Envelope-Verträge bestätigt. Der bestätigte Stand umfasst:

- JUCE-9-CMake-Projekt für Windows x64
- VST3 und Standalone
- Instrument ohne Audioeingang, Stereoausgang, MIDI-In, kein MIDI-Out
- 16 vorab erzeugte Stimmen und genau einen DeepPluckSound
- samplegenaue MIDI-Unterteilung
- per Stimme eine bandbegrenzte PolyBLEP-Saw
- eigene DeepPluckEnvelope mit idle, attack, decay, sustain und release
- sofortiger Release bei Note-Off aus Attack, Decay und Sustain
- live wirksame Attack-, Decay-, Sustain- und Release-Parameter
- laufende Releases reagieren weich auf kürzere und längere Release-Zeiten
- musikalisches, deterministisches Voice-Stealing
- lineare Velocity-Amplitude
- Tune-Smoothing pro aktiver Stimme
- fester konservativer Voice Gain
- globales Output-Gain-Smoothing nach der Stimmsumme
- APVTS-Parameter-Cache und ein Parameter-Snapshot pro Audioblock
- kompatible State-Migration aus älteren Versionen
- vier trockene Factory-Presets: Deep Pluck, Soft Pluck, Tight Pluck, Long Pluck
- Presetauswahl mit Custom-Zustand
- lokale Debug-/Release-Artefakte und sieben CTest-Suites

Bestätigte V0.2.0b-Messwerte:

- PolyBLEP-Aliasenergie: 2,86 Prozent der naiven Saw im vorhandenen Test
- Default-Peak bei 16 Stimmen: 0,549 bei einer Grenze von 0,95
- Debug und Release erfolgreich
- alle sieben Testsuites in beiden Konfigurationen erfolgreich
- Standalone-Starttest erfolgreich

Historische V0.2.0b-Commits laut Abschlussstand:

- e2bc67f - Implementierung
- d902144 - Abschlussbericht

Diese Angaben sind Referenz, kein Reset-Auftrag. Der reale Repository-Stand ist
vor Arbeitsbeginn zu prüfen. Die manuell bestätigten Amp-Envelope-Verträge sind
Regression Contracts und dürfen nicht verändert werden.


===============================================================================
4. LESSONS LEARNED UND VERBINDLICHE FOLGERUNGEN
===============================================================================

1. Die vorhandene Grundarchitektur ist stabil. Sie wird erweitert, nicht neu
   erfunden.

2. Plugin-Laden, Automation, State-Restore, Presets und Projekt-Rückruf sind
   wertvolle Verträge und dürfen nicht regressieren.

3. Die projektspezifische Live-Envelope ist die richtige Basis für eine zweite
   Hüllkurve. Keine Rückkehr zu starren Note-On-Snapshots.

4. Ein Note-Off ist auch für die Filter-Envelope ein sofortiges musikalisches
   Ereignis. Attack und Decay dürfen nicht erst beendet werden.

5. Eine laufende Filter-Release-Phase muss auf kürzere und längere Release-
   Zeiten weich reagieren.

6. Automatisierte DSP-Tests beweisen Stabilität und Verträge, aber nicht den
   musikalischen Klang. Listening Acceptance bleibt Pflicht.

7. Der Filter wird pro Stimme vor der Amp-Envelope verarbeitet. Ein globaler
   Filter nach der Stimmsumme würde Noten und Envelopes unmusikalisch koppeln.

8. Hohe Resonanz ist ein Stabilitätsfall, kein Anlass für einen Limiter oder
   eine harte Sample-Clamp als Fehlerverdeckung.

9. Click-freier Bypass ist Teil des Instruments und kein reines GUI-Detail.

10. Der Milestone bleibt klein: genau ein Filtermodell, keine parallelen
    Klangquellen und keine Effekte.


===============================================================================
5. BESTANDSAUFNAHME UND SCHUTZREGELN
===============================================================================

Vor jeder Änderung mindestens:

- Git-Status, letzte Commits, unstaged und staged Diff erfassen
- Projektstruktur außerhalb generierter Verzeichnisse erfassen
- normative Dokumente und betroffenen Code vollständig lesen
- Parameterlayout, State-Migration, Presets, Voice-Lifecycle, MIDI-Aufteilung,
  Oszillator, Amp-Envelope, Synthesiser, Processor, Editor und Tests verstehen
- vorhandene Build- und Artefaktkonventionen prüfen
- bestehende Debug-/Release-Tests soweit sicher ausführbar als Baseline laufen
- Abweichungen zwischen dieser Spezifikation und realem Code notieren

Bereits bekannte untracked historische Dateien und Cubase-Testdaten nicht in
den Milestone aufnehmen, verändern oder löschen, sofern sie nicht ausdrücklich
zum bestätigten Scope gehören. Insbesondere bestehende CubaseTest/-Inhalte und
alte Rev1-Prompts unangetastet lassen.

Keine Benutzeränderung zurücksetzen, automatisch stashen, ungefragt formatieren
oder in einen Milestone-Commit aufnehmen. Bei Überschneidungen den kleinsten
sicheren Patch wählen. Bei einer nicht sicher lösbaren Kollision stoppen und
den konkreten Konflikt melden.

Generierte Build-Dateien und lokale Artefakte niemals als Source committen.
Keine breitflächige Formatierung und kein Architektur-Rewrite.


===============================================================================
6. PRODUKTIDENTITÄT, VERSION UND KOMPATIBILITÄT
===============================================================================

Produktname: DeepPluck
Hersteller: ToneTrax
Bundle Identifier: de.tonetrax.deeppluck
Plugin-Typ: Instrument
Formate: VST3 und Standalone
Milestone: V0.3.0 - Filter Engine

Unverändert bewahren:

- Bundle Identifier
- PLUGIN_MANUFACTURER_CODE Tntx
- PLUGIN_CODE DpV1
- Plugin-Name und Produktname DeepPluck
- VST3-Identität und alle daraus abgeleiteten IDs
- Plugin-Typ, Kategorien, Buslayout und MIDI-Vertrag
- vorhandene Format- und State-Struktur
- bestehende sechs Parameter-IDs und ihre Semantik

Cubase muss V0.3.0 als dasselbe Plugin erkennen. Keine neue Plugin-ID, kein
Parallelprodukt und kein inkompatibler State-Schema-Neustart.

CMake erhält die numerische Version 0.3.0. Sichtbare Entwicklungskennzeichnung,
falls im Projekt vorhanden: "Development Build V0.3.0". Beschreibung sinnvoll
auf den Filter-Engine-Stand aktualisieren, ohne Identitätsfelder zu ändern.

Die stabilen vorhandenen Parameter-IDs bleiben exakt:

- outputGain
- masterTune
- ampAttack
- ampDecay
- ampSustain
- ampRelease

Keine vorhandene ID umbenennen, neu verwenden, in der Reihenfolge unnötig
verschieben oder semantisch brechen. Neue IDs werden ausschließlich angehängt.

State-Kompatibilitätsvertrag:

- V0.1.0-, V0.2.0a- und V0.2.0b-States müssen weiterhin sicher laden.
- Vorhandene Werte werden übernommen; fehlende V0.3.0-Parameter erhalten ihre
  dokumentierten Defaults.
- V0.3.0-State muss vollständig und deterministisch rückrufbar sein.
- Unbekannte, ungültige oder nicht-finite Werte dürfen keinen Crash, NaN oder
  unbeschränkten Zustand erzeugen.
- Die vorhandene mergeRestoredState-Strategie nur minimal erweitern und testen.
- Ein alter State darf nie durch pauschales Zurücksetzen auf neue Defaults
  beschädigt werden.


===============================================================================
7. MILESTONE-ZIEL UND USER EXPERIENCE
===============================================================================

Ein Musiker soll DeepPluck laden und ohne Effekte unmittelbar einen
charakteristischen, emotionalen Deep-House-Pluck hören. Der Default-Zustand
muss den Filter hörbar, aber nicht übertrieben einsetzen.

Der Musiker soll mit wenigen klaren Reglern:

- die Grundhelligkeit bestimmen
- den Pluck durch eine kurze Filterbewegung artikulieren
- Resonanz als Farbe statt als aggressive Spezialwirkung verwenden
- mit Drive Wärme und Dichte vor dem Filter erzeugen
- über die Tastatur hinweg eine konsistente Helligkeit einstellen
- mit bipolarer Envelope-Intensität sowohl öffnende als auch schließende
  Bewegungen erzeugen
- den Filter für einen echten A/B-Vergleich click-frei deaktivieren

Default und Factory-Presets müssen auch ohne spätere Effekte überzeugen.


===============================================================================
8. VERBINDLICHER SCOPE UND LIEFERUMFANG
===============================================================================

Verbindlicher Scope:

1. genau einen hochwertigen 24-dB-Low-Pass-Filter implementieren
2. Filter pro Stimme instanziieren und verarbeiten
3. Cutoff, Resonance und Pre-Filter Drive implementieren
4. musikalisches Key Tracking implementieren
5. bipolaren Filter-Envelope Amount implementieren
6. dedizierte Live-Filter-Envelope implementieren
7. sofortigen Note-Off aus jeder aktiven Pre-Release-Stage sicherstellen
8. live wirksame Filter-Envelope-Zeiten einschließlich laufender Releases
9. click-freien Filter-Bypass implementieren
10. alle kontinuierlichen Audioparameter angemessen glätten
11. Defaults, GUI und bestehende vier Factory-Presets erweitern
12. State- und Preset-Kompatibilität erhalten
13. Headroom und Stabilität über den vollständigen Parameterraum absichern
14. automatisierte DSP-, Parameter-, State-, Lifecycle- und Regressionstests
15. Listening Acceptance Tests und Cubase-Validierung
16. Dokumentation, lokale Artefakte, Git und Abschlussbericht

Der Milestone ist erst fertig, wenn Implementierung, Tests, Dokumentation und
ehrliche Verifikation als zusammenhängendes Ergebnis vorliegen.


===============================================================================
9. ANTI-GOALS UND NICHT-ZIELE
===============================================================================

Nicht in V0.3.0 implementieren:

- zweiten Oszillator
- Noise-Generator oder Samples
- Unison, SuperSaw, Voice-Stacking oder Stereo-Spread
- weitere Filtertypen, Flankensteilheiten oder Filtermodelle
- High-Pass, Band-Pass, Notch, Comb oder Formantfilter
- Filter-Routing-Auswahl, seriell/parallele Filter oder Morphing
- LFO, Modulationsmatrix, Macros oder Aftertouch-Modulation
- FM, Ringmodulation, Hard Sync, Wavetables oder Chord Memory
- Chorus, Delay, Reverb, Distortion, Saturation als separater Effekt,
  Compressor, Limiter, Exciter oder Clipper
- Oversampling als eigenständiges Feature oder Qualitätsmarketing
- Preset-Browser oder externe Preset-Dateiformate
- neues GUI-Designsystem, Visualizer, Meter oder Animationen
- frei konfigurierbares Routing
- Architektur-Rewrite oder parallele Engine
- generischen Synthesizer-Funktionsumfang

Pre-Filter Drive ist ein integraler Bestandteil der Filterstufe, kein frei
routbarer Distortion-Effekt. Er rechtfertigt keine FX-Infrastruktur.

Keine zusätzlichen versteckten Sound-Features. Wenn ein Problem nur durch ein
Out-of-Scope-Feature lösbar scheint, Ursache neu analysieren und die kleinste
innerhalb des Scopes korrekte Lösung wählen oder die Grenze dokumentieren.


===============================================================================
10. VERBINDLICHE ARCHITEKTUR UND SIGNALFLUSS
===============================================================================

Bestehende Verantwortungstrennung erhalten und so erweitern:

MIDI
  -> DeepPluckAudioProcessor
  -> DeepPluckSynthesiser, maximal 16 Stimmen
  -> DeepPluckVoice
       PolyBLEP Saw
       -> Filter-Modul
            Pre-Filter Drive
            -> 24-dB Low-Pass
            Modulation durch Filter Envelope und Key Tracking
            click-freier Wet/Bypass-Crossfade zum trockenen Saw
       -> Amp Envelope
       -> Velocity
       -> fester Voice Gain
  -> Stereo-Stimmensumme
  -> geglätteter globaler Output Gain
  -> Stereo Output

"Wet" bezeichnet hier ausschließlich den aktivierten Filterpfad, nicht einen
neuen Wet/Dry-Hostparameter. Der Benutzer erhält einen klaren Filter-On/Off-
Schalter. Bei On ist der Filter vollständig aktiv; bei Off ist der Saw-Pfad
ungefiltert. Zwischenzustände existieren nur intern für den click-freien
Crossfade.

Der Filter liegt zwingend pro Stimme vor der Amp-Envelope. Damit besitzen
gleichzeitig klingende Noten unabhängige Filterzustände und Filter-Envelopes.
Ein globaler Filter nach der Stimmsumme ist nicht zulässig.

Empfohlene klare Klassenverantwortung:

- DeepPluckFilter kapselt Algorithmus, internen Zustand, Koeffizienten,
  Stabilitätsgrenzen und Sample-Verarbeitung.
- DeepPluckVoice besitzt genau einen Filter und eine zweite Instanz der
  projektspezifischen Envelope für die Filtermodulation.
- DeepPluckParameters definiert IDs, Bereiche, Defaults, Cache und Snapshot.
- DeepPluckPresets speichert vollständige musikalische Parameterzustände.
- PluginProcessor liest jeden Hostparameter höchstens einmal pro Block und
  stellt den Snapshot der Synth-/Voice-Schicht bereit.
- PluginEditor zeigt und bindet Parameter, enthält aber keine DSP-Logik.

DeepPluckEnvelope soll wiederverwendet oder minimal generalisiert werden, wenn
dies ohne Regression und ohne generische Modulations-Engine möglich ist. Keine
duplizierte zweite ADSR-State-Machine nur für den Filter. Amp- und Filter-
Envelope besitzen getrennten Laufzustand und getrennte Parameter.

Genau ein globaler Output Gain bleibt nach der vollständigen Stimmsumme. Kein
automatischer Gain, Limiter oder Compressor darf instabile Filterpeaks
kaschieren.


===============================================================================
11. FILTERALGORITHMUS UND 24-dB-VERTRAG
===============================================================================

Implementiere genau einen resonanten 4-Pol-Low-Pass mit nominal 24 dB pro
Oktave im Sperrbereich. Der Algorithmus muss für zeitvariable Cutoff- und
Resonanzwerte geeignet, bei allen unterstützten Sample Rates stabil und im
Audiothread deterministisch sein.

Bevorzugt ist eine gut verstandene topology-preserving-transform-/zero-delay-
feedback-basierte 4-Pol-Struktur oder eine fachlich gleichwertige, überprüfbare
Lösung. Eine Kaskade aus zwei sauber abgestimmten 2-Pol-TPT-Stufen ist zulässig,
wenn Resonanzverhalten, Flankenvertrag, Modulation und Stabilität die Tests und
Hörabnahme erfüllen. Ein biquadbasierter Ansatz ist nur zulässig, wenn die
Koeffizientenmodulation nachweislich artefaktarm und alle Extremfälle stabil
sind.

Nicht zulässig:

- vier naive One-Pole-Filter ohne korrektes Resonanz-Feedback
- ein 12-dB-Filter mit irreführender 24-dB-Beschriftung
- ein globaler Filter nach der Stimmsumme
- harte Sample-Clamps als normale Stabilitätsstrategie
- ein Limiter hinter dem Filter als Ersatz für einen stabilen Algorithmus
- unkontrollierte Selbstoszillation oder exponentiell wachsende Zustände
- Neuberechnung teurer, unveränderter Koeffizienten für jeden Kanal
- impliziter Filtertypwechsel im Parameterraum

Verträge:

- mono-intern pro Voice; dasselbe Voice-Sample wird wie bisher auf beide
  Ausgangskanäle addiert
- prepare(sampleRate) initialisiert alle abhängigen Werte deterministisch
- reset() löscht alle Zustände und Denormal-Reste deterministisch
- processSample ist endlich, bounded, allokationsfrei und für den Hot Path
  geeignet
- Cutoff-/Resonanzänderungen resetten keinen Filterzustand
- Note-On beginnt mit einem definiert zurückgesetzten Filterzustand
- Hard Stop und Voice Reuse hinterlassen keinen alten Filtertail in der neuen
  Note
- Voice-Stealing bleibt click-arm; vorhandener Residual-Tail-Vertrag darf
  nicht regressieren
- bei Filter-On wird der 24-dB-Charakter messbar und hörbar erreicht
- Passband und Resonanz färben musikalisch, ohne den Mittenkern auszuhöhlen

Der genaue Algorithmus, seine Gleichungen, Resonanzabbildung, Stabilitätsgrenzen
und Gründe für die Wahl sind in ARCHITECTURE.md zu dokumentieren.


===============================================================================
12. CUTOFF UND GESAMTMODULATION
===============================================================================

Der Filter-Cutoff wird musikalisch im logarithmischen Frequenzraum gebildet.
Verbindliches Modell:

baseOctaves = log2(smoothedBaseCutoffHz / referenceHz)
keyOffsetOctaves = ((midiNote - 60) / 12) * keyTracking
envOffsetOctaves = smoothedEnvAmountOctaves * filterEnvelopeValue
targetCutoffHz = referenceHz
                 * 2^(baseOctaves + keyOffsetOctaves + envOffsetOctaves)

Eine algebraisch gleichwertige Implementierung ist zulässig. referenceHz darf
zweckmäßig gewählt werden und muss sich aus der Gleichung herauskürzen; der
Hostparameter bleibt eine absolute Basisfrequenz in Hz.

Verträge:

- MIDI-Note 60 ist die neutrale Key-Tracking-Referenz.
- 0 Prozent Key Tracking erzeugt keinen Notenoffset.
- 100 Prozent Key Tracking verschiebt den Cutoff um exakt eine Oktave pro
  gespielter Oktave.
- positiver Envelope Amount öffnet den Filter mit steigendem Envelope-Wert.
- negativer Envelope Amount schließt ihn mit steigendem Envelope-Wert.
- 0 Envelope Amount erzeugt keine Envelope-Modulation.
- Envelope und Key Tracking addieren sich in Oktaven, nicht linear in Hz.
- der endgültige Cutoff wird nach allen Modulationen auf einen sicheren,
  sample-rate-abhängigen DSP-Bereich begrenzt.
- empfohlene technische Obergrenze: min(20000 Hz, 0.45 * sampleRate), sofern
  der gewählte Algorithmus keine nachweislich strengere Grenze benötigt.
- technische Untergrenze: 20 Hz.
- Clamping muss weich im Verhalten und frei von NaN/Inf sein.
- extreme Kombinationen dürfen weder DC-Explosion noch instabile Zustände
  erzeugen.

Die Filter-Envelope wird pro Sample ausgewertet. Der resultierende Cutoff darf
pro Sample oder in nachweislich artefaktarmen kleinen Teilstücken aktualisiert
werden. Blockweise Sprünge der Envelope-Modulation sind nicht zulässig.


===============================================================================
13. RESONANZ UND STABILITÄT
===============================================================================

Resonance ist ein musikalisch normalisierter Hostparameter von 0 bis 100
Prozent. Die interne Abbildung auf Q, Damping oder Feedback ist vom gewählten
Algorithmus abhängig und muss dokumentiert sowie getestet werden.

Klangziel:

- 0 bis etwa 40 Prozent: subtile Formung und Wärme
- etwa 40 bis 75 Prozent: klar hörbare, musikalische Betonung
- etwa 75 bis 100 Prozent: ausdrucksstark, aber kontrolliert und brauchbar
- keine aggressive Lautheitsexplosion im normalen Default-/Presetbereich
- kein plötzliches Umschlagen in digitales Kreischen

Selbstoszillation ist kein Produktziel. Falls der gewählte Algorithmus nahe dem
Maximum technisch eine gedämpfte Sinusantwort erzeugt, muss sie bounded,
vorhersehbar und musikalisch kontrollierbar bleiben. Ohne Eingang darf kein
unbeschränkt wachsendes Signal entstehen.

Stabilitätsverträge für jede unterstützte Sample Rate und Blockgröße:

- alle Samples und internen beobachtbaren Zustände bleiben endlich
- keine NaN, Inf, Denormals oder persistierende DC-Explosion
- Resonanzsprünge und Sweeps resetten den Filter nicht
- Kombination aus maximaler Resonanz, maximalem Drive und Cutoff-Grenzen bleibt
  stabil
- nach Hard Stop und reset folgt deterministische Stille
- nach endlichem Input klingt ein resonanter Tail bounded ab oder bleibt in
  einer ausdrücklich dokumentierten, bounded Betriebsart

Eine sanfte, algorithmisch integrierte Nichtlinearität im Feedbackpfad ist
zulässig, wenn sie Stabilität und musikalischen Charakter verbessert. Sie darf
nicht zu einem zweiten undokumentierten Drive-Regler oder zu unkontrolliertem
Aliasen führen.


===============================================================================
14. PRE-FILTER DRIVE
===============================================================================

Drive liegt pro Stimme unmittelbar vor dem 24-dB-Filter. Er soll dem Saw Wärme,
Dichte und organische Obertöne geben und die Resonanz musikalisch anregen.

Signalvertrag:

PolyBLEP Saw -> Drive Gain / weiche Sättigung -> 24-dB Low-Pass

Verträge:

- 0.0 dB ist transparent oder praktisch transparent und ohne Pegelsprung
  gegenüber dem linearen Eingangspfad.
- steigende Werte erhöhen hörbar Dichte und harmonische Färbung.
- eine glatte, ungerade, DC-symmetrische Kennlinie verwenden.
- keine harte Clipping-Kante.
- keine eigene FX-Infrastruktur.
- keine automatische Lautheitsnormalisierung, die den Drive-Effekt unhörbar
  macht; eine dokumentierte konservative Pegelkompensation ist zulässig.
- keine signifikante DC-Verschiebung bei symmetrischem Eingang.
- keine Allokation und keine teure ungebundene Arbeit im Hot Path.
- maximale Werte müssen gemeinsam mit hoher Resonanz stabil bleiben.

Der gewählte Sättigungsansatz und eine eventuelle Pegelkompensation sind in
ARCHITECTURE.md zu dokumentieren. Drive darf den Default nicht aggressiv,
kratzig oder überkomprimiert machen.


===============================================================================
15. DEDIZIERTE LIVE-FILTER-ENVELOPE
===============================================================================

Jede Stimme besitzt zusätzlich zur Amp-Envelope eine unabhängige Filter-
Envelope mit den Stages:

- idle
- attack
- decay
- sustain
- release

Sie verwendet dieselben bewährten musikalischen Kurven-, Live-Update- und
Eventverträge wie die V0.2.0b-Amp-Envelope. Bevorzugt wird eine zweite Instanz
von DeepPluckEnvelope mit getrennten Parametern und getrenntem Zustand.

Allgemeine Verträge:

- Ausgabe immer endlich und in [0, 1]
- Stage-Wechsel ohne Pegelsprung
- keine Klicks, Zipper-Artefakte oder Envelope-Neustarts durch Automation
- keine exp()/pow()-Berechnung pro Sample
- keine Allokation, Locks oder unbeschränkte Arbeit
- Koeffizienten nur bei prepare, Parameterübernahme, Event oder Stage-Wechsel
  aktualisieren
- reset deterministisch; Hard Stop setzt sofort idle und 0
- nach Release-Ende exakt 0, idle und isActive false
- Denormals vermeiden

Kurvenziele entsprechen der Amp-Envelope:

- Attack: monoton von 0 nach 1, schneller musikalischer Beginn und weiches
  Annähern an den Peak; Attack Target Ratio 0.30
- Decay: monoton vom aktuellen Peak zum Sustain-Level, schnellerer Beginn und
  weicher Tail; Decay Target Ratio 0.0001
- Sustain: stabiler oder weich zum live geänderten Ziel wandernder Pegel
- Release: monoton und weich vom exakt aktuellen Level nach 0; Release Target
  Ratio 0.0001

Falls DeepPluckEnvelope generalisiert wird, müssen Timingdefinition, Kurven und
Regressionstests der Amp-Envelope unverändert bleiben. Keine neue generische
Modulationsarchitektur bauen.


===============================================================================
16. LIVE-UPDATE-VERTRAG DER FILTER-ENVELOPE
===============================================================================

filterAttack, filterDecay, filterSustain und filterRelease sind live wirksam.
Sie werden nicht dauerhaft beim Note-On eingefroren.

Filter Attack während Attack ändern:

- kürzer: vom aktuellen Wert aus beschleunigen
- länger: vom aktuellen Wert aus verlangsamen
- kein Reset auf 0
- kein Sprung zum Ziel
- Stage-Fortschritt und neue Zeit konsistent neu berechnen

Filter Decay während Decay ändern:

- kürzer: vom aktuellen Wert aus schneller zum aktuellen Sustain-Ziel
- länger: vom aktuellen Wert aus langsamer zum aktuellen Sustain-Ziel
- kein Sprung und kein Neustart vom Peak

Filter Sustain während Decay oder Sustain ändern:

- Ziel live aktualisieren
- Übergang stetig und monoton in Richtung des neuen Ziels
- keine hart gesetzte Pegelkante
- Decay bleibt semantisch Decay zum aktuellen Ziel

Filter Release während laufendem Release ändern:

- kürzer: vorhandener Tail wird sofort hörbar und weich kürzer
- länger: vorhandener Tail wird sofort hörbar und weich länger
- vom exakt aktuellen Envelope-Wert weiterrechnen
- niemals zum Note-Off-Level oder zu einem früheren Segmentanfang springen
- Envelope nicht neu triggern
- keine Pegelerhöhung durch reine Release-Zeit-Änderung

Sonderfälle:

- Zeit am Minimum beendet die Stage innerhalb der dokumentierten Mindestzeit
- nicht-finite Werte werden durch sichere Defaults ersetzt
- Werte werden an den technischen Grenzen geclamped
- mehrere Änderungen im selben Audioblock bleiben deterministisch
- Filter-Envelope-Automation darf die Amp-Envelope nicht beeinflussen


===============================================================================
17. NOTE-OFF-VERTRAG DER FILTER-ENVELOPE
===============================================================================

Note-Off ist nicht verhandelbar:

- Note-Off während Filter Attack -> sofort Filter Release
- Note-Off während Filter Decay -> sofort Filter Release
- Note-Off während Filter Sustain -> sofort Filter Release
- Note-Off während Filter Release -> kein Neustart, kein Pegelsprung
- Hard Stop -> beide Envelopes und Filterzustand sofort deterministisch resetten

"Sofort" bedeutet am samplegenauen MIDI-Offset, an dem die bestehende Voice das
Note-Off empfängt. Die Filter-Envelope darf Attack oder Decay nicht erst zu Ende
führen.

Release beginnt vom exakt aktuellen Filter-Envelope-Wert. Er darf nicht auf 1,
auf Sustain oder auf einen gecachten Note-Off-Pegel springen.

Die Voice bleibt durch den Amp-Envelope-Lifecycle bestimmt. Eine beendete
Filter-Envelope darf die Voice nicht vorzeitig clearen. Solange die Amp-
Envelope aktiv ist, wird der Filter mit dem definierten Filter-Envelope-
Endwert weiter betrieben.


===============================================================================
18. CLICK-FREIER FILTER-BYPASS
===============================================================================

filterEnabled ist ein automatisierbarer, speicherbarer Bool-Parameter. Er
schaltet die gesamte Filterstufe einschließlich Pre-Filter Drive und Filter-
Envelope-Modulation hörbar ein oder aus.

Bypass-Vertrag:

- On: Saw -> Drive -> Filter -> Amp-Envelope
- Off: Saw -> Amp-Envelope
- Umschalten erzeugt keinen Click, harten Pegelsprung oder Phasensprung
- intern linear oder equal-power über 10 ms überblenden; gewählte Form
  dokumentieren
- beide Pfade müssen während einer Überblendung kohärent verarbeitet werden
- mehrfaches schnelles Umschalten setzt vom aktuellen Mixwert fort, nicht von
  einem festen Endpunkt
- Bypass ändert weder Note-Lifecycle noch Amp-Envelope
- Bypass-Automation ist deterministisch und realtime-sicher
- Filterzustand darf beim Wiedereinschalten keinen alten explosiven Transient
  erzeugen

Bevorzugt wird, den Filterzustand auch bei vollständigem Bypass mitzuführen,
damit Wiedereinschalten sofort kohärent ist. Eine CPU-Optimierung, die den
vollständig trockenen Filterpfad überspringt, ist nur zulässig, wenn ein
getestetes Warm-up-/State-Konzept denselben click-freien Vertrag erfüllt.

Kein zusätzlicher Filter-Mix-Parameter. Der Bypass-Crossfade ist ein interner
Qualitätsmechanismus, kein zweiter Klangregler.


===============================================================================
19. PARAMETER, BEREICHE, DEFAULTS UND IDs
===============================================================================

Alle sechs vorhandenen Parameter bleiben unverändert. Folgende neue Parameter
werden mit exakt diesen stabilen IDs angehängt:

1. filterEnabled
   Typ: Bool
   Default: true
   Name: Filter

2. filterCutoff
   Typ: Float
   Bereich: 20.0 bis 20000.0 Hz
   Default: 1800.0 Hz
   GUI-/Host-Skalierung: logarithmisch/skewed
   Anzeige: Hz unter 1000, kHz ab 1000 zulässig

3. filterResonance
   Typ: Float
   Bereich: 0.0 bis 1.0
   Default: 0.18
   Anzeige: 0 bis 100 Prozent

4. filterDrive
   Typ: Float
   Bereich: 0.0 bis 18.0 dB
   Default: 3.0 dB
   Schrittweite: höchstens 0.1 dB

5. filterKeyTracking
   Typ: Float
   Bereich: 0.0 bis 1.0
   Default: 0.35
   Anzeige: 0 bis 100 Prozent

6. filterEnvAmount
   Typ: Float
   Bereich: -5.0 bis +5.0 Oktaven
   Default: +2.50 Oktaven
   bipolar, Mittelpunkt exakt 0

7. filterAttack
   Typ: Float
   Bereich: 0.001 bis 5.000 s
   Default: 0.002 s
   GUI-/Host-Skalierung: musikalisch sinnvoll logarithmisch/skewed

8. filterDecay
   Typ: Float
   Bereich: 0.001 bis 5.000 s
   Default: 0.280 s
   GUI-/Host-Skalierung: musikalisch sinnvoll logarithmisch/skewed

9. filterSustain
   Typ: Float
   Bereich: 0.0 bis 1.0
   Default: 0.0
   Anzeige: 0 bis 100 Prozent

10. filterRelease
    Typ: Float
    Bereich: 0.001 bis 10.000 s
    Default: 0.180 s
    GUI-/Host-Skalierung: musikalisch sinnvoll logarithmisch/skewed

Parameterregeln:

- IDs exakt wie angegeben, englisch, camelCase und dauerhaft stabil
- alle Parameter hostautomatisierbar, speicherbar und rückrufbar
- keine IDs für interne Crossfade-Zeit, Algorithmusparameter oder Voice Gain
- Parameterpointer außerhalb des Hot Path binden
- jeden Hostparameter pro Audioblock höchstens einmal atomar laden
- Snapshot muss trivial kopierbar und vollständig validiert bleiben
- nicht-finite Werte sicher ersetzen, technische Grenzen clampen
- alte gespeicherte Werte niemals durch neue Defaults überschreiben
- neue Parameter in alten States erhalten nur dann ihren Default, wenn sie im
  geladenen State tatsächlich fehlen
- "Deep Pluck" entspricht exakt den APVTS-Defaults
- ein neuer Plugin-Start und Reset auf Defaults ergeben denselben Klang wie
  das Factory-Preset "Deep Pluck"

Die Defaults sind Startwerte für die Implementierung. Falls die tatsächliche
Hörabnahme eine kleine Korrektur innerhalb der definierten Bereiche zwingend
nahelegt, ist sie nur erlaubt, wenn "Deep Pluck", APVTS-Defaults,
Dokumentation und Tests gemeinsam aktualisiert und die Änderung im Bericht
begründet wird. Parameterbereiche und IDs dürfen nicht informell geändert
werden.


===============================================================================
20. PARAMETER-SMOOTHING UND AUTOMATION
===============================================================================

Kontinuierliche Filterparameter dürfen bei Automation keine Zipper-Geräusche,
Clicks oder instabilen Koeffizientensprünge erzeugen.

Verbindliche Zielzeiten:

- filterCutoff: 20 ms, im logarithmischen Frequenz-/Oktavraum
- filterResonance: 20 ms
- filterDrive: 20 ms, vorzugsweise im dB-Raum vor Gain-Konvertierung
- filterKeyTracking: 20 ms
- filterEnvAmount: 20 ms
- filterEnabled: 10 ms interner Bypass-Crossfade

Filter-Envelope-Zeiten werden über den Live-Envelope-Vertrag aktualisiert und
nicht zusätzlich als einfacher Sample-Ramp geglättet, der die Stage-Semantik
verfälscht.

Smoothing-Verträge:

- prepare setzt Current und Target deterministisch auf den aktuellen Parameter
- Note-On darf keinen alten Ramp-Zustand einer vorherigen Note übernehmen
- aktive Stimmen reagieren auf Automation ohne Phasen- oder State-Reset
- neu gestartete Stimmen beginnen beim aktuellen globalen Parameterzustand
- schnelle Automation bleibt endlich und bounded
- Smoothing ist sample-rate-unabhängig in Sekunden definiert
- Blockgrößenänderungen verändern die Zeitkonstante nicht
- keine neue atomare Parameterabfrage pro Sample

Host-samplegenaue Parameterautomation wird nicht neu erfunden, wenn die
vorhandene Architektur Parameter pro Block liefert. MIDI-Events bleiben wie
bisher samplegenau. Diese Grenze ehrlich dokumentieren.


===============================================================================
21. VOICE-LIFECYCLE, RESET UND VOICE-STEALING
===============================================================================

Die bestehende 16-Voice-Architektur und das musikalische Voice-Stealing bleiben
erhalten.

Bei Note-On:

- Oszillator deterministisch starten wie bisher
- Filterzustand deterministisch resetten
- Amp- und Filter-Envelope unabhängig resetten und triggern
- Smoother auf fachlich korrekte aktuelle Werte initialisieren
- keine Zustände einer gestohlenen oder früheren Note übernehmen

Bei normalem Note-Off:

- Amp- und Filter-Envelope am exakten Eventoffset sofort in Release schicken
- beide vom jeweils aktuellen Wert weiterlaufen lassen
- Voice erst clearen, wenn der bestehende Amp-Lifecycle beendet ist

Bei Hard Stop oder allNotesOff ohne Tail:

- beide Envelopes, Filter, Bypass-Zustand, Smoother und relevante Tail-Zustände
  deterministisch in einen sicheren Zustand bringen
- bestehende click-arme Residual-Tail-Strategie erhalten
- keine hängenden Stimmen

Voice-Stealing-Priorität und deterministischer Tie-Break aus V0.2.0b bleiben
unverändert, sofern eine minimale Anpassung für neue beobachtbare Voice-Zustände
nicht zwingend notwendig ist. Filterresonanz darf die vorhandene Bewertung des
hörbaren Voice-Pegels nicht unkontrolliert verfälschen. Jede Änderung am
Stealing muss separat begründet und regressionsgetestet werden.


===============================================================================
22. HEADROOM, PEGEL UND DYNAMIK
===============================================================================

Der Filter darf den bestätigten dynamischen und konservativen Charakter nicht
zerstören.

Verträge:

- kein Limiter, Compressor oder Hard Clipper nach der Stimmsumme
- Velocity bleibt hörbar und ungefähr linear im Amp-Pfad
- vorhandener Output Gain und dessen 20-ms-Smoothing bleiben erhalten
- Default und alle Factory-Presets müssen sinnvolle Reserve besitzen
- der Default-16-Voice-Test bleibt bei maximaler Velocity <= 0.95 Peak
- keine NaN/Inf bei Maximalparametern oder Stress-Sequenzen
- keine unbegründete globale Pegelanhebung zum Lautheitsvergleich
- Resonanz und Drive dürfen musikalisch lauter wirken, aber nicht unkontrolliert
  eskalieren

Der bisherige Default-Peak 0.549 ist eine Referenz, kein exakt zu konservierender
Wert. Der neue Filter darf den Pegel verändern. Ein Ergebnis bis 0.95 ist nur
dann akzeptabel, wenn es musikalisch sinnvoll, stabil und nicht künstlich
maximiert ist.

Teste zusätzlich einen Worst-Case-Stabilitätsraum mit hoher Resonanz, hohem
Drive, mehreren Cutoffs, positiven und negativen Envelope Amounts sowie 16
Stimmen. Dieser Test muss endlich und bounded bleiben. Eine fachlich begründete
technische Obergrenze darf großzügiger als die Factory-Headroom-Grenze sein,
darf aber keine instabile Engine verdecken und ist zu dokumentieren.


===============================================================================
23. FACTORY-PRESETS UND DEFAULT SOUND
===============================================================================

Die vier bestehenden Factory-Presets bleiben namentlich erhalten:

- Deep Pluck
- Soft Pluck
- Tight Pluck
- Long Pluck

Jedes Preset wird um vollständige Werte für alle zehn neuen Filterparameter
erweitert. Es darf kein neuer Preset-Name nur zur Erhöhung der Anzahl entstehen.

Klangrollen:

1. Deep Pluck
   Exakt identisch zu allen APVTS-Defaults. Ausgewogener emotionaler
   Referenzsound: klarer Attack, warmer Filterkern, kurze musikalische Öffnung,
   moderate Resonanz und Drive, produktionsfähiger Headroom.

2. Soft Pluck
   Dunkler, runder und sanfter. Niedrigerer Basis-Cutoff, wenig Resonanz,
   zurückhaltender Drive, moderate positive Envelope und weicherer Verlauf.
   Nicht dumpf oder im Mittenbereich verschwunden.

3. Tight Pluck
   Kürzer, fokussierter und rhythmischer. Prägnante, kurze positive Filter-
   Bewegung, kontrollierter Bass, kein aggressiver Resonanz-Peak.

4. Long Pluck
   Länger, emotional und atmend. Etwas längere Filterbewegung und Release,
   musikalische Offenheit ohne scharfe Höhen oder verwaschenen Low-End-Bereich.

Preset-Verträge:

- alle Presets Filter On
- alle Werte explizit und vollständig, nicht implizit vom vorherigen Zustand
- Presetwechsel setzt Parameter über die bestehende host-/APVTS-taugliche
  Strategie
- Änderung eines beliebigen Filterparameters setzt Auswahl auf Custom
- Laden eines exakt passenden vollständigen Factory-Zustands erkennt das
  entsprechende Preset
- Presetwechsel während Audio darf keine Clicks oder NaNs erzeugen
- Presets bleiben trocken, ohne Effekte, Limiter oder versteckte Lautheitstricks
- alle behalten Dynamik und <= 0.95 Factory-Headroom im definierten Test
- jeder Klang entspricht dem Sound Manifest und ist als DeepPluck erkennbar

Finale Zahlen werden anhand der Hörabnahme abgestimmt und in Presetcode,
Dokumentation sowie Tests exakt festgehalten. Keine zufälligen oder nur visuell
verschiedenen Werte.


===============================================================================
24. GUI-ANFORDERUNGEN
===============================================================================

Die bestehende Entwicklungs-GUI minimal und ruhig erweitern. Kein Redesign.

Verbindliche neue Controls:

- Filter On/Off
- Cutoff
- Resonance
- Drive
- Key Track
- Env Amount mit klar erkennbarem bipolarem Mittelpunkt
- Filter Attack
- Filter Decay
- Filter Sustain
- Filter Release

Anforderungen:

- ParameterAttachments verwenden; keine DSP-Logik im Editor
- bestehende Amp-Controls und Presetauswahl vollständig erhalten
- klare visuelle Gruppierung "FILTER" und "FILTER ENV"
- verständliche Labels und Einheiten
- Cutoff musikalisch/logarithmisch bedienbar
- Env Amount zeigt negative, null und positive Werte eindeutig
- Filter-Bereich bei Bypass visuell ruhig als inaktiv erkennbar, ohne
  Parameterwerte zu löschen oder Attachments zu trennen
- Preset-Custom-Verhalten bleibt korrekt
- keine Animation, kein Analyzer, kein Meter und kein dekoratives Feature
- keine unnötige Vergrößerung oder visuelle Überlastung
- GUI muss bei üblichen Windows-Skalierungen vollständig sichtbar und bedienbar
  sein

Die sichtbare GUI muss manuell geprüft werden. Ein erfolgreicher Build ersetzt
keine Sichtprüfung.


===============================================================================
25. REALTIME-, C++20- UND CODEQUALITÄTSREGELN
===============================================================================

Im Audiothread und in jeder Sample-Schleife verboten:

- dynamische Speicherallokation oder Freigabe
- Locks, Mutexes, Waits oder blockierende Aufrufe
- Datei-, Netzwerk-, Logging- oder Konsolenzugriff
- ValueTree-Suche oder Stringarbeit
- Parameter-Lookup nach ID
- Exceptions als Kontrollfluss
- unbeschränkte Schleifen
- wiederholte Atomics pro Parameter und Sample

Verbindlich:

- C++20 und vorhandener Code-Stil
- RAII, klare Ownership und kleine Verantwortungsbereiche
- noexcept für geeignete DSP-Hot-Path-Funktionen
- feste, vorab erzeugte Voice-/DSP-Strukturen
- Parameter-Cache und Block-Snapshot erweitern, nicht umgehen
- nicht-finite Eingaben defensiv behandeln
- Denormals verhindern oder sicher flushen
- keine unnötigen Kopien großer Buffer
- keine UB, keine Out-of-bounds-Zugriffe, keine Race Conditions
- Debug und Release ohne neue relevante Warnungen
- Kommentare erklären Gründe, Gleichungen und nicht offensichtliche Verträge,
  nicht triviale Syntax

Teure Transzendentalfunktionen für Cutoff-Berechnung dürfen nur dort pro Sample
eingesetzt werden, wo die Modulationsqualität es tatsächlich erfordert und die
CPU-Plausibilitätsprüfung dies trägt. Bevorzuge stabile Rekurrenz, kleine
Updates oder andere klar dokumentierte Optimierungen ohne hörbare Treppen.


===============================================================================
26. AUTOMATISIERTE TESTS
===============================================================================

Bestehende sieben Suites und alle bestehenden Assertions bleiben aktiv. Tests
nicht abschwächen, löschen oder durch großzügige Toleranzen bedeutungslos
machen. Neue Tests in fachlich klaren Suites ergänzen; mindestens eine eigene
CTest-Suite "filter" und bei Bedarf eine eigene "filter_envelope" registrieren.

Mindestens folgende Verträge automatisiert prüfen:

A. Parameter und IDs

- alle sechs alten IDs existieren unverändert
- alle zehn neuen IDs existieren exakt einmal
- Typen, Bereiche, Defaults, Skews und Einheiten stimmen
- Cache ist vollständig gültig
- Snapshotwerte sind finite und korrekt geclamped
- APVTS-Defaults entsprechen exakt Deep Pluck

B. State-Kompatibilität

- synthetischer V0.1.0-/V0.2.0-State ohne Filterwerte lädt alte Werte korrekt
- fehlende Filterwerte erhalten die V0.3.0-Defaults
- vollständiger V0.3.0-State round-tript exakt innerhalb sinnvoller Toleranz
- unbekannte Properties/Children crashen nicht
- invalider Tree wird sicher abgelehnt
- Presetwahl und Custom-Erkennung bleiben korrekt

C. Filter-Grundfunktion

- reset liefert deterministische Stille
- Impuls-, DC-, Sinus- und Saw-Eingänge bleiben endlich
- tiefer Cutoff dämpft hohe Frequenzen deutlich stärker als tiefe
- hoher Cutoff erhält den musikalischen Passband-Pegel plausibel
- Sperrbereich zeigt nominalen 24-dB/Oktave-Charakter über einen geeigneten,
  nicht von Grenzfrequenz oder Noise Floor dominierten Messbereich
- mehrere Sample Rates mindestens 44.1, 48 und 96 kHz
- Blockgrößen mindestens 1, 32, 64, 127 und 512
- reset/prepare-Wiederholung ist deterministisch

D. Resonanz

- steigende Resonanz erhöht die Energie um den Cutoff messbar
- Resonanzbereich ist monoton oder fachlich nachvollziehbar abgebildet
- Maximum bleibt für Impuls, Stille, Saw und Sweeps endlich und bounded
- keine wachsende DC- oder NaN-Kaskade nach endlichem Input
- Resonanzautomation erzeugt keinen Filterreset

E. Drive

- 0 dB ist transparent oder innerhalb dokumentierter enger Toleranz
- steigender Drive erzeugt bei geeignetem Testsignal zusätzliche harmonische
  Energie
- Kennlinie bleibt für positive/negative Eingänge annähernd ungerade und
  erzeugt keine relevante DC-Komponente
- maximaler Drive plus maximale Resonanz bleibt finite und bounded

F. Cutoff-Modulation und Key Tracking

- 0 Prozent Key Tracking: gleiche Basis-Cutoff-Zielwerte für verschiedene Noten
- 100 Prozent: eine Oktave Notendifferenz ergibt eine Oktave Cutoff-Differenz
- positiver Env Amount erhöht den Cutoff bei Envelope-Wert > 0
- negativer Env Amount senkt ihn
- 0 Amount bleibt neutral
- alle Kombinationen clampen sicher an den DSP-Grenzen

G. Filter-Envelope

- Attack, Decay, Sustain, Release und Timing bei 44.1/48/96 kHz
- Ausgabe finite, bounded [0,1] und Stage-Übergänge stetig
- Note-Off während Attack startet sofort Release
- Note-Off während Decay startet sofort Release
- Note-Off während Sustain startet sofort Release
- Release beginnt vom aktuellen Wert
- kürzere Release-Zeit verkürzt einen laufenden Tail
- längere Release-Zeit verlängert einen laufenden Tail
- Live-Änderung von Attack, Decay und Sustain ohne Reset/Pegelsprung
- Filter- und Amp-Envelope laufen unabhängig
- Filter-Envelope-Ende cleart keine aktive Voice

H. Bypass und Smoothing

- Filter Off entspricht dem trockenen V0.2.0b-Signal innerhalb enger Toleranz,
  nachdem der Crossfade vollständig beendet ist
- On/Off-Übergang dauert die dokumentierte Zeit
- schnelles mehrfaches Umschalten bleibt stetig und endlich
- keine Ein-Sample-Diskontinuität oberhalb einer begründeten Schwelle
- Cutoff-, Resonance-, Drive-, Key-Track- und Amount-Sprünge rampen statt hart
  zu springen
- Smoothing-Zeit bleibt über Sample Rates und Blockgrößen konsistent

I. Per-Voice-Verhalten und MIDI-Samplegenauigkeit

- zwei Noten besitzen unabhängige Filterzustände und Envelopes
- Note-On/Off an nichtnull Sampleoffset wirkt dort auf beide Envelopes
- Samples vor dem Event bleiben unverändert
- 16 Stimmen bleiben exakt 16; keine DSP-Objektvermehrung
- Voice-Stealing, Hard Stop und Reuse hinterlassen keine alten Filterzustände
- wiederholte Akkorde erzeugen keine Hänger oder Zustandsakkumulation

J. Headroom und Stress

- Default-16-Voice-Peak <= 0.95 bei maximaler Velocity
- jedes Factory-Preset erfüllt denselben Headroom-Test
- Worst-Case-Matrix aus Cutoff, Resonanz, Drive, Key Tracking, positivem und
  negativem Amount bleibt finite und bounded
- lange Automation-Sweeps, schnelle MIDI-Folgen und Voice-Stealing bleiben
  stabil
- Stille ohne aktive Stimmen ist exakt oder innerhalb bestehender Toleranz still

Messmethoden müssen deterministisch sein. FFT-Fenster, Einschwingzeit,
Frequenzen, Toleranzen und Gründe dokumentieren. Keine fragile Assertion auf
einzelne phasenabhängige Samples, wenn Energie-/RMS-/Spektralmessung fachlich
besser ist.

Tests müssen in Debug und Release über CTest registriert und einzeln selektierbar
sein. Jede neue Suite muss im Build- und Abschlussbericht aufgeführt werden.


===============================================================================
27. LISTENING ACCEPTANCE TESTS
===============================================================================

Listening Tests sind Pflicht, weil die Filterqualität nicht allein aus grünen
Unit-Tests folgt. Mit guten Kopfhörern oder Monitoren bei kontrollierter
Lautstärke durchführen. Exakte Sample Rate, Buffer Size und Testumgebung im
Bericht festhalten.

Wenn nicht tatsächlich gehört wurde, jeden Punkt als

MANUAL VERIFICATION REQUIRED

ausweisen.

1. Default First Impression

- Plugin neu laden, Deep Pluck spielen
- einzelne Noten und einfache Deep-House-Akkorde in tiefer, mittlerer und hoher
  Lage
- Erwartung: sofort warm, rund, emotional und trocken überzeugend
- keine kratzigen Höhen, kein hohler Mittenbereich, kein matschiger Bass

2. Cutoff Sweep

- Resonanz moderat, Env Amount 0, gehaltene Note
- Cutoff langsam 20 Hz -> 20 kHz -> 20 Hz bewegen
- Erwartung: gleichmäßig, musikalisch und frei von Steps, Zippern und Clicks
- Übergang durch Mitten bleibt präsent und weich

3. Resonance Sweep

- mehrere feste Cutoffs in Bass, Mitten und Höhen
- Resonanz 0 -> 100 -> 0 Prozent
- Erwartung: zunehmende Farbe und Fokus ohne plötzliche Lautheitsexplosion,
  digitales Kreischen oder instabiles Verhalten

4. Drive

- bei moderatem Cutoff Drive 0 -> 18 dB vergleichen
- Erwartung: zunehmende Wärme, Dichte und harmonische Lebendigkeit
- Maximum darf charaktervoll, aber nicht kalt, harsch oder flach komprimiert
  wirken

5. Positive Filter Envelope

- Amount +2.5 Oktaven, Attack 2 ms, Decay 280 ms, Sustain 0, Release 180 ms
- Erwartung: klarer, organischer Pluck-Impuls mit weichem Ausklang
- keine harte Klickkante und kein künstliches Zischen

6. Negative Filter Envelope

- Basis-Cutoff ausreichend offen, Amount negativ
- Erwartung: hörbar schließende, musikalisch nutzbare Bewegung
- bipolarer Mittelpunkt muss neutral und kontrollierbar sein

7. Note-Off während Filter Attack

- Filter Attack ca. 1 s, Amp-Envelope lang genug hörbar
- Note kurz antippen
- Erwartung: Filterbewegung geht sofort vom aktuellen Wert in Release
- Attack wird nicht erst abgeschlossen

8. Note-Off während Filter Decay

- Filter Decay ca. 2 s, Filter Sustain 0
- Note nach ca. 0.5 s loslassen
- Erwartung: sofortiger Filter Release, kein restliches Decay

9. Live Filter Release kürzen

- Filter Release 5 s, Note auslösen und loslassen
- während des Tails auf 0.05 s drehen
- Erwartung: Filtertail wird sofort weich kürzer, ohne Sprung oder Neustart

10. Live Filter Release verlängern

- Filter Release 0.05 s, Note auslösen und loslassen
- während des Tails auf 5 s drehen, solange Envelope noch aktiv
- Erwartung: verbleibender Filtertail wird weich verlängert

11. Bypass A/B

- gehaltene Noten und Akkorde, Filter mehrfach On/Off
- Erwartung: kein Click; Off ist überzeugender sauberer V0.2.0b-Saw-Pfad, On
  liefert klaren musikalischen Mehrwert
- schnelle Umschaltungen dürfen nicht explodieren oder hängen

12. Key Tracking

- gleiche Velocity über mehrere Oktaven, Amount 0
- 0, 35 und 100 Prozent vergleichen
- Erwartung: 0 bleibt absolut, 100 folgt deutlich der Tastatur, 35 hält den
  Default über den Spielbereich ausgewogen
- hohe Noten nicht scharf, tiefe Noten nicht unbrauchbar dumpf

13. Polyphony und Voice-Stealing

- volle Akkorde, schnelle Wiederholungen, Pedal-/Release-ähnliche Überlagerung
- 17. Note erzwingen
- Erwartung: keine Clicks, Pegelsprünge, hängenden oder tonal falsch erbenden
  Stimmen

14. Factory-Presets

- alle vier Presets in mehreren Registern und Velocities spielen
- Erwartung: vier klar unterschiedliche, musikalisch brauchbare Sweet Spots
- jeder Preset klingt trocken nach DeepPluck und behält Headroom

15. Manifest-Abnahme

Explizit beurteilen und kurz protokollieren:

- warm, soft, rounded, musical, elegant, emotional, modern
- Höhen weich und seidig
- Mitten charaktertragend
- Bass kontrolliert
- Dynamik und Velocity lebendig
- keine sterile, aggressive, kalte, spröde oder überdigitalisierte Tendenz


===============================================================================
28. CUBASE-VALIDIERUNG
===============================================================================

Cubase-Validierung ist eine eigene Abnahmestufe. Vorhandene CubaseTest/-Daten
nicht ungefragt verändern oder committen. Systemweite Plugininstallation nicht
automatisieren. Falls der Benutzer das lokale VST3 manuell bereitstellt, exakt
diesen Build validieren.

Wenn Cubase nicht tatsächlich ausgeführt und beobachtet wurde, jeden Punkt als

MANUAL VERIFICATION REQUIRED

ausweisen.

Pflichtprüfungen:

1. Plugin Discovery und Identität

- Cubase erkennt V0.3.0 als dasselbe DeepPluck-Plugin
- kein doppelter Eintrag durch geänderte IDs
- Instrument lädt ohne Blacklist, Fehlerdialog oder Crash

2. Projektkompatibilität

- bestehendes V0.2.0b-Projekt mit DeepPluck öffnen
- alte sechs Parameterwerte und Presetklang bleiben erhalten
- neue Filterparameter erhalten dokumentierte Defaults
- speichern, schließen, erneut öffnen; vollständiger V0.3.0-State identisch

3. Automation

- Cutoff, Resonance, Drive, Key Track, Env Amount und Filter On automatisieren
- Filter-ADSR automatisieren, besonders Release während laufendem Tail
- Wiedergabe stoppen/starten und Loop-Grenzen prüfen
- keine Clicks, Sprünge, NaNs oder verlorenen Werte

4. MIDI und Timing

- Note-On/Off bei unterschiedlichen Positionen und kurzen Noten
- Note-Off während Filter Attack und Decay
- schnelle Repeats, Akkorde und Voice-Stealing
- kein hängender Ton und kein verspäteter Filter Release

5. Presets und Custom

- alle vier Factory-Presets wählen
- Filterparameter ändern -> Custom
- Projekt mit Factory-Preset und mit Custom speichern/rückrufen
- keine unvollständigen oder vom vorherigen Preset geerbten Filterwerte

6. GUI

- alle Controls sichtbar, lesbar und erreichbar
- DPI/Skalierung prüfen
- bipolare Env-Amount-Anzeige und Filter-Bypass eindeutig
- keine Überlappungen, abgeschnittenen Labels oder falschen Attachments

7. Audioqualität

- Monitoring bei normaler Lautstärke
- Cutoff-/Resonanz-Sweeps, Bypass, Live Release und Presetwechsel
- keine Clicks, Zipper-Geräusche, Pegelspitzen oder unerwartete Stille

8. Mehrfachinstanzen und Lifecycle

- mehrere Instanzen laden, spielen, speichern und entfernen
- Audio-Device-/Sample-Rate-Wechsel soweit praktikabel
- Projekt schließen und Cubase regulär beenden
- keine Crashes oder hängenden Prozesse

Im Abschlussbericht Cubase-Version, VST3-Pfad/Artefakt, Sample Rate, Buffer Size
und tatsächliches Ergebnis nennen. Keine pauschale Aussage "Cubase getestet"
ohne Einzelbefunde.


===============================================================================
29. PERFORMANCE- UND STABILITÄTSPRÜFUNG
===============================================================================

Audioqualität kommt zuerst, unnötige CPU-Arbeit ist dennoch kein Qualitätsmerkmal.

Mindestens prüfen und dokumentieren:

- 1, 4, 8 und 16 aktive Stimmen
- 44.1, 48 und 96 kHz
- sinnvolle Blockgrößen einschließlich 32, 64, 127 und 512
- Filter On gegen Filter Off
- Default sowie hohe Resonanz/hoher Drive
- schnelle Cutoff- und Envelope-Modulation

Verwende nach Möglichkeit eine reproduzierbare lokale Messung oder einen
deterministischen Render-Benchmark. Absolute CPU-Prozentwerte ohne stabile
Messumgebung nicht überinterpretieren. Dokumentiere Hardware, Buildtyp,
Sample Rate, Blockgröße, Stimmenzahl, Laufzeit und Messmethode.

Akzeptanz:

- keine Echtzeit-Aussetzer im normalen manuellen Test
- Laufzeit wächst nachvollziehbar mit Stimmenzahl
- Filter Off darf optimiert sein, muss aber den Bypass-Vertrag erfüllen
- keine ungebundene Arbeit oder Speicherzunahme
- keine extreme Debug-/Release-Diskrepanz, die auf UB hindeutet
- hörbare Qualität nicht für einen kosmetischen Benchmark opfern

Wenn kein belastbarer CPU-Benchmark möglich ist, dies als bekannte
Verifikationsgrenze dokumentieren. Realtime-Code-Review und Stress-Tests bleiben
trotzdem Pflicht.


===============================================================================
30. DOKUMENTATION
===============================================================================

Mindestens aktualisieren:

README.md

- Milestone/Version V0.3.0
- neue Filterfunktionen und fokussierter Scope
- Build-, Test- und lokale Artefakthinweise aktuell halten
- neue Parameter und Factory-Preset-Verhalten knapp beschreiben

ARCHITECTURE.md

- neuer per-Voice-Signalfluss
- Filterklasse und Ownership
- genauer 24-dB-Algorithmus und Gleichungen
- Cutoff-, Resonanz- und Stabilitätsabbildung
- logarithmische Envelope-/Key-Tracking-Modulation
- Drive-Kennlinie und Pegelstrategie
- Bypass-Crossfade und State-Verhalten
- zweite Live-Envelope und Note-Off-/Live-Update-Verträge
- Smoothing-Zeiten und Block-Snapshot-Grenze
- Reset, Voice-Stealing und Headroom

Sound Manifest

- normativen Inhalt nicht beiläufig umschreiben
- nur ändern, wenn eine echte notwendige Korrektur vorliegt und diese klar
  begründet ist; normalerweise bleibt das Manifest unverändert

Master-Prompt

- dieses Dokument unverändert als
  Docs/DeepPluck_V0.3.0_Filter_Engine_MasterPrompt_Rev1.txt
  in das Repository übernehmen, sofern es dort noch nicht identisch vorhanden
  ist

Finaler Bericht

- als Docs/DeepPluck_V0.3.0_Filter_Engine_Implementation_Report.md
- Struktur gemäß Abschnitt 35
- ausgeführte und manuelle Prüfungen strikt trennen

Dokumentation darf keine geplanten Werte als gemessene Ergebnisse darstellen.


===============================================================================
31. BUILD, ARTEFAKTE UND VERIFIKATIONSABLAUF
===============================================================================

Vorhandene CMake-/JUCE-Architektur verwenden. Keine neue Toolchain und keine
Systeminstallation.

Verbindliche Reihenfolge:

1. Bestandsaufnahme, Dokumentlektüre und Git-Schutzprüfung
2. vorhandenen Debug-/Release-Teststand soweit sicher als Baseline ausführen
3. kleinsten Architekturplan für Filter, zweite Envelope und Parameter erstellen
4. Filteralgorithmus isoliert mit Tests implementieren
5. Drive, Cutoff-Modulation, Resonanz und Stabilität testen
6. Filter-Envelope und Eventverträge mit Tests integrieren
7. per-Voice-Signalfluss, Bypass und Smoothing integrieren
8. State, Presets und GUI erweitern
9. Headroom-, Matrix-, Stress- und Regressionstests vervollständigen
10. frische/validierte CMake-Konfiguration prüfen
11. vollständigen Debug Build und Debug CTest ausführen
12. vollständigen Release Build und Release CTest ausführen
13. Warnungen, Realtime-Hot-Path und Artefakte prüfen
14. VST3-Bundle-Struktur und Standalone-Artefakt prüfen
15. Standalone-Smoke-Test soweit sicher automatisierbar ausführen
16. Listening Acceptance und Cubase-Validierung tatsächlich ausführen oder
    exakt als manuell erforderlich ausweisen
17. Dokumentation, Diff, Git-Status und Definition of Done prüfen
18. erst danach fokussierte Commits erstellen

Lokale Artefaktkonvention erhalten:

- Artifacts/Debug/DeepPluck.vst3 als vollständiges Bundle
- Artifacts/Debug/DeepPluck.exe
- Artifacts/Release/DeepPluck.vst3 als vollständiges Bundle
- Artifacts/Release/DeepPluck.exe

Keine Artefakte in System-VST3-Verzeichnisse kopieren. Keine generierten
Artefakte committen.

Nach jeder relevanten DSP-Korrektur betroffene Tests erneut ausführen. Vor
Abschluss immer vollständige Debug- und Release-Suites wiederholen.


===============================================================================
32. GIT-WORKFLOW
===============================================================================

Vor Arbeitsbeginn:

- git status --short
- git log --oneline in sinnvollem Umfang
- git diff und git diff --cached
- vorhandene untracked Dateien erfassen

Während der Arbeit:

- nur Scope-Dateien ändern
- Benutzeränderungen und bekannte untracked historische Dateien unangetastet
  lassen
- keine Rebases, Resets, automatischen Stashes oder destruktiven Clean-Befehle
- keine fremden Änderungen in eigene Commits aufnehmen
- keine Buildverzeichnisse oder Binärartefakte committen
- keine Pushes

Empfohlene fokussierte Commit-Struktur nach vollständiger Verifikation:

1. Implementierungscommit
   Beispiel: feat: add per-voice 24 dB filter engine

2. Abschlussbericht-Commit
   Beispiel: docs: add V0.3.0 filter engine report

Wenn der reale kleine Diff einen einzigen sauberen Commit fachlich besser
rechtfertigt, ist dies zulässig und im Bericht zu erklären. Keine künstliche
Commit-Zerlegung.

Vor jedem Commit Diff und Staging-Liste prüfen. Nach dem letzten Commit finalen
Status nennen, einschließlich absichtlich untracked gebliebener Dateien.


===============================================================================
33. REGRESSION POLICY
===============================================================================

Keines der folgenden V0.2.0b-Merkmale darf regressieren:

- Plugin-Identität und Cubase-Erkennung
- VST3- und Standalone-Build
- 16-Voice-Limit
- samplegenaue MIDI-Verarbeitung
- PolyBLEP-Saw und bestätigte Aliasreduktion
- Amp-Envelope-Kurven und Timing
- sofortiger Amp Release bei Note-Off aus Attack/Decay/Sustain
- live wirksame Amp-Envelope-Parameter
- Kürzen und Verlängern laufender Amp-Releases
- musikalisches Voice-Stealing
- lineare Velocity-Reaktion
- Tune-Smoothing ohne Phasenreset
- Output-Gain-Smoothing nach der Stimmsumme
- Default-Headroom <= 0.95
- State-Migration älterer Versionen
- vier Factory-Presets und Custom-Erkennung
- deterministische Stille ohne aktive Stimmen
- vollständige vorhandene Tests
- lokale Artefaktkonvention

Wenn ein bestehender Test wegen einer absichtlichen hörbaren Filterwirkung nicht
mehr exakt denselben Audiowert erwarten kann, Test nicht löschen. Seine
eigentliche Regression-Aussage auf dem trockenen Bypass-Pfad oder auf einer
geeigneten neuen Erwartung erhalten und die Anpassung begründen.

Ein Filter-On-Default erlaubt keine Behauptung, der alte Default müsse bitgenau
klingen. Filter Off muss jedoch den alten trockenen Signalpfad nach beendetem
Crossfade innerhalb enger numerischer Toleranz bewahren.


===============================================================================
34. STRENGTHENED DEFINITION OF DONE
===============================================================================

V0.3.0 ist nur fertig, wenn alle zutreffenden Punkte erfüllt sind:

Repository und Scope

[ ] realen Ausgangsstand und Benutzeränderungen geprüft
[ ] normative Dokumente vollständig gelesen
[ ] ausschließlich V0.3.0-Scope implementiert
[ ] Oszillator 2, Noise, Unison und Effekte nicht implementiert
[ ] alte untracked Dateien und CubaseTest/ unangetastet, soweit vorgefunden

Kompatibilität

[ ] Produkt-, Bundle-, Hersteller- und Plugin-IDs unverändert
[ ] bestehende sechs Parameter-IDs unverändert
[ ] zehn neue IDs exakt wie spezifiziert angehängt
[ ] alte States laden korrekt und erhalten neue Defaults nur für fehlende Werte
[ ] V0.3.0-State round-tript vollständig
[ ] Cubase erkennt das Ergebnis als dasselbe Plugin oder Prüfung ist manuell
    ausgewiesen

DSP

[ ] genau ein per-Voice 24-dB-Low-Pass implementiert
[ ] Cutoff, Resonance, Drive und Key Tracking vollständig funktionsfähig
[ ] bipolarer Filter-Envelope Amount korrekt
[ ] Filter bei hoher Resonanz und maximalem Drive stabil
[ ] keine NaN, Inf, Denormals oder ungebundenen Zustände
[ ] kein Limiter/Clipper kaschiert Stabilitätsprobleme
[ ] Filter Off erhält den trockenen V0.2.0b-Pfad

Filter-Envelope

[ ] eigene Envelope pro Stimme
[ ] gleiche Kurven- und Live-Update-Verträge wie Amp-Envelope
[ ] Note-Off während Attack führt sofort in Release
[ ] Note-Off während Decay führt sofort in Release
[ ] Note-Off während Sustain führt sofort in Release
[ ] laufender Release reagiert auf kürzere Zeit
[ ] laufender Release reagiert auf längere Zeit
[ ] Amp- und Filter-Envelope bleiben unabhängig

Automation und Bypass

[ ] kontinuierliche Parameter fachlich geglättet
[ ] Cutoff-Smoothing im logarithmischen Raum
[ ] Filter-On/Off über 10 ms click-frei überblendet
[ ] schnelles mehrfaches Umschalten setzt stetig fort
[ ] Automation resetet weder Filter noch Envelopes

Musikalität

[ ] Default ist trocken sofort als emotionaler Deep-House-Pluck brauchbar
[ ] Höhen weich, Mitten präsent, Bass kontrolliert
[ ] Resonanz und Drive besitzen breite musikalische Sweet Spots
[ ] Key Tracking hält Klang über die Tastatur sinnvoll ausgewogen
[ ] positive und negative Envelope-Modulation sind hörbar nützlich
[ ] alle vier Factory-Presets sind vollständig und unterscheidbar
[ ] Sound Manifest wurde explizit beurteilt

Headroom und Realtime

[ ] Default-16-Voice-Peak <= 0.95
[ ] alle Factory-Presets <= 0.95 im definierten Test
[ ] Worst-Case-Stresstest finite und bounded
[ ] keine Allokationen, Locks oder String-/Tree-Arbeit im Audiothread
[ ] CPU-/Realtime-Plausibilität geprüft und dokumentiert

Build und Tests

[ ] Debug Build erfolgreich
[ ] vollständiger Debug CTest erfolgreich
[ ] Release Build erfolgreich
[ ] vollständiger Release CTest erfolgreich
[ ] alle sieben bestehenden Suites weiterhin erfolgreich
[ ] neue Filter-Suite(s) registriert und erfolgreich
[ ] Standalone-Smoke-Test erfolgreich oder manuell ausgewiesen
[ ] lokale Debug-/Release-Artefakte vollständig
[ ] keine neuen relevanten Compilerwarnungen

Manuelle Abnahme

[ ] Listening Acceptance tatsächlich durchgeführt oder jeder offene Punkt exakt
    mit MANUAL VERIFICATION REQUIRED markiert
[ ] GUI sichtbar geprüft oder exakt manuell ausgewiesen
[ ] Cubase vollständig validiert oder jeder offene Punkt exakt manuell
    ausgewiesen
[ ] keine nicht ausgeführte Prüfung als erfolgreich behauptet

Dokumentation und Git

[ ] README.md aktuell
[ ] ARCHITECTURE.md mit Filtergleichungen und Verträgen aktuell
[ ] Master-Prompt im Docs-Verzeichnis vorhanden
[ ] vollständiger Implementierungsbericht erstellt
[ ] finalen Diff und Git-Status geprüft
[ ] fokussierte Commits ohne Benutzerdateien erstellt
[ ] keine generierten Artefakte committed
[ ] kein Push ausgeführt

Ein grüner Build allein erfüllt diese Definition of Done nicht. Automatisierte
Vollständigkeit und musikalische Abnahme sind getrennt auszuweisen.


===============================================================================
35. FINAL IMPLEMENTATION REPORT
===============================================================================

Erstelle:

Docs/DeepPluck_V0.3.0_Filter_Engine_Implementation_Report.md

Pflichtstruktur:

1. Overall Result
   - Status: complete, partial oder blocked
   - knappe belastbare Zusammenfassung

2. Starting Point
   - realer Commit/Branch/Status
   - vorhandene Benutzeränderungen und Schutzmaßnahmen
   - ausgeführte Baseline-Tests

3. Scope
   - umgesetzt
   - bewusst nicht umgesetzt

4. Files
   - neu, geändert und absichtlich unangetastet

5. Architecture and Signal Flow
   - per-Voice-Einbindung und Ownership
   - Parameter-Snapshot und Lifecycle

6. Filter Algorithm
   - Gleichungen/Topologie
   - 24-dB-Nachweis
   - Cutoff- und Resonanzabbildung
   - Stabilitätsstrategie

7. Drive, Key Tracking and Modulation
   - Kennlinie, Pegelstrategie und logarithmische Cutoff-Bildung

8. Filter Envelope
   - Wiederverwendung/Generalisierung
   - Live-Update und sofortiger Note-Off
   - Unabhängigkeit von der Amp-Envelope

9. Bypass and Smoothing
   - Crossfade-Form und Zeit
   - alle Smoothing-Zeiten

10. Parameters, State and Compatibility
    - IDs, Bereiche, Defaults
    - alte State-Migration und V0.3.0-Roundtrip
    - unveränderte Plugin-Identität

11. Presets and GUI
    - finale Presetwerte und musikalische Rollen
    - Custom-Verhalten
    - GUI-Status und Sichtprüfung

12. Realtime Review
    - Hot-Path-Audit, Allokationen, Locks, Atomics und Denormals

13. Builds and Artifacts
    - genaue Debug-/Release-Befehle und Ergebnisse
    - vollständige lokale Artefaktpfade

14. Automated Tests
    - jede Suite einzeln
    - Pass/Fail, Konfigurationen und wichtige Messwerte
    - 24-dB-, Resonanz-, Bypass- und Envelope-Nachweise

15. Listening Acceptance
    - jeden Test einzeln mit tatsächlichem Befund
    - offene Tests exakt MANUAL VERIFICATION REQUIRED

16. Cubase Validation
    - Version, Sample Rate, Buffer, Artefakt und Einzelbefunde
    - offene Tests exakt MANUAL VERIFICATION REQUIRED

17. Headroom and Performance
    - Default- und Preset-Peaks
    - Worst-Case-Bounds
    - CPU-Methode und Ergebnisse oder ehrliche Messgrenze

18. Sound Manifest Review
    - warm/soft/rounded/musical/emotional
    - Höhen, Mitten, Bass, Dynamik und Dry-Sound
    - Antwort auf die Mandatory Development Question

19. Regression Review
    - alle Verträge aus Abschnitt 33

20. Known Limitations and Technical Debt
    - konkret, priorisiert und ohne versteckte Scope-Erweiterung

21. Git
    - finale Commits, finaler Status, nicht enthaltene Benutzerdateien, kein Push

22. Design Review
    - Did the implementation improve musical quality?
    - Did complexity increase, and was it justified?
    - Does it follow the Sound Manifest?
    - Would a musician immediately hear or feel the improvement?
    - Keep, refactor, or revert?

23. Next Milestone Recommendation
    - genau eine fokussierte Empfehlung
    - keine ungefragte Implementierung des nächsten Milestones

Der Bericht trennt Fakten, Messwerte, subjektive Hörbefunde und offene manuelle
Prüfungen. Keine erfundenen Erfolge und keine pauschalen Sammelaussagen.


===============================================================================
36. FEHLERBEHANDLUNG UND ZULÄSSIGE ABWEICHUNGEN
===============================================================================

Bei Build-, Test- oder DSP-Fehlern:

1. vollständige relevante Fehlermeldung lesen
2. Ursache bestimmen
3. kleinste fachlich korrekte Änderung vornehmen
4. betroffenen Test erneut ausführen
5. vollständige relevante Debug-/Release-Prüfung wiederholen

Keine Tests deaktivieren, Assertions entfernen, Grenzwerte willkürlich erhöhen
oder Fehler durch Output-Clamping verstecken.

Zulässige Abweichungen betreffen nur technische Details, wenn:

- die lokale JUCE-9-API oder reale Architektur die beschriebene Form nicht
  unterstützt
- die Alternative denselben hörbaren und technischen Vertrag erfüllt
- Scope und Kompatibilität unverändert bleiben
- eigene automatisierte Tests die Gleichwertigkeit belegen
- die Abweichung im Bericht mit Grund und Auswirkung dokumentiert ist

Nicht zulässige Abweichungen:

- anderer Filtertyp oder mehrere Filtermodelle
- weniger als nominal 24 dB/Oktave
- globaler statt per-Voice-Filter
- unipolarer statt bipolarer Envelope Amount
- statische statt live reagierende Filter-Envelope
- verzögerter Note-Off aus Attack oder Decay
- harter Bypass
- neue Plugin-ID oder gebrochene alte States
- Out-of-Scope-Features


===============================================================================
37. DEEPPLUCK STANDARD UND GOLDEN RULES
===============================================================================

1. DeepPluck ist ein Musikinstrument, keine Technologie-Demo.
2. Sound before features.
3. Musicality before spectacle.
4. Quality before quantity.
5. Realtime safety is absolute.
6. The Sound Manifest is mandatory.
7. One excellent filter is better than ten average models.
8. Every control must have an audible musical purpose.
9. Note-Off is immediate for both Amp and Filter Envelopes.
10. Live controls must feel alive, never frozen.
11. High resonance must remain stable and musically controlled.
12. Bypass must be a trustworthy, click-free A/B comparison.
13. Dry sound quality always comes before effects.
14. Defaults and presets must retain dynamics and headroom.
15. Plugin identity and existing states are permanent contracts.
16. New modules integrate cleanly without duplicated DSP logic.
17. Musical errors are real errors even when unit tests are green.
18. DeepPluck is not designed to make every sound. It is designed to make the
    right sound exceptionally well.


===============================================================================
38. ABSCHLIESSENDE ARBEITSANWEISUNG
===============================================================================

Implementiere DeepPluck V0.3.0 - Filter Engine vollständig, fokussiert und
musikalisch. Beginne mit dem realen Repository-Stand und schütze vorhandene
Benutzerarbeit. Bewahre alle Plugin-IDs, bestehenden Parameterverträge und die
State-Kompatibilität.

Baue genau eine hochwertige per-Voice-Filterstufe:

PolyBLEP Saw
  -> click-frei bypassbarer Pre-Filter Drive
  -> stabiler resonanter 24-dB Low-Pass
  -> Amp Envelope
  -> Velocity und Voice Gain
  -> globale Summe und Output Gain

Moduliere den Cutoff musikalisch im logarithmischen Raum durch Basis-Cutoff,
Key Tracking und eine bipolare dedizierte Filter-Envelope. Die Filter-Envelope
muss dieselbe Live-Reaktivität und denselben sofortigen Note-Off-Vertrag wie die
bestätigte Amp-Envelope besitzen.

Betrachte den Milestone als fehlgeschlagen, wenn einer dieser Fälle vorliegt:

1. Filter ist global statt per Stimme.
2. Filter erreicht den 24-dB-Vertrag nicht.
3. Hohe Resonanz oder Drive erzeugen NaN, Inf oder unbounded Wachstum.
4. Filter-Envelope ignoriert Note-Off während Attack oder Decay.
5. Laufende Filter-Releases ignorieren geänderte Release-Zeiten.
6. Bypass clickt oder übernimmt beim Einschalten einen gefährlichen Altzustand.
7. Automation erzeugt hörbare Steps oder setzt Filter/Envelope zurück.
8. Filter Off bewahrt den trockenen V0.2.0b-Pfad nicht.
9. Alte States, Presets oder Plugin-Identität werden gebrochen.
10. Headroom wird durch Limiting statt durch korrektes Gain-Staging erreicht.
11. Oscillator 2, Noise, Unison oder Effekte werden in den Scope gezogen.
12. Manuelle Prüfungen werden erfunden oder als erfolgreich behauptet.

Arbeite bis alle automatisierbaren Punkte der Definition of Done erfüllt sind.
Führe Listening-, GUI- und Cubase-Prüfungen tatsächlich aus oder kennzeichne
jeden offenen Punkt exakt mit MANUAL VERIFICATION REQUIRED. Erstelle lokale
Debug-/Release-Artefakte, vollständige Tests, aktualisierte Dokumentation,
fokussierte Git-Commits und den finalen Implementierungsbericht.

Die abschließende Produktfrage lautet:

Does this make DeepPluck a better instrument for emotional Deep House plucks?

Wenn die ehrliche Antwort nicht klar "yes" ist, ist V0.3.0 noch nicht fertig.

===============================================================================
ENDE DER MASTER-SPEZIFIKATION
===============================================================================
