Sonore SDK vs JUCE: a alternativa Apache-2.0 para plugins de áudio

Lado a lado

Licença e o que custa

Esta é a diferença que as equipes sentem primeiro. O JUCE tem licença dupla desde o JUCE 8: AGPLv3, ou uma EULA comercial em faixas definidas pela receita anual ou pelo financiamento.

Na prática, para uma equipe de três desenvolvedores, isso dá $1,440 por ano em assinaturas Indie quando a receita passa de $20,000. Acima de $300,000, são $6,300 por ano em assinaturas Pro, ou $10,500 de uma vez em licenças Pro perpétuas. Esses valores vêm diretamente dos preços publicados. A tela de abertura (splash screen) que o JUCE exigia foi removida com o JUCE 8, e o preço do JUCE 9 é igual ao do JUCE 8.

O Sonore SDK é Apache-2.0 sem faixas: um plugin de código fechado não custa nada em qualquer faturamento, e a concessão de patente da licença vem junto. A obrigação é manter a licença e o arquivo NOTICE junto com o que você distribui. As condições dos donos dos formatos valem igualmente para os dois frameworks: o AAX exige acordo com a Avid e assinatura da PACE, e desde o VST 3.8 (outubro de 2025) a Steinberg não exige acordo para distribuir um VST3.

Formatos e plataformas

CLAP é onde os dois mais diferem em formatos. Os roadmaps do JUCE de 2024 e 2025 previam CLAP nativo no JUCE 9, mas ele não foi incluído, então plugins JUCE obtêm CLAP por meio do clap-juce-extensions. No Sonore SDK, o CLAP é o núcleo: o wrapper CLAP controla parâmetros, estado e a ponte do editor, e VST3, Audio Units, AAX e LV2 o adaptam. Assim, um plugin não pode se comportar de forma diferente conforme o formato que o host carregou.

No desktop, ambos geram VST3, AUv2, LV2 e um aplicativo independente no Windows, macOS e Linux, e AAX no Windows e macOS. O Sonore gera todos eles, inclusive o CLAP, a partir de uma única chamada sonore_add_plugin. O código é compilado uma vez e vinculado a cada bundle, e mais uma vez, contra o SDK da Avid, para o AAX.

No iPhone, iPad e Android, ambos geram plugins e aplicativos, e no Sonore é o mesmo plugin.cpp de novo:

• AUv3. sonore_add_auv3 coloca o plugin dentro de um aplicativo como uma extensão Audio Unit, o único tipo de plugin que GarageBand, AUM, Cubasis e Logic Pro para iPad carregam, e o tipo que a Mac App Store aceita. Ele traz a árvore de parâmetros com gestos, automação com precisão de amostra, MIDI 1.0 e 2.0 de entrada e MIDI de saída, tempo e transporte, predefinições de fábrica e o mesmo estado salvo de todos os outros formatos.
• Aplicativos para iPhone e iPad. O editor roda em tela cheia na área segura, com som pelo RemoteIO e teclados MIDI pelo CoreMIDI.
• Aplicativos Android. O NDK gera um APK diretamente do CMake, sem Gradle. Ele toca via AAudio, aceita todos os teclados MIDI conectados e exibe qualquer um dos dois editores.

Como um plugin é escrito

Um plugin JUCE é uma subclasse de AudioProcessor com um processBlock, um AudioProcessorEditor e os módulos do JUCE compilados no projeto. Um plugin Sonore é um único arquivo com três partes: uma struct de DSP, uma tabela de parâmetros e um descritor.

#define SONORE_NUM_PARAMS 1
#include <sonore/dsp.h>

struct SonoreDsp {
  sonore::Smooth gain;
  void prepare(const sonore::ProcessSpec& spec) { gain.setup((float) spec.sampleRate, 20.0f); gain.snap(1.0f); }
  void process(sonore::AudioBlock<float>& io, const float* p) {
    for (size_t i = 0; i < io.getNumSamples(); ++i) {
      const float g = gain.next(sonore::dbToGain(p[0]));
      for (size_t c = 0; c < io.getNumChannels(); ++c) io.getChannelPointer(c)[i] *= g;
    }
  }
};

#include <sonore/plugin.h>
static const sonore::ParamInfo kParamTable[SONORE_NUM_PARAMS] = {{"gain", "Gain", "dB", -24.0f, 12.0f, 0.0f}};
static const sonore::PluginDescriptor kDesc = {"com.example.gain", "Gain", "Me", "1.0.0", "A gain stage.", "https://example.com", false, kParamTable, SONORE_NUM_PARAMS};
#include <sonore/formats.h>

