Projekte / FF00 Studio / Technischer Anhang

Meilenstein 2 / Worker-Bridge in Pruefung

Warum FF00 Studio so gebaut wird

FF00 Studio soll ein lokaler Musikpartner werden, der Kontext hoeren, Entscheidungen erklaeren und begrenzte Arbeiten wirklich ausfuehren kann — ohne ein Sprachmodell auf den Echtzeit-Audio-Thread zu lassen oder einen Vorschlag als ausgefuehrte Aktion auszugeben.

Dies ist der Architekturnachweis des Projekts, nicht die Beschreibung eines fertigen Produkts. Die Vertraege werden vor den gefaehrlichsten Teilen geschrieben, damit die spaetere Implementierung an mehr als guten Absichten gemessen werden kann. Eine Aussage ist hier bestaetigt, geplant, nicht unterstuetzt oder unbekannt. Geplantes wird nicht als funktional dargestellt.

Aktuelles Ziel: Windows, Waveform 14.0.49 Free + Welcome, Surge XT 1.3.4 und ein austauschbares lokales Ollama-Modell. Linux-Portierbarkeit formt die Schnittstellen ab dem ersten Commit; Linux-Audio-Support wird noch nicht behauptet.

1. Produktgrenze

Das Produkt hat zwei sichtbare Arbeitsflaechen. FF00 Master enthaelt das Projektgespraech, Referenzen, Analysen, erzeugte Assets und gepruefte Aktionen. FF00 Rack wird auf einer Waveform-Spur eingesetzt und definiert den Ort, an dem FF00 Audio bearbeiten, Kind-Plugins hosten und kontrollierte Parameter bereitstellen darf.

Es ist absichtlich kein allgemeiner Desktop-Chatbot. UI-Automatisierung und erfundene Waveform-Befehle sind fuer Audioarbeit kein verlaessliches Fundament. Ein Modell darf ueber einen gewuenschten Klang nachdenken; deterministische Executors muessen verfuegbare Parameter entdecken, Aenderungen validieren, ausfuehren und genau berichten.

Die ersten Nicht-Ziele sind genauso wichtig: kein Schreiben von .tracktionedit, keine Cloud-Abhaengigkeit, kein Feedback-Graph, kein Sicherheitsversprechen fuer beliebige VST3-Plugins und keine Behauptung ueber Waveform-Scripting, bevor die Aktion auf der installierten Version lief.

2. Prozesstopologie und Besitz

Waveform-14-Prozess
  └─ FF00 Rack VST3
       ├─ feste Echtzeit-Bridge ─ Shared Memory ─ FF00 Worker
       └─ Steuerung/Zustand ───── Named Pipe ─────┘

FF00 Master ─ lokales Broker-/Steuerprotokoll ─ registrierte Racks
     └─ deterministische Werkzeuge ─ validierte Vorschlaege ─ Ollama/Loopback

Das Rack ist die kleinste host-interne Komponente. Pro Rack existiert ein Worker mit dem Kind-Plugin-Graph; er kann beendet werden, ohne Kind-DSP in Waveform zu laden. Master bleibt ausserhalb des Echtzeitpfads. Ollama ist ein austauschbarer Denk-Provider und besitzt keinen Produktzustand.

Prozessisolation begrenzt den Schaden, macht das Rack aber nicht unfehlbar. Ein Fehler im Rack, in seiner VST3-Grenze, bei Shared-Memory-Pruefungen oder im host-seitigen State-Decoder kann Waveform weiter destabilisieren. Native Kind-Plugin-Editoren muessen deshalb Worker-eigene Fenster bleiben.

3. Echtzeit-Audiovertrag

