Cómo crear un plugin VST3 o CLAP con un agente de programación de IA

Por qué los agentes se equivocan con los plugins de audio

Una biblioteca C++ poco conocida rara vez hace que un agente se niegue. Hace que improvise, y los plugins de audio castigan la improvisación de tres formas:

1. Nombres inventados. Una clase que debería existir, como un CompressorPro, o una clase real a la que se le asigna un método de otro framework. El código se lee perfectamente y no compila.
2. Código que compila y sigue siendo incorrecto. Una asignación de memoria o un bloqueo dentro de process(), que se ejecuta en el hilo de audio. Funciona en la máquina del desarrollador y se cae bajo carga en la sesión de otra persona.
3. Reglas que no viven en la API. Un limitador con look-ahead que no informa de su latencia desplaza toda mezcla en paralelo en la que se encuentre. Una tabla de parámetros reordenada en la versión 1.1 carga las sesiones antiguas en los controles equivocados. Ninguna cabecera dice nada de eso.

El primer problema es de nombres, el segundo de comportamiento y el tercero de convenciones. Un modelo más grande no ayuda con ninguno de ellos, porque la información no está en sus datos de entrenamiento con la fiabilidad suficiente como para confiar en ella.

Lo que el agente necesita en su lugar

Tres cosas, cada una respondiendo a uno de esos modos de fallo:

Las tres se generan a partir de las cabeceras del SDK por el mismo script. Eso importa más de lo que parece. Una chuleta escrita a mano para agentes se desvía del código en una versión, y entonces se convierte en una segunda fuente de nombres inventados. Aquí, npm run verify:llms hace fallar la compilación si los archivos no coinciden con las cabeceras, y npm run verify:mcp comprueba que la búsqueda encuentra cada tipo público, de modo que un «sin coincidencias» del servidor es una respuesta real y no un hueco en un índice.

Las seis herramientas del servidor MCP

El servidor se ejecuta desde una copia local por stdio, solo necesita Node.js, y cada herramienta solo lee archivos de la copia.

Un ejemplo de la diferencia que marca. Si se le pide CompressorPro, el servidor responde que nada del SDK coincide. Si se le pide «ladder filter», devuelve LadderFilter y el ladder de diodos, con las cabeceras en las que están. El agente escribe lo segundo, no lo primero.

Configuración

Clona el SDK y luego añade la skill y el servidor a tu agente. Para 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 usa -a codex y codex mcp add. Cursor y Antigravity usan la skill con -a cursor o -a antigravity, y el servidor en su archivo de configuración de MCP. El botón Instalar skill y MCP de la página de inicio tiene los comandos exactos para cada uno. Sin la herramienta de línea de comandos skills, copiar skills/sonore-sdk a la carpeta de skills del agente hace el mismo trabajo.

Un primer prompt que funciona

Sé concreto con el plugin, y di qué significa terminado:

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.

Con la skill cargada, el agente sigue el flujo de trabajo del SDK por sí mismo: genera un proyecto con sonore_new_plugin.cmake, escribe el DSP en el único src/plugin.cpp, comprueba los nombres a medida que avanza y compila. Un solo archivo fuente se convierte en un .clap, un .vst3, un Audio Unit en macOS, un bundle LV2 y una aplicación independiente, y el mismo proyecto compila un AUv3 para iPhone y iPad y una app para Android.

Qué significa «terminado»

Un plugin que compila es un borrador. El proyecto generado da al agente tres comprobaciones que superar, en orden según lo que demuestran:

1. Compila todos los formatos desde una sola compilación.
2. ctest pasa. Ejecuta dos pruebas. El --verify de la aplicación independiente renderiza audio sin conexión y comprueba que está sano. En un proyecto compilado desde una copia del SDK, la auditoría en tiempo real (sonore_add_rt_test) cuenta cada asignación de memoria hecha en el hilo de audio a través de frecuencias de muestreo y tamaños de bloque, y falla ante cualquiera. El SDK somete sus propios ejemplos al mismo listón: nueve frecuencias de muestreo de 8 kHz a 384 kHz, tamaños de bloque de 1 a 8192 y cero asignaciones.
3. Los validadores pasan. clap-validator y pluginval cargan el plugin como lo hacen los hosts. Ambas plantillas de proyecto pasan con el nivel de exigencia 10 de pluginval tal como se generan, así que un fallo es algo que introdujo el agente.

La auditoría y los validadores detectan lo que la lectura del código no detecta, por eso van en el prompt.

Lo que aún depende de ti

Un agente con las herramientas adecuadas escribe un plugin que carga, pasa la validación y no asigna memoria en el hilo de audio. No puede decirte si el saturador suena bien, si la interfaz se siente bien en una sesión, o si un host que te importa se comporta como debe. La escucha, el criterio y las pruebas en tu propia DAW siguen siendo tuyos. Lo mismo ocurre con los formatos que tienen guardianes: AAX requiere el acuerdo de desarrollador de Avid y la firma PACE, que ningún framework puede conceder.

Para la versión paso a paso, sin agente, lee Primeros pasos. Para ver cómo se compara el SDK con JUCE, iPlug2 y el resto, consulta Frameworks de plugins de audio comparados.

Fuentes

• Repositorio de Sonore SDK: la sección “Writing plugins with a coding agent” del README, llms.txt y scripts/mcp-server.mjs
• La skill sonore-sdk
• Especificación del Model Context Protocol
• Formato Agent Skills
• Convención llms.txt