Projekte / FF00 Studio / Technischer Anhang

Experimental Pre-Alpha / Rack, Worker, Surge-Autoritaet und Windows-Paket 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. Eine unsignierte Windows Experimental Pre-Alpha ist mit Warnungsdialog, Pruefsumme, Anleitung, Buildmanifest und exakt passendem AGPL-Quellcode-Commit oeffentlich.

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. Der Rust-Kern besitzt stabile Snapshot- Primitive, der Waveform-XML-Snapshot-Parser ist aber noch nicht integriert. Sein Vertrag lautet: stabile Kopie, versionsbezogene Whitelist, unbekanntes XML und Plugin-State opaque behandeln und die Projektdatei nie rekonstruieren oder serialisieren.

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. Der aktuelle Surge-Proof nutzt einen opferbaren Inspektionsprozess; ein allgemeiner Scanner-Dienst mit Timeout und persistenter Quarantaene bleibt geplant. Der Worker besitzt bereits getestete Surge-Instanz, Mono-/Stereo-Audio, MIDI, Kind-UI, Parameter, opaque State und Teardown. Allgemeine Latency-, Tail-, Bypass-, Multi-bus- und Plugin-Sonderfaelle bleiben offen.

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. Der Rust-Kern validiert derzeit den begrenzten Graphvertrag; Worker-seitige Runtime-Graph-Ausfuehrung existiert noch nicht. Die Alpha erlaubt absichtlich nur Mono-/Stereo-Main-I/O, einen optionalen Mono-/Stereo-Sidechain pro Node, feste Layouts und kein Feedback.

Das erforderliche Runtime-Design baut und prepared Graphs ausserhalb des Audio- Threads als immutable Plaene. Der spaetere Executor muss Pfad-Latency berechnen, kuerzere Zweige kompensieren, deterministische MIDI-Reihenfolge definieren und eine Revision publizieren. Blockgrenzen-Swap, sichere Topologie-Crossfades und verzoegertes Entfernen sind Acceptance-Kriterien, keine Implementationsclaims.

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 implementierte Verbindung traegt Rack-UUID, PID, Prozessstart-Nonce, Connection-Generation und Protokollversion. Der aktuelle Windows-Endpunkt erbt noch die Prozess-/Standard-DACL; eine ausdrueckliche Current-user-only-Pipe-ACL bleibt Release-Gate. Major-/Minor-Capability-Negotiation, asynchrone Jobs und Cancellation sind ebenfalls geplant. Erwartete Graph-Revisionen weisen alte Mutationsanfragen bereits ab.

Master entdeckt mehrere Racks derzeit ueber je einen ephemeren, versionierten Registry-Eintrag pro vorbereitetem Rack. Discovery ist keine Autoritaet: Rack- UUID, Generation, Authority-Modus und committed Basisrevision werden am Endpunkt erneut geprueft. Ein spaeterer Per-user-Broker kann dieses Rendezvous ersetzen. Aktuelle synchrone Befehle melden nur das deterministische Executor-Resultat.

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.

Diese Grenze hat nun Production-path-Evidenz. Master uebersetzt bis zu drei aus neun kuratierten Surge-Richtungen in einen exakten, schreibgeschuetzten ParamID-/ Werteplan. Eine getrennte Aktion erzeugt Preview; Discard restauriert committed State; Apply erhoeht die committed Revision einmal. Eine Headless-Rack-/Worker-/ Surge-Transaktion bestaetigte sechs Parameter-Readbacks, exaktes Replanning nach Discard, Revision 1 zu 2 bei Apply und die Abweisung des alten Plans. Menschliches Waveform-Auditioning und Semantic-batch-Save/Reopen bleiben offen.

9. Session-Sidecar und Provenance

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

Der Rust-Sidecar-Crate implementiert die Kernvertraege fuer Manifest, atomaren Ersatz, JSONL, immutable Asset-Identitaet und stabile Source-Snapshots. Die Integration in Master und ein echtes Waveform-Projekt bleibt geplant. Die vorgesehene Runtime hat einen Writer; events.jsonl ist bis zum letzten vollstaendigen Record wiederherstellbar; Locks tragen PID und Prozessstart-Nonce.

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.

Der erste versionierte Surge-XT-1.3.4-Adapter ist fuer metallic, hollow, shorter, wider, harsher, cleaner, more movement, less transient und heavier in je drei begrenzten Intensitaeten implementiert. Er arbeitet nur mit dem vollstaendigen, eindeutigen Katalog von 2.855 ParamIDs des getesteten Builds, kombiniert hoechstens drei verschiedene Richtungen, meldet Saturation und weist ID-/Namensabweichungen ab. Persistentes PluginKnowledge, User-Korrekturschichten und kontrolliertes Auditioning unbekannter Plugins bleiben geplant.

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.

Das oeffentliche Forgejo-Repository ist unter AGPL-3.0-or-later lizenziert, passend zu den anderen FF00-Anwendungen und dem Contributor Agreement. Das oeffentliche unsignierte Windows-Paket installiert Master und das Development- Rack samt Worker fuer den aktuellen Benutzer. Exakter Source-Commit, Pruefsumme, Buildmanifest, Anleitung, Lizenz und Drittanbieterhinweise sind verlinkt. Dependency-/Rechtspruefung, Codesignierung und der echte Installations-/ Deinstallationstest bleiben offen. Waveform, Surge XT, UVR, Ollama-Modelle und Referenzmedien werden nicht gebundelt.

16. Nachweise, Unbekanntes und Meilensteine

Am 2026-09-12 mit Evidenz bis 2026-09-10 abgeglichen: 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 schema-valide Beratung ohne Mutation-Tools. Deterministische Normalisierung verhindert nun, dass wiederholte Model-Richtungs-IDs gestapelt werden. Der Neun-Richtungs-Surge-Adapter, die Exact-plan-Review-UI, der modellfreie Selector und die Headless-Preview-/Discard-/ Apply-Transaktion bringen Meilenstein 6 weiter, ohne persistentes PluginKnowledge oder Live-Auditioning als abgeschlossen darzustellen.

Der komplette Rust-Workspace besteht 16 Tests; der optimierte native Pfad besteht alle fuenf CTest-Eintraege. Das erste oeffentliche Installationsprogramm 0.0.1 experimental-pre-alpha ist 4.246.035 Bytes gross; SHA-256: CFDC80DCF1D7A2697EEDA94C2DC3E2A2217A1EC55403FC8CA7038ABBEFC9BD2D. Statische Manifest-/Pruefsummenvalidierung bestand; der Installer selbst hat das Close-host-Install-/Uninstall-Acceptance-Verfahren noch nicht abgeschlossen.

Noch ungeprueft oder unvollstaendig: die verbleibenden 256- und 1024-Sample- Full-duration-Host-PDC-/Nulltests, Host-Allocation-Instrumentierung, variable Bloecke und Offline-Rendering, explizite Pipe-ACL, Split/Merge-Graph und Sidechain, Waveform-Scriptaktionen, Request-Cancellation, persistentes PluginKnowledge, Live-Semantic-Audition/Save-Reopen, Transkription, beobachtetes Non-loopback-Netzwerkverhalten, Installer/Uninstaller-Acceptance und warnungsfreies Linting. Die 64-, 128- und 512-Sample-Host-Renders sind explorative Passes unter der protokollierten Short-render-Einschraenkung.

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.