Der Audio-Callback darf nie auf Worker, Pipe, Modell, Datei, Speicherzuteilung oder UI warten. Prozessuebergreifendes DSP verwendet darum eine Pipeline statt eines synchronen Remote-Aufrufs. Eingangsblock n wird in einen festen Slot geschrieben, waehrend ein Output einer frueheren Sequenz gelesen wird. Der konfigurierte Sicherheitshorizont betraegt einen oder mehrere Perioden; seine Gesamtlatency wird Waveform in Samples fuer Plugin Delay Compensation gemeldet.

„Ein Block“ ist unter Windows kein ehrliches Vertragsversprechen. Scheduler- Jitter, Prozessaufweckzeit, Treiber und konkurrierende Arbeit koennen es brechen, auch bei kleiner mittlerer DSP-Zeit. Der Vertrag lautet stattdessen: deterministische konfigurierte Pipeline-Latency, kein Warten im Callback, Sequenz- und Generationspruefung sowie definierter Output bei Deadline-Verlust.

Die Alpha muss die gemeldete Latency mit Impulstests von 64 bis 1024 Samples pruefen. Offline-Rendering gilt nicht automatisch als Echtzeit-aequivalent. Bis ein synchroner Watchdog-Modus experimentell sicher ist, wird fuer nicht bestaetigte Modi Echtzeit-/1×-Rendering verlangt statt still fehlerhaftes Audio.

4. Waveform-Besitz und Projektkontext

Waveform besitzt Spuren, Clips, Automation, native Plugins, Speichern und Rendering. FF00 Studio behandelt .tracktionedit in dieser Architektur dauerhaft nur als Read-only-Kontext. Es erstellt einen stabilen Snapshot, parst eine versionsbezogene Whitelist und behandelt unbekanntes XML sowie Plugin-State als opaque. Die Projektdatei wird nie rekonstruiert oder serialisiert.

Damit verschwindet das groesste Korruptionsrisiko eines fremden Serializers, der unbekannte Felder verliert. Ein Live-File kann waehrend des Speicherns ersetzt werden; geparst wird deshalb nur eine stabile Kopie mit Metadatenpruefung vor und nach dem Kopieren sowie begrenzten Wiederholungen.

Waveform-Scripts sind faehigkeitsgesteuert. Spuren, MIDI-Clips, Noten, Plugins, Presets, Parameter, Render/Export, Step Clips, Clip Launcher und Micro Drum Sampler bleiben unbekannt, bis Waveform 14.0.49 sie ueber eigene Discovery und Wegwerfprojekte bestaetigt. Ein vorbereitetes Script ist keine erfolgreiche Aktion: Vorbereitung, Benutzerausfuehrung und verifiziertes Resultat sind getrennt.

5. VST3-Hosting und der Surge-Proof

JUCE liefert nuetzliche Hosting-Abstraktionen, garantiert aber keine ehrlichen Metadaten, stabiles Verhalten, deterministischen State oder sichere Editoren fuer jedes Plugin. Discovery laeuft in einem opferbaren Scanner mit Timeout und Quarantaene. Der Worker besitzt Instanz, Audio-/MIDI-Busse, UI, Latency, Tail, Bypass, State und Teardown.

Die Alpha begrenzt Kompatibilitaet vor der Behauptung „beliebige Plugins“. Plugins koennen instabile Parameternamen, modusabhaengige Controls, mehrere Busse, Sidechains, Offline-Sonderverhalten, File-Dialoge, versteckten State, Haenger oder Crashes haben. Jedes getestete Binary erhaelt Fingerprint und Kompatibilitaetsnachweis.

Surge XT 1.3.4 ist der erste tiefe Adapter. Save/Reload verlangt keine willkuerlich reserialisierten, byte-identischen Daten. Korrekt ist:

• unangetasteten opaque State exakt erhalten, wenn keine Umwandlung noetig ist;
• Parameter- und Preset-Aequivalenz nach Restore pruefen;
• ein kontrolliertes MIDI-/Audio-Fixture innerhalb definierter Toleranz rendern;
• Plugin-Version und Fingerprint mit jedem Resultat aufzeichnen.

6. Begrenzter Rack-Graph