Os parâmetros chegam como valores simples, na ordem da tabela, já em decibéis ou hertz. Comportamentos opcionais são ativados declarando um membro: latencySamples(), tailSamples(), saveState(), uma sidechain ou uma assinatura process de MIDI. Os wrappers os encontram em tempo de compilação, e um DSP que não os declara não paga nada por isso.

Vindo do JUCE, alguns nomes serão familiares: MidiBuffer, AudioBlock, uma árvore de Component para o editor nativo, MessageManager e um AudioProcessorValueTreeState sobre a tabela de parâmetros, com attachments de widgets. O SDK não é um fork e não é compatível com o código-fonte. O código de DSP migra como C++ puro, enquanto a casca do plugin é reescrita no formato acima. Se o plugin já foi lançado, planeje como os hosts vão identificar a nova build, já que cada framework deriva os IDs de plugin à sua maneira.

Interfaces

Os Components do JUCE são um toolkit maduro de modo retido, e o JUCE 8 acrescentou interfaces WebView. O Sonore SDK também tem as duas rotas, em todas as plataformas:

• Um plugin sem página recebe o editor nativo, desenhado pelo SDK na sua própria janela, sem processo de navegador. Ele define texto com kerning GPOS e shaping no estilo HarfBuzz para árabe, indiano e dezenas de outros scripts, desenha emoji coloridos e lê arte em SVG.
• Um plugin com página fornece HTML que abre no webview do sistema: WebView2, WKWebView, WebKitGTK ou o WebView do Android. Uma ponte window.sonore a conecta ao plugin, e suas edições chegam à thread de áudio por uma fila lock-free.

DSP feito para plugins

O Sonore SDK traz uma biblioteca de DSP voltada ao que os plugins realmente fazem, implementada a partir de artigos publicados:

• modelos em nível de circuito: um motor DK nodal, o Fuzz Face, o estágio de drive do TS-808;
• saturação de fita e EQ de fita;
• medição de loudness BS.1770 e de true peak;
• correção de afinação e pitch shifting por phase vocoder;
• um motor granular;
• reverbs de placa, de mola e FDN;
• dinâmica, do opto ao multibanda estilo OTT;
• blocos para sintetizadores: roubo de vozes, mono e legato com glide, modulação polifônica CLAP e uma matriz de modulação.

Agentes de código

O JUCE publica um llms.txt e um AGENTS.md, e desde setembro de 2026 seu README pede que as ferramentas de IA avisem seus usuários de que pode ser necessária uma licença comercial do JUCE. Ele não tem servidor MCP oficial.

O Sonore SDK foi construído esperando que um agente escreva grande parte do código:

• O servidor MCP responde se um nome existe e qual é a sua declaração real. A CI verifica se a busca encontra todos os 766 tipos públicos em 282 headers.
• O Agent Skill dá ao Claude Code, Codex, Cursor e Antigravity o fluxo de trabalho: gerar um projeto, consultar nomes e concluir apenas quando ctest e os validadores passarem.

Tudo isso é gerado a partir dos headers, então não pode divergir deles. Como criar um plugin com um agente de código percorre o processo passo a passo.

Quando o Sonore SDK é a melhor escolha

• Você está começando um plugin novo e quer um único arquivo-fonte que chegue aos DAWs de desktop, aos hosts de iPhone e iPad e ao Android.
• Você vende plugins de código fechado e quer custo de licença zero em qualquer faturamento.
• CLAP e LV2 importam para você, ao lado de VST3 e Audio Units.
• Um agente de código escreve grande parte do seu código, e você quer que ele confira nomes em vez de inventá-los.
• Você quer um build header-only: um plugin.cpp, CMake e nenhum runtime de framework no binário.

Quando o JUCE ainda faz sentido

• Você tem uma base de código JUCE que funciona, e nem a licença nem o CLAP estão pressionando você a migrar.
• Sua equipe já conhece o JUCE e depende do grande volume de exemplos e respostas de fóruns.

Para o panorama mais amplo, com iPlug2, DPF e os frameworks em Rust, veja Frameworks de plugins de áudio comparados.

Fontes

• JUCE: licença, EULA do JUCE 9, preços, mudanças na EULA do JUCE 8, cobertura do lançamento do JUCE 9, releases, README, API do CMake, roadmap, 3º trimestre de 2025, AGENTS.md
• CLAP para JUCE: clap-juce-extensions
• Licenciamento do VST3: anúncio do VST 3.8, SDK do VST3
• Sonore SDK: repositório, primeiros passos, plataformas e formatos, o editor nativo, o editor web