SPARTA packages ambisonic encoding, decoding and analysis as audio plug-ins

A suite of spatial audio plug-ins rather than one algorithm

SPARTA is a collection of open-source VST, VST3, AU, LV2 and AAX audio plug-ins for the production and playback of spatial sound scenes, developed using JUCE and the Spatial_Audio_Framework. The wording collection is doing real work here. This is not a single decoder or a single panner with a different name, it is a suite covering the whole ambisonic signal chain: capture from microphone arrays, encoding from mono sources, rotation and binaural rendering, loudspeaker decoding, room simulation, and analysis tools that show you what the scene actually contains. The intended user is an audio engineer working in a DAW with a multichannel workflow, either producing immersive content for loudspeaker arrays or headphones, or researching spatial audio, since several of the plug-ins are explicitly diagnostic rather than creative. The project cites its own design paper in the 2019 AES International Conference on Immersive and Interactive Audio, and the project site is leomccormack.github.io/sparta-site. Pre-built plug-ins are published as release assets for MacOS 12.0 or higher, Linux x86_64 and Windows x86_64, so evaluation does not require a compiler.

Encoding, panning and room simulation in the ambisonic domain

The encoder family is where a scene is created. AmbiENC is an Ambisonic encoder and panner up to 10th order with support for up to 128 input channels, and the directions may be imported via JSON configuration files. AmbiRoomSim is an encoder that also includes room reflections based on the image-source method using a shoebox room model, with multiple sources and multiple receivers supported up to 128 channels, for example 32 first order, 8 third order or 2 seventh order receivers. AmbiDRC is a frequency-dependent dynamic range compressor for ambisonic signals up to 10th order, which exists because compressing a first order field and a seventh order field with the same gain reduction is not the same operation. On the output side, the Panner is a frequency-dependent 3-D panner using the VBAP method with up to 128 inputs and outputs, the Rotator is a flexible Ambisonic rotator with head-tracking support via OSC messages, and the Spreader is an arbitrary array encoder for things like HRIRs or microphone array IRs with coherent and incoherent spreading modes. Together these cover the path from mono or multichannel sources into a sound field, including a physical room.

Two decoders: SOFA binaural rendering and configurable loudspeaker arrays

Playback splits into two plug-ins with very different requirements. AmbiBIN is a binaural Ambisonic decoder up to 10th order with a built-in SOFA loader and head-tracking support via OSC messages, and it offers Least-Squares, spatial re-sampling, time-alignment and magnitude least-squares decoding options, so you can choose how the ambisonic field is compressed into two ears. AmbiDEC is a frequency-dependent loudspeaker Ambisonic decoder up to 10th order with user specifiable loudspeaker directions, up to 128 of them, which may optionally be imported via JSON configuration files. AmbiDEC offers All-Round, Energy-Preserving, Spatial and Mode-Matching decoding options, and the loudspeaker signals may also be binauralised for headphone playback. The presence of a SOFA loader in the binaural path and a JSON speaker layout in the loudspeaker path reflects the reality that the interesting content is the configuration file: the decoder is generic, the layout is the artwork. The Binauraliser and BinauraliserNF are separate plug-ins for binaural panning of ordinary sources, with the NF variant adding proximity filtering for near field sound sources.

Analysis plug-ins show what the field contains

Three plug-ins are analysis and visualisation tools rather than processors, and they are the most unusual part of the suite. PowerMap is a sound-field visualisation plug-in based on Ambisonic signals as input up to 10th order, with PWD, MVDR, MUSIC and Min-Norm options, so you can compare how the different localisation estimators place energy in direction. SLDoA is a frequency-dependent sound-field visualiser that depicts direction-of-arrival estimates derived from spatially localised active-intensity vectors, with low frequency estimates shown in blue icons, mid frequencies in green and high frequencies in red, which makes the band dependent behaviour of the estimator visible at a glance. DirASS is a sound-field visualiser based on re-assigning the energy of beamformers, with the re-assignment based on DoA estimates extracted from spatially-constrained regions centred around each beamformer look-direction. The Beamformer plug-in works in the spherical harmonic domain with multiple beamforming strategies and up to 128 output beams, Array2SH encodes a microphone array up to 10th order with presets for several commercially available A-format and higher-order arrays, and TrackerTest outputs incoming headtracker data as audio signals so you can confirm that a head tracker is actually talking to the plug-ins.

