So baust du ein VST3- oder CLAP-Plugin mit einem KI-Coding-Agenten

Warum Agents Audio-Plugins falsch machen

Eine unbekannte C++-Bibliothek bringt einen Agenten selten dazu, die Arbeit zu verweigern. Sie bringt ihn zum Improvisieren, und Audio-Plugins bestrafen Improvisation auf drei Arten:

1. Erfundene Namen. Eine Klasse, die es geben sollte, etwa eine CompressorPro, oder eine echte Klasse mit einer Methode aus einem anderen Framework. Der Code liest sich einwandfrei und kompiliert nicht.
2. Code, der kompiliert und trotzdem falsch ist. Eine Allokation oder ein Lock innerhalb von process(), das im Audio-Thread läuft. Auf dem Rechner des Entwicklers funktioniert es und setzt unter Last in der Session eines Nutzers aus.
3. Regeln, die in keiner API stehen. Ein Look-ahead-Limiter, der seine Latenz nicht meldet, verschmiert jeden parallelen Mix, in dem er steht. Eine Parametertabelle, die in Version 1.1 umsortiert wurde, lädt alte Sessions in die falschen Regler. Nichts im Header sagt das.

Das erste Problem betrifft Namen, das zweite Verhalten, das dritte Konventionen. Ein größeres Modell hilft bei keinem davon, weil die Informationen in seinen Trainingsdaten nicht verlässlich genug sind, um ihnen zu trauen.

Was der Agent stattdessen braucht

Drei Dinge, von denen jedes eine dieser Fehlerarten beantwortet:

Alle drei werden vom selben Skript aus den Headern des SDK generiert. Das ist wichtiger, als es klingt. Ein handgeschriebenes Spickzettel für Agents driftet innerhalb eines Releases vom Code weg, und dann ist es eine zweite Quelle für erfundene Namen. Hier schlägt npm run verify:llms den Build fehl, wenn die Dateien nicht mehr zu den Headern passen, und npm run verify:mcp prüft, dass die Suche jeden öffentlichen Typ findet. So ist „keine Treffer“ vom Server eine echte Antwort und keine Lücke in einem Index.

Die sechs Werkzeuge des MCP-Servers

Der Server läuft aus einem lokalen Checkout über stdio, braucht nur Node.js, und jedes Werkzeug liest nur Dateien im Checkout.

Ein Beispiel für den Unterschied. Auf die Frage nach CompressorPro antwortet der Server, dass im SDK nichts passt. Auf „ladder filter“ liefert er LadderFilter und die Diode-Ladder-Schaltung, mit den Headern, in denen sie liegen. Der Agent schreibt das Zweite, nicht das Erste.

Einrichtung

Klone das SDK und füge dann Skill und Server deinem Agenten hinzu. Für Claude Code:

git clone https://github.com/SonorieAI/sonore-sdk "$HOME/sonore-sdk"
npx skills add SonorieAI/sonore-sdk --skill sonore-sdk -a claude-code -g
claude mcp add --scope user sonore-sdk -- node "$HOME/sonore-sdk/scripts/mcp-server.mjs"

Codex nimmt -a codex und codex mcp add. Cursor und Antigravity bekommen den Skill mit -a cursor bzw. -a antigravity und den Server in ihrer MCP-Konfigurationsdatei. Der Button Skill & MCP installieren auf der Startseite enthält die genauen Befehle für jeden. Ohne das Kommandozeilenwerkzeug skills erledigt das Kopieren von skills/sonore-sdk in den Skill-Ordner des Agenten dieselbe Aufgabe.

Ein erster Prompt, der funktioniert

Sei konkret, was das Plugin angeht, und sag, was „fertig“ heißt:

Make a tape-style saturator plugin with Drive, Tone and Mix.
Start from a generated Sonore project. Look up every sonore:: name
before you use it. It is done when it builds, ctest passes, and
clap-validator and pluginval run clean.

Mit geladenem Skill folgt der Agent dem Workflow des SDK von selbst: Er erzeugt ein Projekt mit sonore_new_plugin.cmake, schreibt die DSP in die eine src/plugin.cpp, prüft Namen unterwegs und baut. Aus einer Quelldatei entstehen eine .clap, eine .vst3, eine Audio Unit unter macOS, ein LV2-Bundle und eine Standalone-App. Dasselbe Projekt baut außerdem einen AUv3 für iPhone und iPad sowie eine Android-App.

Was „fertig“ heißt

Ein Plugin, das kompiliert, ist ein Entwurf. Das generierte Projekt gibt dem Agenten drei Prüfungen vor, in der Reihenfolge, wie viel sie beweisen:

1. Es baut alle Formate aus einem einzigen Compile-Lauf.
2. ctest besteht. Es laufen zwei Tests. Das --verify der Standalone-App rendert Audio offline und prüft, dass es gesund ist. In einem Projekt, das aus einem SDK-Checkout gebaut wird, zählt das Echtzeit-Audit (sonore_add_rt_test) jede Allokation im Audio-Thread über Samplerates und Blockgrößen und schlägt bei jeder fehl. Das SDK hält seine eigenen Beispiele auf derselben Messlatte: neun Samplerates von 8 kHz bis 384 kHz, Blockgrößen von 1 bis 8192, null Allokationen.
3. Die Validatoren bestehen. clap-validator und pluginval laden das Plugin so, wie Hosts es tun. Beide Projektvorlagen bestehen sie auf Strenge 10 von pluginval, so wie sie generiert werden. Ein Fehler ist also etwas, das der Agent eingebaut hat.

Das Audit und die Validatoren finden, was das Lesen des Codes nicht findet, und deshalb gehören sie in den Prompt.

Was weiterhin bei dir liegt

Ein Agent mit den richtigen Werkzeugen schreibt ein Plugin, das lädt, die Validierung besteht und im Audio-Thread nichts allokiert. Er kann dir aber nicht sagen, ob die Sättigung gut klingt, ob sich die Oberfläche in einer Session richtig anfühlt oder ob ein Host, der dir wichtig ist, sich richtig verhält. Hören, Geschmack und Tests in deiner eigenen DAW bleiben bei dir. Ebenso die Formate mit Türstehern: AAX braucht Avids Entwicklervereinbarung und PACE-Signierung, und das kann kein Framework gewähren.

Für die Schritt-für-Schritt-Variante ohne Agenten lies Erste Schritte. Wie sich das SDK mit JUCE, iPlug2 und den übrigen vergleicht, siehe Audio-Plugin-Frameworks im Vergleich.

Quellen

• Sonore-SDK-Repository: der Abschnitt „Writing plugins with a coding agent“ in der README, llms.txt und scripts/mcp-server.mjs
• Der sonore-sdk-Skill
• Model-Context-Protocol-Spezifikation
• Agent-Skills-Format
• llms.txt-Konvention