Como criar um plugin VST3 ou CLAP com um agente de programação de IA

Por que agentes erram plugins de áudio

Uma biblioteca C++ desconhecida raramente faz o agente recusar a tarefa. Ele improvisa, e plugins de áudio punem a improvisação de três maneiras:

1. Nomes inventados. Uma classe que deveria existir, como um CompressorPro, ou uma classe real recebendo um método de outro framework. O código parece perfeito e não compila.
2. Código que compila e ainda assim está errado. Uma alocação ou um lock dentro de process(), que roda na thread de áudio. Funciona na máquina do desenvolvedor e cai sob carga na sessão de alguém.
3. Regras que não estão em lugar nenhum da API. Um limitador com look-ahead que não informa sua latência espalha qualquer mix paralelo em que for colocado. Uma tabela de parâmetros reordenada na versão 1.1 carrega sessões antigas nos controles errados. Nenhum cabeçalho diz isso.

O primeiro problema é de nomes, o segundo de comportamento, o terceiro de convenções. Um modelo maior não ajuda em nenhum deles, porque a informação não está nos dados de treinamento com confiabilidade suficiente para ser confiável.

O que o agente precisa, em vez disso

Três coisas, cada uma respondendo a um desses modos de falha:

Tudo isso é gerado a partir dos cabeçalhos do SDK pelo mesmo script. Isso importa mais do que parece. Uma cola manual para agentes se distancia do código em uma versão, e então vira uma segunda fonte de nomes inventados. Aqui, npm run verify:llms falha o build se os arquivos divergirem dos cabeçalhos, e npm run verify:mcp confere se a busca encontra cada tipo público, então um “no match” vindo do servidor é uma resposta real, e não uma lacuna no índice.

As seis ferramentas do servidor MCP

O servidor roda a partir de um checkout local via stdio, precisa apenas do Node.js, e cada ferramenta só lê arquivos do checkout.

Um exemplo da diferença que isso faz. Quando pedido CompressorPro, o servidor responde que nada no SDK corresponde. Quando pedido “ladder filter”, ele devolve LadderFilter e o filtro ladder de diodo, com os cabeçalhos em que estão. O agente escreve o segundo, não o primeiro.

Configuração

Clone o SDK e depois adicione a skill e o servidor ao seu agente. Para o 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"

Para o Codex, use -a codex e codex mcp add. Para o Cursor e o Antigravity, instale a skill com -a cursor ou -a antigravity e configure o servidor no arquivo de configuração MCP deles. O botão Instalar Skill e MCP na página inicial traz os comandos exatos para cada um. Sem a ferramenta de linha de comando skills, copiar skills/sonore-sdk para a pasta de skills do agente faz o mesmo trabalho.

Um primeiro prompt que funciona

Seja específico sobre o plugin e diga o que significa “pronto”:

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.

Com a skill carregada, o agente segue o fluxo de trabalho do SDK por conta própria: gera um projeto com sonore_new_plugin.cmake, escreve o DSP no único src/plugin.cpp, confere os nomes à medida que avança e compila. Um arquivo-fonte vira um .clap, um .vst3, um Audio Unit no macOS, um bundle LV2 e um aplicativo standalone, e o mesmo projeto gera um AUv3 para iPhone e iPad e um app Android.

O que significa “pronto”

Um plugin que compila é um rascunho. O projeto gerado oferece ao agente três verificações, em ordem do que cada uma prova:

1. Ele compila todos os formatos a partir de uma única compilação.
2. O ctest passa. Ele roda dois testes. O --verify do aplicativo standalone renderiza áudio offline e confirma que ele está saudável. Em um projeto compilado a partir de um checkout do SDK, a auditoria em tempo real (sonore_add_rt_test) conta cada alocação feita na thread de áudio em vários sample rates e block sizes, e falha em qualquer uma. O próprio SDK submete seus exemplos ao mesmo padrão: nove sample rates de 8 kHz a 384 kHz, block sizes de 1 a 8192, zero alocações.
3. Os validadores passam. clap-validator e pluginval carregam o plugin do jeito que os hosts fazem. Os dois templates de projeto passam neles com strictness 10 do pluginval tal como gerados, então uma falha é algo que o agente introduziu.

A auditoria e os validadores pegam o que a leitura do código não pega, e por isso devem estar no prompt.

O que ainda depende de você

Um agente com as ferramentas certas escreve um plugin que carrega, passa na validação e não aloca na thread de áudio. Ele não consegue dizer se o saturador soa bem, se a interface parece certa numa sessão, ou se um host que você se importa se comporta direito. Escuta, gosto e testes no seu DAW continuam sendo seus. Os mesmos cuidados valem para os formatos com guardiões: o AAX exige um acordo de desenvolvedor com a Avid e assinatura PACE, algo que nenhum framework pode conceder.

Para a versão passo a passo, sem agente, leia Primeiros passos. Para ver como o SDK se compara com o JUCE, o iPlug2 e os demais, veja Frameworks de plugins de áudio comparados.

Fontes

• Repositório do Sonore SDK: a seção “Writing plugins with a coding agent” do README, o llms.txt e o scripts/mcp-server.mjs
• A skill sonore-sdk
• Especificação do Model Context Protocol
• Formato Agent Skills
• Convenção llms.txt