Sonore SDK vs JUCE: the Apache-2.0 alternative for audio plugins

Side by side

Licence and what it costs

This is the difference most teams feel first. JUCE has been dual-licensed since JUCE 8: AGPLv3, or a commercial EULA in tiers set by annual revenue or funding.

In practice, for a team of three developers, that works out to $1,440 a year on Indie subscriptions once revenue passes $20,000. Above $300,000 it is $6,300 a year on Pro subscriptions, or $10,500 once for perpetual Pro licences. Those figures come straight from the published prices. The splash screen JUCE used to require went away with JUCE 8, and JUCE 9 pricing is the same as JUCE 8’s.

The Sonore SDK is Apache-2.0 with no tiers: a closed-source plugin costs nothing at any revenue, and the licence’s patent grant comes with it. The obligation is to keep the licence and NOTICE file with what you distribute. Format owners’ terms apply to both frameworks equally: AAX needs Avid’s agreement and PACE signing, and since VST 3.8 (October 2025) Steinberg no longer asks for an agreement to distribute a VST3.

Formats and platforms

CLAP is where the two differ most on formats. JUCE’s roadmaps in 2024 and 2025 put native CLAP in JUCE 9, but it did not ship there, so JUCE plugins get CLAP from clap-juce-extensions. In the Sonore SDK, CLAP is the core: the CLAP wrapper owns parameters, state and the editor bridge, and VST3, Audio Units, AAX and LV2 adapt it. A plugin therefore cannot behave differently depending on which format a host loaded.

On the desktop, both build VST3, AUv2, LV2 and a standalone app on Windows, macOS and Linux, and AAX on Windows and macOS. Sonore builds all of them, CLAP included, from one sonore_add_plugin call. The source is compiled once and linked into every bundle, and once more, against Avid’s SDK, for the AAX.

On iPhone, iPad and Android, both build plugins and apps, and in Sonore it is the same plugin.cpp again:

• AUv3. sonore_add_auv3 puts the plugin inside an app as an Audio Unit extension, the only kind of plugin GarageBand, AUM, Cubasis and Logic Pro for iPad load, and the kind the Mac App Store accepts. It carries the parameter tree with gestures, sample-accurate automation, MIDI 1.0 and 2.0 in and MIDI out, tempo and transport, factory presets, and the same saved state as every other format.
• iPhone and iPad apps. The editor runs full screen in the safe area, with sound through RemoteIO and MIDI keyboards through CoreMIDI.
• Android apps. The NDK builds an APK straight from CMake, with no Gradle. It plays through AAudio, takes every MIDI keyboard plugged in, and shows either editor.

How a plugin is written

A JUCE plugin is an AudioProcessor subclass with a processBlock, an AudioProcessorEditor, and the JUCE modules compiled into the project. A Sonore plugin is one file with three parts: a DSP struct, a parameter table and a descriptor.

#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>

Parameters arrive as plain values in the table’s order, already in decibels or hertz. Optional behaviour is opt-in by declaring a member: latencySamples(), tailSamples(), saveState(), a sidechain or MIDI process signature. The wrappers find it at compile time, and a DSP that does not declare it pays nothing.

Coming from JUCE, some names will be familiar: MidiBuffer, AudioBlock, a Component tree for the native editor, MessageManager, and an AudioProcessorValueTreeState over the parameter table with widget attachments. The SDK is not a fork and is not source-compatible. DSP code moves across as plain C++, while the plugin’s shell is rewritten in the shape above. If the plugin has already shipped, plan for how hosts will identify the new build, since each framework derives plugin IDs in its own way.

Interfaces

JUCE’s Components are a mature retained-mode toolkit, and JUCE 8 added WebView interfaces. The Sonore SDK has both routes too, on every platform:

• A plugin without a page gets the native editor, drawn by the SDK in its own window with no browser process. It sets text with GPOS kerning and HarfBuzz-style shaping for Arabic, Indic and dozens of other scripts, draws colour emoji, and reads SVG art.
• A plugin with a page supplies HTML that opens in the OS webview: WebView2, WKWebView, WebKitGTK or Android’s WebView. A window.sonore bridge connects it to the plugin, and its edits reach the audio thread through a lock-free queue.

DSP built for plugins

The Sonore SDK ships a DSP library aimed at what plugins actually do, implemented from published papers:

• circuit-level models: a nodal DK engine, the Fuzz Face, the TS-808 drive stage;
• tape saturation and tape EQ;
• BS.1770 loudness and true-peak metering;
• pitch correction and phase-vocoder pitch shifting;
• a granular engine;
• plate, spring and FDN reverbs;
• dynamics from opto to OTT-style multiband;
• synth building blocks: voice stealing, mono and legato with glide, CLAP polyphonic modulation and a mod matrix.

Coding agents

JUCE publishes an llms.txt and an AGENTS.md, and since September 2026 its README asks AI tools to tell their users that a commercial JUCE licence may be required. It has no official MCP server.

The Sonore SDK was built expecting an agent to write much of the code:

• The MCP server answers whether a name exists and what its real declaration is. CI checks that its search finds all 766 public types in 282 headers.
• The Agent Skill gives Claude Code, Codex, Cursor and Antigravity the workflow: generate a project, look names up, and finish only when ctest and the validators pass.

All of it is generated from the headers, so it cannot drift from them. How to build a plugin with a coding agent walks through it.

When the Sonore SDK is the better choice

• You are starting a new plugin and want one source file to reach desktop DAWs, iPhone and iPad hosts and Android.
• You sell closed-source plugins and want no licence cost at any revenue.
• CLAP and LV2 matter to you next to VST3 and Audio Units.
• A coding agent writes much of your code, and you want it to check names instead of inventing them.
• You want a header-only build: one plugin.cpp, CMake, and no framework runtime in the binary.

When JUCE still makes sense

• You have a JUCE codebase that works, and neither the licence nor CLAP is pushing you to move.
• Your team already knows JUCE and leans on its large pool of examples and forum answers.

For the wider field, with iPlug2, DPF and the Rust frameworks, see Audio plugin frameworks compared.

Sources

• JUCE: licence, JUCE 9 EULA, pricing, JUCE 8 EULA changes, JUCE 9 release coverage, releases, README, CMake API, roadmap, Q3 2025, AGENTS.md
• CLAP for JUCE: clap-juce-extensions
• VST3 licensing: VST 3.8 announcement, VST3 SDK
• Sonore SDK: repository, getting started, platforms and formats, the native editor, the web editor