Projekte / FF00 Studio / Technischer Anhang

Pre-Alpha / Rack, Worker, Master und lokaler Discuss-Pfad 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

Der erste implementierte Provider ist Ollama auf kanonischem Loopback. Master listet lokal installierte Modelle und bevorzugt aktuell das auf dieser Maschine gepruefte qwen3:8b; qwen3:14b bleibt waehlbar, und die Modellwahl bleibt austauschbar. Der Client folgt weder Redirects noch Proxies, begrenzt Prompt, Kontext und Antwort und lehnt Non-loopback-Endpunkte sowie als Cloud bezeichnete Modelle 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.

Der erste Provider-Slice ist ausschliesslich Discuss. Er erhaelt keine Executor- Tools; sein Schema enthaelt nur Summary, Beobachtungen, unverbindliche Optionen und Unbekanntes. Rust prueft Form und Grenzen vor der Anzeige. Der erste direkte Structured-Output-Test lief mit qwen3:8b in 23,22 Sekunden durch; das 14B-Modell ueberschritt auf derselben Maschine das 180-Sekunden-Usability-Limit. Das ist keine dauerhafte Qualitaetsrangliste.

Lange Arbeit soll als asynchroner Job laufen. Request-Cancellation ist noch nicht implementiert. Kontext-Summaries sind provenance-tragende Inputs, kein Nachweis des aktuellen Plugin-State, und die aktuelle Modellantwort hat keinen Pfad zu Preview oder Apply.

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

Bis 2026-09-06 bestaetigt: Das Development-Rack betreibt pro behaltenem Rack einen externen Worker ueber feste Shared-Memory-Audio-/MIDI-Slots und Named-Pipe- Steuerung. Komponententests decken feste Bloecke von 64 bis 1024 Samples, Delayed-Dry-Fallback, begrenzten Ersatz, Restart-Limit, Quarantaene und State- Restore nach Worker-Abbruch ab.

Waveform 14.0.49 hat inzwischen Surge XT 1.3.4 durch diesen Worker gehostet. Master erkannte das Rack, listete 2.855 Host-Parameter und fuehrte exakte Preview-, Discard- und Apply-Uebergaenge aus. Applied Surge State ueberstand Save, Close und Reopen. Zwei Rack-Instanzen blieben getrennt adressierbar. Das Beenden eines exakten Workers waehrend Playback liess Waveform und den zweiten Worker aktiv, verursachte bei der Hoerpruefung keine wahrnehmbare Aenderung und fuehrte zu begrenztem Ersatz. Beim Schliessen des Edits verschwanden alle Worker und Registrierungen. Der Hoertest ist kein Capture-Nachweis fuer clickfreie Recovery.

Der erste lokale Ollama-Discuss-Pfad lieferte ausserdem schema-valide Beratung, ohne Mutation-Tools zu erhalten. Damit wurden Meilensteine 3, 4 und 6 weitergebracht, aber nicht abgeschlossen.

Noch ungeprueft oder unvollstaendig: volle Host-PDC-/Nulltest-Matrix, Host- Allocation-Instrumentierung, variable Bloecke und Offline-Rendering, Pipe-ACL- Nachweis, Split/Merge-Graph und Sidechain, Waveform-Scriptaktionen, Request- Cancellation, semantische Surge-Rezepte, PluginKnowledge, Transkription 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.