Langfristig kennt der Graph Splits, Merges, Umordnung, MIDI, Aux-Busse, Sidechains, Bypass und Node-Latency. Die Alpha erlaubt absichtlich nur Mono-/Stereo-Main-I/O, einen optionalen Mono-/Stereo-Sidechain pro Node, feste Layouts und kein Feedback.

Graphs werden ausserhalb des Audio-Threads als immutable Plaene gebaut und prepared. Der Executor berechnet Pfad-Latency, kompensiert kuerzere Zweige, definiert deterministische MIDI-Reihenfolge und publiziert eine Revision. Der aktive Plan wechselt an einer Blockgrenze; Topologieaenderungen crossfaden wo sicher. Alte Plaene werden erst entfernt, wenn kein Echtzeit-Leser sie referenziert.

Ein atomarer Pointer-Swap reicht nicht, falls Plugin-Preparation, State- Migration, Busverhandlung oder Destruction im Callback passieren. Diese Arbeit bleibt draussen. Dynamische Layouts und Feedback warten, bis die Bridge bewiesen ist.

7. Lokales Protokoll und Rack-Identitaet

Echtzeit-Audio und begrenzte MIDI-Events gehoeren in feste Shared-Memory-Slots. Graph-State, Parameter, Capability Discovery, Jobs, Fehler und Snapshots laufen ueber Control-IPC: zuerst Windows Named Pipes, spaeter Unix Sockets.

Jede Verbindung traegt Rack-UUID, PID, Prozessstart-Nonce, Connection- Generation und Protokollversion. Pipes sind auf den aktuellen Benutzer beschraenkt. Major-Versionen lehnen Inkompatibilitaet ab; Minor-Versionen handeln Capabilities aus. Operations-IDs, erwartete Graph-Revisionen, Deadlines und Cancellation verhindern, dass alte Antworten in neue Sessions gelangen.

Master entdeckt mehrere Racks ueber einen Per-user-Broker. Discovery ist keine Autoritaet. „Accepted“ heisst validiert und eingereiht, nicht abgeschlossen. Abschluss wird nur aus deterministischem Executor-State gemeldet.

8. Discuss, Preview und Apply

Bei Parametern bedeutet „permanent“: im committed Rack-State. Beim Graph: die committed Graph-Revision. Bei Audio/MIDI: ein provenance-tragendes immutable Asset, das aus Preview promoted wurde. Bei Waveform: der Benutzer hat eine gepruefte Aktion ausgefuehrt und FF00 das sichtbare Resultat danach verifiziert. Das blosse Schreiben eines Scripts ist nie Erfolg.

Preview darf nicht in Waveform-Automation, committed Rack-State oder dauerhafte Assets auslaufen. Apply nutzt Revision-Preconditions, damit ein altes Modell- Resultat keinen inzwischen veraenderten Zustand ueberschreibt.

9. Session-Sidecar und Provenance

<edit-name>.ff00/
  session.toml
  SESSION.md
  history/events.jsonl
  generated/audio/
  generated/midi/
  snapshots/
  cache/

Der Sidecar hat einen Writer. session.toml wird atomar ersetzt; events.jsonl ist bis zum letzten vollstaendigen Record wiederherstellbar; Snapshots und Assets besitzen immutable IDs statt Dateinamen-Identitaet. Locks enthalten PID und Prozessstart-Nonce, damit recycelte PIDs keinen Besitz erben.

Referenzen bleiben ueber Pfad, SHA-256, Groesse, Zeitstempel und optionalen Media-Fingerprint verlinkt. Verschobene oder geaenderte Medien werden nie still ersetzt. Portable Kopien brauchen Zustimmung. Cache ist disposable und hash-basiert; Originalaudio wird nie umgeschrieben.

10. Ollama und deterministische Autoritaet

Das erste Entwicklungsmodell ist qwen3:14b ueber einen konfigurierbaren Loopback-Ollama-Provider. Das Modell bleibt austauschbar. Strict-local weist Nicht-Loopback-Endpunkte ab.