Convolution tools, including time varying rendering from SOFA

The convolution group covers three different needs. MatrixConv is a basic matrix convolver with an optional partitioned convolution mode, where the user specifies the number of inputs and loads the filters via a wav file. MultiConv is a basic multi-channel convolver that performs no matrixing, so each input channel is convolved with the respective filter and numInputs equals numFilters equals numOutputs. 6DoFconv is the interesting one: a time-varying partitioned convolution multi-channel convolver for SOFA files containing RIRs with multiple listener positions, which is what makes a moving listener work with a measured room impulse response set rather than a single static HRIR. MatrixConv and MultiConv both use optional partitioned convolution, so long filters can run with a delay cost rather than a large memory cost. A PitchShifter, described as a very basic multi-channel pitch shifter based on the phase-vocoder approach, is also present, which tells you something about the balance of the suite: the signal processing tools that matter for spatial work are deep, while the utility processors are deliberately minimal.

Building requires JUCE, oneAPI or OpenBLAS, and a CMake pass

Building the suite yourself starts with a recursive clone, because the framework and JUCE arrive as submodules:

git clone --recursive https://github.com/leomccormack/SPARTA
# or if you have already cloned the repository, update/init with:
git submodule update --init --recursive

The dependency story differs by platform. All of the major audio plugin SDKs are bundled inside of JUCE, with the exception of VST2, so to build VST2 versions the VST2_SDK must be placed in the SDKs folder as SDKs/VST2_SDK. MacOS users require no other additional dependencies. Linux and Windows x86_64 users need Intel oneAPI with MKL and IPP and must run the install-safmkl.sh/.bat and install-safipp.sh/.bat scripts in SDKs/Spatial_Audio_Framework/scripts, while Raspberry Pi ARM users instead require OpenBLAS and LAPACKE:

sudo apt-get install liblapack3 liblapack-dev libopenblas-base libopenblas-dev liblapacke-dev

Linux users also need the JUCE dependencies:

sudo apt-get install x11proto-xinerama-dev libwebkit2gtk-4.0-dev libgtk-3-dev x11proto-xext-dev libcurl4-openssl-dev libasound2-dev

The build itself is CMake, version 3.15 or higher, and the recommended path is:

mkdir build
cmake -S . -B build
cd build
make

Visual Studio 2022 users can enable the extra plug-in formats at configure time, and the README also documents a Projucer based route that is marked deprecated.

GPL-3.0, a beta in the release list, and a last push in April

Two housekeeping points. The licence is GPL-3.0, which is the constraint to weigh before shipping a plug-in built from this code inside a commercial product or a closed platform, and it is the main reason the framework and plug-in code sit in separate but tightly coupled repositories. Second, the release history shows a mixture of stability signals. The tagged versions are v1.8.2 on 2026-01-25, v1.8.1 on 2025-10-04 and v1.8.0, labelled as a beta, on 2025-07-13, so the 1.8 line shipped a beta followed by two point releases, which is the shape of a project that is stabilising an API rather than one that has frozen. The last push to the repository was on 2026-04-10, which is more than six months before now, so treat the tree as quiet rather than actively developed and check that the release you install contains the plug-ins you need. For a research and tooling suite that is still the right trade: the algorithms are documented in papers, the plug-in list is broad, and the pre-built packages let you work without touching the build toolchain at all.

Editorial conclusion

Adopt SPARTA if you produce or reproduce ambisonic audio and want ready made plug-ins for encoding, binaural and loudspeaker decoding, room simulation and sound field analysis rather than writing DSP hosts yourself. Do not adopt it if you need a single purpose tool with a minimal dependency footprint, since the suite is large and pulls in JUCE, the framework and on Linux and Windows the Intel oneAPI libraries. Verify first that the platform requirements are met, including Intel MKL and IPP on Linux and Windows and OpenBLAS with LAPACKE on Raspberry Pi, that the plug-in formats you need are produced by your build, and that the GPL-3.0 terms are acceptable for the distribution you plan.

Frequently asked questions

Official sources

1. leomccormack/SPARTA on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases