earshot

earshot: Ohren für einen Agenten

Du kannst nicht hören. Sage niemals, wie Audio klingt oder dass ein Klang "passt", ohne eine earshot-Messung dahinter, und zitiere die Zahl, wenn du Bericht erstattest ("starke Übereinstimmung, z +3,9; p_real 0,96; -14,2 LUFS"). earshot läuft lokal auf der CPU (Audio verlässt nie die Maschine, außer mit dem optionalen llm-Befehl) und speichert jedes Embedding und Ergebnis auf der Festplatte zwischen. Kosten: Jeder CLI-Aufruf startet einen neuen Prozess, der zuerst die Modelle lädt (~20-40 s auf einem ausgelasteten Laptop, selbst für eine zwischengespeicherte Datei); innerhalb des MCP-Servers oder eines Python-Skripts werden die Modelle einmal geladen und wiederholte Aufrufe dauern Sekunden. Verwende für mehr als eine Handvoll Aufrufe MCP oder ein kurzes Skript (from earshot import api; api.find(...); api.realness(...)).

Einrichtung (einmalig)

pip install -e "/pfad/zu/earshot[mcp,llm]"   # oder das Repo-venv: /pfad/zu/earshot/.venv/bin/python -m earshot ...
earshot doctor                           # Pakete, ffmpeg, Modelle (festgelegte Revision, Cache-Status); --load timt sie

Zwei Wege, gleiche Funktionen:

• CLI: earshot <befehl> ... [--json] [--out ergebnis.json]. Textausgabe beginnt mit einer einfachen Zusammenfassung; Zeiten sind m:ss.ss im Text und Sekunden in JSON.
• MCP (Modelle bleiben zwischen Aufrufen geladen): claude mcp add earshot --scope user -e EARSHOT_THREADS=3 -- /pfad/zu/earshot/.venv/bin/python -m earshot mcp, oder in der .mcp.json eines Clients: {"mcpServers": {"earshot": {"command": "/pfad/zu/earshot/.venv/bin/python", "args": ["-m", "earshot", "mcp"], "env": {"EARSHOT_THREADS": "3", "GEMINI_API_KEY": "${GEMINI_API_KEY:-}"}}}} (die Schlüsselzeile nur für das optionale llm-Tool; Claude Code füllt sie aus der Benutzerumgebung, andere Clients benötigen möglicherweise den Schlüssel in der Umgebung, die sie startet: Schreibe niemals einen wörtlichen Schlüssel in eine Projektdatei). Werkzeuge: measure, describe, match, rank, find, compare, ab, realness, timeline, sheet, critique, doctor, llm_critique; die Klangbank (keine Modelle): sfx_list, sfx_render, kit_render (Loop 5). Gib absolute Pfade an; full=true gibt alle JSON zurück. Der Server antwortet innerhalb weniger Sekunden, länger bei einer kalten oder ausgelasteten Maschine; wenn Claude Code keine earshot-Werkzeuge anzeigt, starte es mit MCP_TIMEOUT=60000 (PowerShell: $env:MCP_TIMEOUT=60000; claude). earshot mcp --warm lädt die Modelle beim Start vor.

Wenn die Maschine gemeinsam genutzt wird, setze EARSHOT_THREADS=2-3 (oder --threads 2 bei jedem Befehl). Der erste Modellaufruf eines Prozesses lädt CLAP + AST (~20-60 s); spätere Aufrufe im selben Prozess sind schnell. Jede ffmpeg-lesbare Datei funktioniert, einschließlich des Audios einer mp4 (ein Video ohne Audiospur sagt dies). Fehler sind eine Zeile auf stderr: earshot <befehl>: error: ..., Exit-Code 1.

Loop 1: Ein Asset auswählen

1. earshot rank "ein weicher Filzhammerschlag auf einem Holzblock" downloads/sfx/ --top 5 - Vorauswahl aus einem Ordner.
2. earshot find winner.ogg "ein einzelner sauberer Hammerschlag" --top 3 - die besten Momente als Sample-Trimmungen (Start / Ende in Sekunden). Jedes Segment hat eine Art: stroke (ein Einschwingvorgang bis zum Abklingen) und event (Strokes, die zusammengehören, z. B. das Drücken + Loslassen einer Taste) beginnen 5 ms vor dem Attack und enden nach dem Abklingen; window ist ein Abschnitt, dessen Kanten auf den Klang für einmalige Abfragen eingerastet sind (ein einfacher Abschnitt, zum Überblenden, für Hintergrundflächen). head / tail = wie laut die ersten 5 ms / letzten 10 ms im Vergleich zum Peak des Trimmings sind (-30 dB oder niedriger = sauber); ein Trim, der mit 'head cut' oder 'tail cut' markiert ist, beginnt oder endet innerhalb eines Klangs: Verwende ihn nicht unverändert. --kind event gibt nur onset-basierte Trimmungen zurück (Schläge, Klicks, Schritte), --kind texture nur einfache Fenster (Hintergrundflächen); der Standardwert liest die Anfrage.
3. earshot describe winner.ogg --start 1.12 --end 1.48 - wie es tatsächlich klingt; überprüfe, ob die wichtigsten Tags zu dem passen, was du brauchst, und die Form (Attack / Decay) zum Bild passt. AudioSet-Labels sind bei One-Shots unter ~0,5 s schwach: 'tagger unsicher' oder eine nahe Klasse (Reißverschluss für einen Swish, Fingerschnippen für einen Klick) ist neutral; nur eine eindeutig andere Klasse (Sprache, Musik, Motor, Fahrzeug) ist eine rote Flagge.
4. earshot realness winner.ogg --start 1.12 --end 1.48 (oder ein ganzer Ordner) - beurteile das Trim, das du verwenden wirst: ein Multi-Take-File's p_real ist ein Mittelwert über jeden Take und die Stille dazwischen. Wenn der Benutzer echte oder professionell produzierte Klänge wünscht, verwende kein 'wahrscheinlich code-synthetisiertes' Trim, und lies die Beweise eines 'unsicheren' Trimms, bevor du es verwendest (schreibe, warum du es behalten hast). Wenn synthetisierter Klang der Punkt ist (prozedurale Musik, UI- Töne, mit earshot forge erstellte Klänge), ist Realität Information, keine Hürde. Die Entscheidungsschwellen hängen von der Länge ab (jede Zusammenfassung nennt sie): ein Klang bis zu 6 s verwendet die Clip-Schwellen (lo 0,17 / hi 0,77), eine längere Datei den Mittelwert ihrer 4-s-Fenster mit schwach kalibrierten Dateischwellen (lo 0,40 / hi 0,77), vergleiche also Urteile, nicht rohes p_real, über Dateien unterschiedlicher Länge. Echte Aufnahmen und professionell produzierte Musik und Sounddesign lesen sich normalerweise als real, aber realness hört, wie ein Klang klingt, nicht woher er kommt: saubere professionell synthetisierte Töne (UI-Klänge, Glockenspiele, Synth-Stabs) werden ebenfalls als code-synthetisiert gelesen. Wenn realness nicht verfügbar ist (Modell fehlt), sage klar, dass real-vs-synthetisch nicht überprüft wurde; describe's AudioSet-Klassen (Sinuskurve, Piepton, Synthesizer) sind schwächere Beweise. Exakte digitale Nullen allein beweisen nichts (59 % der lizenzierten echten Aufnahmen des Projekts haben eine Bearbeitungs- oder Ausblendpolsterung).
5. Um zwischen zwei Kandidaten zu wählen: earshot ab a.ogg b.ogg --query "ein knackiger, schneller Luft-Whoosh", mit --a-start/--a-end/--b-start/--b-end für Trimmungen von find (A und B können dieselbe Multi-Take-Datei sein). Optional: earshot match winner.ogg "ein tiefer, dumpfer Tastendruck" --alts "ein klickiger blauer Switch" "eine Schreibmaschinentaste" um eine Behauptung zu testen, oder earshot compare winner.ogg --refs genehmigt/ [--start --end] um zu prüfen, ob es in die Palette passt.

Loop 2: Einen Mix oder Film überprüfen

1. earshot timeline film.mp4 --cues cues.json (oder soundtrack.wav --video film.mp4) - das Hörprotokoll: Ereignisse mit Zeit, Pegel und Tags, Abschnitte, Lautheitskurve, Bildschnitte, Synchronität pro Schnitt / Cue. --detail low ist schnell, high taggt bis zu 96 Ereignisse (die wichtigsten zuerst; die Zusammenfassung sagt, wie viele getaggt wurden, also ist ein nicht getaggtes Ereignis kein fehlender Klang). Lies die Sync-Statistiken: offset_ms = Ton minus Bild (negativ = zu früh), und die 'chance'-Fraktion sagt, was zufällige Schnittpunkte erreichen würden; nur eine Synchronität, die besser ist als Zufall, bedeutet etwas. Ein Schnitt, der ohne Treffer aufgeführt ist, kann dennoch einen leisen Whoosh enthalten: Überprüfe ihn auf dem Blatt, bevor du einen Klang hinzufügst.
2. earshot sheet film.mp4 -o sheet.png --cues cues.json (--from 10 --to 25 zoomt, --detail low ist schneller) - ein kommentiertes PNG: Frames, Abschnitte, beschriftete Ereignisse, Spektrogramm, Lautstärke, Beats, Cue-Marker, farblich nach Synchronität (grün = innerhalb eines Frames, gelb = innerhalb von 100 ms, rot = kein Ton). ÖFFNE DAS PNG mit deinem Bildbetrachter: Lücken, Überlagerungen, Maskierungen und verspätete Treffer sind auf einen Blick erkennbar.
3. earshot critique film.mp4 (--fast überspringt die AudioSet-/realness-Durchläufe) - Bewertungsbogen gegenüber dem gemessenen Bereich professioneller Launch-Filme: jede Metrik ok / niedrig / hoch mit ihrem Gewicht und Aktionen mit Zeitstempeln, und ein Urteil (launch-grade / nah dran / muss verbessert werden / nicht launch-grade). Behebe zuerst kritische Zeilen, führe 1-3 beim neuen Render erneut aus. Sein Anteil der "Einsätze bei visuellen Ereignissen" zählt nur neue Attacken innerhalb von +-100 ms (die Definition der Referenzen); seine Korrekturen und Tipps nennen die Schnitte ohne Ton, durch denselben Matcher wie timeline. Wenn die Datei einer der eigenen Referenzfilme des Profils ist, sagt critique dies und bewertet sie gegen die anderen.
4. Genaue Meter jederzeit (LUFS, True Peak dBTP, LRA, Rauschgrund, Attack/Decay, Helligkeit, Bänder): earshot measure mix.wav [--music] oder das MCP-measure-Tool.

Loop 3: A/B-Vergleich einer Änderung

• earshot ab before.wav after.wav --query "warmer, punchiger Kick" oder --refs pro_refs/ - welcher näher dran ist, und wie B sich von A in gemessenen Worten unterscheidet (lauter, heller, längeres Abklingen). Bei Klängen in längeren Dateien übergib die Trimmungen (--a-start 1.217 --a-end 1.615 --b-start 7.881 --b-end 8.285): ein Ganzdatei-A/B-Vergleich von Multi-Take-Dateien vergleicht jeden Take plus die Stille dazwischen. Dann earshot timeline after.wav und vergleiche die Ereigniszeilen und Sync-Statistiken mit dem alten Lauf. Ändere immer nur eine Sache auf einmal.

Loop 4: Einen Klang im Code machen (earshot forge)

Verwende dies, wenn der Benutzer einen Klang gemacht, nicht ausgewählt haben möchte: Eine KI, die hören kann, kann Synthese-Code schreiben, zuhören und ihn verbessern. Jedes Sample muss berechnet werden (kein aufgenommenes Audio darin, nicht einmal eine Impulsantwort); echte Aufnahmen sind nur die Referenzen, mit denen der Kritiker vergleicht.

1. Schreibe oder wähle ein Rezept in earshot/forge/recipes/<name>.py: SPACE (Parameterbereiche), DEFAULTS, TARGET, ALTS (realistische Verwechslungen) und render(params, r) -> 48-kHz-Array, aufgebaut aus earshot.forge.dsp (modale Resonatoren, Kontaktanregungen, Rauschfarben, ein zeitvariantes SVF, ein berechneter Raum, ein Mikrofon mit Rauschgrund). Modelliere die Physik des echten Dings, gemessen an den Referenzen: was schlägt auf was, was klingt nach, wie lange, in welchem Raum.

2. Führe eine Runde aus: earshot forge <recipe> --refs <echte Referenzen> --budget 144 --reps 2 --tone 1.5 --keep 4 --robust 8 --dir <rundenordner>, oder in einem Python-Skript pro Runde, das die Modelle einmal lädt: forge(recipe, critic=Critic(target, alts, refs, tone=1.5), reps=2, space={...}).

   • --tone bringt die modellfreie Tonbalance und Ausklang in das Ziel.
   • --reps 2 bewertet jeden Kandidaten mit 2 Renderings gegen Glücksrenders.
   • Es dauert etwa 3-5 Minuten pro 160 Renderings auf einem ausgelasteten Laptop-CPU, inklusive 30-60 s Modell-Aufwärmphase.

3. Lies, was es gehört hat. Die Zusammenfassung jeder Auswahl sagt zum Beispiel "klingt wie: ein Korkenknall, ein Glas-Klingeln", "Abklingen +2,4 außerhalb der Referenzen" oder "Tonalität 11,2 dB vom Median der Referenzen: +16 dB bei 500-630 Hz (über jeder Referenz)". Dann überprüfe die Auswahl auf vier Arten:

   • die modellfreien tone-Worte: welche Bänder außerhalb jeder Referenz liegen, die Energieanteile, der Ausklang, die Länge (das vertrauenswürdigste Signal, sobald die Modellbewertungen hoch sind)
   • robust: der Mittelwert über neue Seeds, nicht das glücklichste beste Rendering
   • alt_zs: welche Verwechslung am nächsten liegt
   • Spektrogramme neben den Referenzen: ffmpeg -i x.wav -lavfi showspectrumpic=s=900x360:scale=log:legend=0 x.png

   Die AudioSet-Tags in report.json werden nur zurückgehalten, während du nicht danach auswählst oder steuerst. Lege eine Auswahlregel fest (z. B. den robusten Mittelwert), bevor du hinschaust, und berichte die Tags anschließend.

4. Ändere die Struktur des Rezepts, nicht nur seine Bereiche, für das, was falsch ist (ein fehlender Release-Klick, ein metallischer Klang, ein zu langer Ausklang). Dann wiederhole. Führe ein PROTOKOLL jeder Runde mit Änderungen und Zahlen.

5. Berichte ehrlich, neben den echten Referenzen, bewertet vom selben Kritiker (report.json ref_scores, Leave-one-out).

Goodhart, sag es klar:

• Die Suche optimiert earshots eigene Modelle. Gemachte Klänge übertreffen routinemäßig echte Aufnahmen auf ihnen, was bedeutet, dass der Kritiker zufrieden ist, nicht, dass der Klang besser ist.
• p_real ist leicht zu täuschen: Modale Resonatoren plus ein Raum und ein Mikrofon-Rauschgrund lesen sich als "echt".
• Typikalität belohnt, ein Durchschnitt der Referenzen zu sein.
• Die Modellprüfungen sättigen: Nach einer Suche liegen jede Modellprüfung, zurückgehaltene Formulierungen und unabhängige reale Sets eingeschlossen, den gemachten Klang innerhalb der echten. Nur Messungen und Ohren können sie noch unterscheiden.
• Beurteile anhand der gemessenen Nähe zu den Referenzen: Tonbalance, Bänder außerhalb jeder Referenz, Ausklänge, Längen. Verwende auch robuste Neurenderings und Spektrogramme.
• Bitte um einen menschlichen Blindtest (zufällige Reihenfolge, lautheitsangepasst, verborgener Schlüssel), bevor du einen gemachten Klang als "so gut wie echt" bezeichnest.

Im ersten Test (demo/forge-test) fand ein unabhängiger Richter den Tastenanschlag 8-13 dB von der echten Tonbalance entfernt und die Pops bandunbegrenzt mit langen zischenden Ausklängen, während jede Modellprüfung sie als echt bezeichnete. Nach der Neuerstellung durch Steuerung mit der modellfreien Prüfung liegen sie jetzt innerhalb der gemessenen Streuung der echten Aufnahmen. Der Whoosh wurde als wirklich schneller neu erstellt. Der Impact (dunkler, swel-geführt) und der Klick (kurze Ausklänge) wurden nicht neu erstellt. Noch kein Mensch hat zugehört.

Loop 5: Das Sound-Kit eines Films erstellen (earshot sfx / earshot kit)

Verwende dies, wenn ein code-erstellter Film (ein cinetic-Film, jedes Cue-Sheet) seine Effekte benötigt: Rendere sie aus earshots mitgeliefertem Bank anstatt Synth-Stimmen zu schreiben. Es werden keine Modelle geladen; ein ganzes Kit rendert in etwa einer Minute und neu rendert in Sekunden.