Das Modell darf Sprache interpretieren, Optionen vergleichen, Rezepte entwerfen und Trade-offs erklaeren. Rust/C++ besitzen Capability Discovery, Schema- Validierung, Parameteridentitaet, Ranges, Revisionen, Ausfuehrung, Cancellation und wahrheitsgetreue Resultate. Schemafehler bekommen hoechstens einen begrenzten Reparaturversuch; danach folgt ein sichtbarer Fehler, kein erfundener Tool Call.

Lange Arbeit laeuft als asynchroner Job. Cancellation ist explizit. Eine neue Modellantwort kann keine laufende Entscheidung ersetzen. Kontext-Summaries sind provenance-tragende Inputs, kein Nachweis des aktuellen Plugin-State.

11. PluginKnowledge und semantisches Sounddesign

PluginKnowledge ist an exakten Plugin-Fingerprint und stabilen Host-ParamID gebunden. Evidenzrang: benutzerbestaetigtes Projektwissen, globale User- Korrekturen, kuratierte Adapterdaten, direkte Beobachtung, kontrollierte Inference, Modellhypothese. Hoehere Evidenz gewinnt immer.

Unbekannte Controls werden nicht blind gesweept. Parameter koennen interagieren, diskret sein, je nach Modus etwas anderes bedeuten, Dateien laden, Dialoge oeffnen oder instabil werden. Auditioning passiert nur in Preview, mit einer begrenzten Aenderung und exaktem State-Snapshot um ein Testsignal.

Woerter wie metallisch, hohl, kuerzer oder schwerer werden in versionierte Surge-Rezepte aus Oszillator-, Filter-, Envelope-, Modulations-, Effekt- und Level-Aenderungen uebersetzt. Das Rezept berichtet exakte Vorher-/Nachher-Werte und behauptet nie eine objektiv einzige Bedeutung eines subjektiven Begriffs.

12. Transkription, Analyse und UVR

Basic Pitch nutzt ein gepinntes offizielles ONNX-Modell und eine Rust- Reproduktion der gepinnten Referenz fuer Preprocessing, Windowing, Stitching, Notendecoding und Pitch Bends. Ein Golden Corpus muss Timing, Tonhoehe, Confidence und Bends mit Python vergleichen, bevor Paritaet behauptet wird.

Loudness, True Peak und Spektrum koennen fuer definierte Algorithmen und Versionen deterministisch sein. Key, Chords, Sections, Timbre, Masking und kuenstlerische Aehnlichkeit bleiben heuristisch und tragen Confidence/Evidenz. Multichannel-Quellen behalten Channel-Ergebnisse; Downmix-Proxies duerfen helfen, aber keine zerstoerte Information ersetzen.

UVR bleibt eine separate optionale Anwendung. FF00 konsumiert Stems als normale Referenzen und protokolliert ihre Provenance; es bundelt UVR nicht, verwaltet keine Modelle und macht Separation nicht zur Runtime-Abhaengigkeit.

13. Fehler- und Wiederherstellungssemantik

healthy → degraded → faulted → restarting → healthy
                              └──────────→ quarantined

Eine verpasste Deadline erzeugt definierten Fallback und sichtbares Degraded. Wiederholte Fehler oder ein toter Worker lassen Fault einrasten. Restart ist begrenzt und verzogert; der letzte committed Graph wird erst nach State- Validierung restauriert. Die erste Testpolicy nutzt drei aufeinanderfolgende Misses und hoechstens zwei Auto-Restarts. Wiederholt crashender State geht in Quarantaene statt in eine Restart-Schleife.

Effekte liefern soweit moeglich Latency-ausgerichtetes Dry-Audio. Instrumente liefern Stille, All-notes-off und Reset. Veraltete Shared-Memory-Generationen und spaete IPC-Antworten werden verworfen. Recovery promoted nie Preview-State und meldet keinen ungeprueften Restore als Erfolg.