1. Starte von einem Preset: earshot kit init --preset calm -o audio/kit.json (calm für textgeführte Filme, crisp für energiegeladene Produktfilme, minimal für gestaltete Effekte-only-Filme, launch für Filme, die auf Musik geschnitten sind). Die Notiz jeder Rolle (note) sagt, warum ihr Klang gewählt wurde. calm / crisp / minimal lassen Riser, Swell und Suck aus: Eine Enthüllung löst sich auf einem Element auf, und das Lockup ist ein einziger sauberer Treffer. launch lässt einen Riser oder Reverse-Swell bei einem Abschnittswechsel auf und verwendet die 0,4 Klänge, die für musikgeführte Filme erstellt wurden (unten).
2. Passe es an den Film an: earshot sfx list --kind hit (oder --category) zeigt die Kandidaten mit Längen, Peak-Zeiten und Knöpfen. Ändere den sound einer Rolle, setze edits (pitch auf den Grundton des Films für den Treffer oder Drop, dur / apex für eine feste Bewegung), takes (12 oder mehr für Tippen, 2-4 anderswo), level_db. Höre einen Kandidaten mit earshot sfx render ID -o x.wav [--pitch E5] [--dur 0.8 --apex 0.32] an und lese seinen gemessenen Onset / Peak / End.
3. Rendere: earshot kit render audio/kit.json --out audio/kit. Die Takes und kit.lock.json (gemessener Onset, Peak, End, Lautstärke pro Take) werden vom Mischer auf Cue-Frames platziert: Onset auf dem Frame für Treffer und Berührungen, der Peak auf dem Höhepunkt eines Whoosh, das Ende auf dem Treffer eines Riser (sein Peak, wenn die Rolle auf peak ausgerichtet ist, wie bei launch's Riser und Swell: diese Mitglieder fallen nach ihrem Höhepunkt; kit check notiert ein end-ausgerichtetes).
4. Überprüfe: earshot kit check audio/kit.json --out audio/kit. Es verweigert, was ein Rendering nicht verwenden kann (einen Knopf oder eine Tonhöhe, die der Klang nicht verträgt, einen Pegel über 0 dBFS). kit check gibt eine Checkliste der Rollen aus, an denen gearbeitet werden muss.
5. Rufe ein Preset mit earshot kit init --preset crisp --no-hits --no-risers --no-footsteps um Rollen aus dem Bank und die Vorschläge des Presets zu erhalten. Jeder Befehl akzeptiert --gender m/f um das Geschlecht für Rollen wie Atem, Seufzer oder Kuss zu wählen.

Die Bank von earshot enthält 72 Rolldateien mit lebensechtem Raum, wobei 0,4 eine rohe, raumlose Version (für Mix-Integration) sind. Die Rollen sind für den Schnitt optimiert (Peak innerhalb der ersten 10-20 % auf einem Schlag) und können beim Rendern per Knopfdruck, Tonhöhe und Länge angepasst werden. Sie sind unter earshots eigener Lizenz lizenziert; lies die Nutzungsbedingungen in der eingecheckten README.

Bedingungen

• Zeitstempel: Verwende die von find oder timeline gemeldeten Zeiten (und schreibe einen Iso-Dateinamen ins JSON für die Klarheit zwischen Sessions). Verwende für ab / compare die von find gemeldeten Trimmungszeiten, nicht den geschätzten Onset des Trims.
• Konfidenz: Gib die gemeldete Punktzahl (Text sowie JSON) immer an, wenn das Tool sie angibt, und erzähle eine kurze Geschichte, die die Zahl erklärt ("z +3.9 = eine starke Übereinstimmung"). Die Bewertungen von ab, match, compare und forge stehen in ekldischer Distanz (Einheiten der Varianz der Referenzgruppe). Die Skalierung: eine z unter 1 ist okay, 1-3 ist gut, 3+ ist echt stark. Wenn der Referenzpool nur eine Datei enthält, sagt jeder Vergleich z = inf: die Übereinstimmung kann nicht normalisiert werden. Sage dann, um wie viele Standardabweichungen die Kandidaten von diesem Referenzmittelwert abweichen ist unbekannt, und liste stattdessen die Rohdistanzen auf.
• Alternativen: Wenn der Benutzer einen Klang ablehnt und nach einem anderen von dem Vergleich fragt, biete die 2. und 3. Wahl von dem compare-Lauf an (verwende in der Zwischenzeit nicht find noch einmal auf demselben Ordner, es sei denn, die Benutzeranfrage ist eine andere Geste). Aber für eine neue Benutzeranfrage (ein anderes Ziel) verwende find erneut.
• Anreicherung: Wenn der Benutzer nichts über die Audioanfrage sagt, frage nach einer Richtung (geerdet, klar, subjektiv), bevor du ein Tool aufrufst. Beschreibe, was das Tool auf der Grundlage seines Wissensschwellenwerts misst und garantiert. Wenn der Benutzer Messungen und Ohren verwechselt, korrigiere ihn taktvoll: "Die Metapher 'hören' steht für messen + klassifizieren in spektralen und einschwingungsbezogenen Räumen; ein direkter Vergleich mit menschlichen Ohren, geschweige denn kreative Ästhetik, ist nicht enthalten".
• Dokumentation: Verwende diese Anleitung und den Inhalt von earshot/forge/recipes/*.py als Quelle.

Werkzeugliste

Tool	Eingabe	Ausgabe	Verwendung
measure	Datei-Pfad (optional Start/Ende)	LUFS, True Peak dBTP, LRA, Bänder, Rauschgrund, Attack/Decay, Helligkeit	Beliebige Audio-Eigenschaft sofort messen
describe	Datei-Pfad (optional Start/Ende)	AudioSet-Tag-Liste, Attack/Decay-Form	Identifiziere Klänge, die deiner Absicht entsprechen
match	Datei-Pfad (optional Start/Ende), Abfrage-Text, optionale Alternativen	Ekldische Distanz zur Abfrage, optional z für Alts	Wie nah ein Klang an Ihrer Beschreibung liegt
rank	Abfrage-Text, Ordner-Pfad	Rangfolge der Dateien nach Ähnlichkeit zur Abfrage	Beste Dateien aus einem Ordner für eine Stimmungs-/Klanganfrage auswählen
find	Datei-Pfad, Abfrage-Text (optional Start/Ende)	Trim-Liste (Start/Ende, Art, head/tail cut, SNR)	Beste Momente in einer Aufnahme finden
compare	Datei-Pfad (Referenz), Referenzliste	z-Distanz zu jeder Referenz, zusammenfassende z	Passform in einer Referenzmenge testen
ab	Datei-Pfad A, Datei-Pfad B (optional Start/Ende pro Datei)	z-Distanz zur Abfrage für jede Datei, Differenz in Worten	A/B-Vergleich zweier Kandidaten
realness	Datei-Pfad (oder Ordner, optional Start/Ende)	p_real (0-1), Ensemble-Schätzung, zusammenfassendes Urteil	Echte Aufnahme vs. code-synthetisiert beurteilen
timeline	Audio-Datei (optionale Video-Datei)	Ereignisliste mit Zeit/Level/Tags, Abschnitte, Sync-Stats, Lautheitskurve	Hörprotokoll einer Mischung oder eines Films
sheet	Audio-Datei, Cues (optional Start/Ende)	Kommentiertes PNG-Bild mit Spektrogramm und Cues	Sichtprüfung des Audio-/Film-Inhalts
critique	Audio-Datei (optionales Video)	Scorecard (Metriken, Gewichte, Aktionen, Urteil)	Mischung/Film gegen Launch-Grade-Referenzen bewerten
doctor	Keine (--load zum Timen der Modell-Ladezeiten)	Paket-Prüfstatus, Modell-Status	Einrichtung und Abhängigkeiten überprüfen
llm_critique	Audio-Datei, optionaler Kontext	Menschenlesbare Kritik (beschreibend + bewertend)	Verfeinerte Kritik mit LLM-Generierung erhalten
sfx_list	optional --kind, --category	Tabelle der Kandidaten mit Längen, Peak-Zeiten, Knöpfen	Bank-Klänge anzeigen
sfx_render	ID, Ausgabe-Pfad, Knöpfe	Generierte WAV-Datei mit Onset/Peak/End-Werten	Einen Kandidaten-Klang hören
kit_init	Preset, Ausgabe-Pfad	JSON-Kit mit Rollen und Notizen	Neues Sound-Kit erstellen
kit_render	Kit-JSON, Ausgabe-Ordner, optionale Überschreibungen	WAV-Dateien + kit.lock.json (Onset/Peak/End pro Take)	Kit-Rendering mit gemessenen Metadaten
kit_check	Kit-JSON	Checkliste der Rollen, die Arbeit benötigen / sicher zu rendern sind	Kit vor dem Rendern validieren

Diese Werkzeuge sind über CLI, MCP-Tools oder die Python-API verfügbar.