14. Was „local-only“ bedeuten muss

FF00-Telemetrie, Crash-Uploads, Remote-Web-Inhalte und automatische Netzwerk- Updates sind in der Alpha deaktiviert. Normale Verarbeitung muss einen Netzwerk-Beobachtungstest ohne Non-loopback-Traffic der FF00-Prozesse bestehen. Modelldownloads, Betriebssystem-, WebView-, Ollama- und eigenstaendiger Plugin- Traffic werden getrennt dokumentiert.

Referenzen werden standardmaessig nie hochgeladen. Logs und oeffentliche Validierungsdaten entfernen private Pfade, Keys, Tokens, Mediennamen, opaque Plugin-States und Maschinenkennungen. Local-only beschreibt FF00, nicht jedes vom Benutzer geladene Drittanbieter-Binary.

15. Windows zuerst, Linux an der Grenze

IPC, Shared Memory, Supervision, Realtime Scheduling, Clocks, Locks, Pfade, Plugin Discovery und native Editoren erhalten ab dem ersten Commit explizite Plattformschnittstellen. Windows bleibt die einzige unterstuetzte Audio-Runtime, bis dieselben Vertraege unter Linux getestet sind. Linux-CI darf Core-Code bauen und testen, ohne Waveform- oder VST3-UI-Support zu behaupten.

Die beabsichtigte Repository-Lizenz ist AGPL-3.0-or-later, passend zu den anderen FF00-Anwendungen und dem Contributor Agreement. Vor Release braucht es weiter eine Dependency-/Asset-Inventur, die Code-, Modell- und Runtime-Lizenz, dynamisch geladene Plugins und nicht redistribuierbares Material trennt. Waveform, Surge XT, UVR, Ollama-Modelle und Referenzmedien werden nicht gebundelt.

16. Nachweise, Unbekanntes und Meilensteine

Am 2026-08-20 bestaetigt: Das Development-Rack betreibt pro behaltenem Rack einen externen Worker ueber feste Shared-Memory-Audio-/MIDI-Slots und Named-Pipe- Lifecycle-Steuerung. Komponententests decken eine Zwei-Block-Impulsverzoegerung von 64 bis 1024 Samples und den latenzausgerichteten trockenen Rueckfallpfad nach einem Worker-Abbruch ab.

Waveform 14.0.49 lud das Rack, erzeugte nach dem Duplizieren unabhaengige Worker, beendete beim Schliessen des Edits alle Worker und stellte nach dem Wiedereroeffnen einen neuen Worker her. Das absichtliche Beenden des Live-Workers beendete Waveform nicht; bei einer nicht kritischen Hoerpruefung fiel kein offensichtlicher Fehler auf, und Edit-Schliessen/Wiedereroeffnen stellte den Worker wieder her. Dies ist ein Host-Lifecycle-Pruefpunkt fuer Meilenstein 2, nicht dessen Abschluss.

Noch ungeprueft oder nicht implementiert: gemessene Host-PDC-/Nulltest-Genauigkeit, Allocation-Instrumentierung im Callback, automatischer Neustart und Quarantaene, variable Bloecke und Offline-Rendering, Pipe-ACL-Nachweis, Surge-Hosting und UI, Waveform-Scriptaktionen, Recovery mit korruptem Child-State und beobachtetes Non-Loopback-Netzwerkverhalten. Warnungsfreies Linting fehlt ebenfalls.

Die Architektur verwirft drei verlockende Abkuerzungen: auf den Worker warten, Modelltext als Ausfuehrung behandeln und Waveform-XML schreiben. Jede erleichtert eine fruehe Demo, verschiebt Unsicherheit aber in Echtzeitsicherheit, Wahrheit oder Projektintegritaet. Das Projekt geht erst weiter, wenn die Grenzen die protokollierten Tests ueberstehen.