Gearmulator: ROM-Based Emulation for Classic VA Synths

What Gearmulator Preserves by Running Original Firmware

Gearmulator addresses a specific compatibility problem: reproducing the operation of classic hardware synthesizers and effects whose sound depends on their original code and signal processor. Rather than describing each instrument only through a collection of synthesis macros and effects, the project runs the original firmware, called the ROM, against emulated versions of the integrated circuits used by the device. That architecture is significant because the executable code participating in audio generation is not a new implementation written for a modern plugin host.

The intended users are musicians seeking access to supported vintage models and engineers interested in low-level emulation of DSP56300-era hardware. Supported families include Access Virus A, B and C; Virus TI, TI2 and Snow; Waldorf microQ; Waldorf Microwave II and XT; Nord Lead and Rack 2x; Roland JP-8000; Roland MT-32 variants; CM-32L, CM-32P and CM-64; MV-30; and the listed Sound Canvas models.

This approach carries an obvious dependency. Gearmulator needs original firmware to execute. The README does not say how ROM acquisition, validation, packaging, or licensing works, so those details must not be inferred from the plugin list. A user interested in a supported model still has to establish that compatible ROM files are available for their own use before the project can reproduce that instrument.

The Emulated Chip, Firmware, and Host Plugin Chain

The visible architecture has three layers. First, Gearmulator emulates the ICs used by each supported musical device. Second, that emulated hardware executes the instrument's original ROM rather than relying solely on a modern software model of the synthesizer. Third, the result is exposed through an audio plugin that can communicate parameters and audio with a compatible host.

The repository names components such as `DSPBridge`, described in the CMake options as the DSPBridge server and the device plugins it loads. This indicates a separate server and plugin-loading path, but the README does not explain the process boundary, communication protocol, audio layout, real-time execution model, or device emulation sequence. Those implementation details would require reading the source before they can be used to design a deployment.

The host-facing formats are unusually broad for a project with this scope. Gearmulator documents FST, VST3, AU, CLAP, and LV2 support. On 64-bit x86 and ARM aarch64, including Raspberry Pi and Apple Silicon hardware, this creates coverage across Windows, macOS, and Linux workflows. JUCE supplies the base plugin targets, while separate CMake switches control CLAP and LV2 generation. The repository is not limited to a single plugin standard, but it is limited to 64-bit targets because 32-bit architectures are explicitly unsupported.

Supported Instruments and Important Scope Boundaries

Coverage is organized by emulated product family, and each target has a distinct internal project name. `Osirus` covers the Access Virus A, B, and C. `OsTIrus` covers Virus TI, TI2, and Snow. `Vavra` maps to Waldorf microQ, while `Xenia` covers Microwave II and XT.

Other targets follow the same pattern. `Nodal Red 2x` covers the Clavia Nord Lead and Rack 2x. `JE-8086` represents the Roland JP-8000. The broad `88emu` target handles both MT-32 boards, CM-32L, CM-32P, CM-64, MV-30, and Sound Canvas variants such as SC-55, SC-88, SC-88pro, SC-8820, and SC-8850.

This is a curated emulation project, not a catalog of every synthesizer architecture from the period. No broad set of additional instruments can be claimed from the README. Likewise, Gearmulator's platform support does not mean that every host on those operating systems can load every format. The plugin format determines host compatibility, while the target architecture and operating system determine which binary can run.

The FX option also needs careful interpretation. `gearmulator_BUILD_FX_PLUGIN` additionally builds FX versions of all plugins and defaults to `off`. The README does not identify the routing, signal flow, or preset differences of those FX builds, so they should not be treated as evidence that every historical effect algorithm is separately modeled. The stated mechanism remains firmware execution on emulated hardware.

Building Gearmulator with CMake

Gearmulator requires a C++17 compiler and CMake. The README names CMake as the build system but does not give a complete command sequence for fetching submodules, configuring a build directory, compiling, or installing plugins. The repository includes platform scripts such as `build_linux.sh`, `build_linux_console.sh`, `build_mac.sh`, `build_win64.bat`, and `build_win64_vs19.bat`, but their contents are not documented here, so their exact commands cannot safely be reproduced.

A first build should therefore begin with the repository's own platform script or its documented CI configuration, rather than an invented command line. The project uses `CMakePresets.json` and has CMake-based workflows, which indicates preset-driven builds are part of the repository structure. The README does not state which presets are required for each operating system.

The principal configuration decision is which targets to compile. All listed synth options and `gearmulator_COMPONENT_DSPBRIDGE` default to `on`, while the general JUCE plugin, CLAP, and LV2 targets also default to `on`. Turning devices off can reduce the build scope, but the README does not quantify build time or binary size, so it would be speculation to promise a meaningful saving. FX plugins are excluded unless `gearmulator_BUILD_FX_PLUGIN` is changed from `off`.

Installing a Built Plugin for the First Session

The README confirms plugin support for FST, VST3, AU, CLAP, and LV2, but it does not document a universal installation procedure. Plugin discovery differs by format and platform, and none of the host paths or copy commands are specified in the available documentation. Consequently, there is no verified one-command installation step to give here.

For a first real use, the sequence is still concrete at the project level. Select the CMake targets for the required device, build the intended plugin formats, install or expose the resulting binaries to a compatible host, and load the plugin corresponding to the supported instrument. The host must then be able to provide the original ROM for that device. The README does not say whether ROM selection happens through a plugin dialog, preset-loading stage, configuration file, or another interface.

Audio processing can only be evaluated after that chain is complete. The README does not document default presets, initialization steps, sample-rate constraints, MIDI behavior, parameter mappings, or known-good test patches. It also gives no official package or binary download instruction. Users who need turnkey installation with predefined factory sounds should treat the absence of those details as an adoption constraint, not assume that building the repository produces a complete instrument bundle.

Platform, License, and Maintenance Boundaries

Gearmulator supports Windows 7 and later, macOS 10.13 and later, and Linux on 64-bit x86 or ARM aarch64. Raspberry Pi and Apple Silicon are called out as ARM targets. Explicit rejection of 32-bit systems is important for plugin hosts or older computers where that architecture remains common.

The project is licensed under GPL-3.0. That matters for developers considering modifications or distribution because it carries reciprocal licensing conditions for covered software. This is not legal advice, and the README does not separately state licensing terms for original instrument ROMs, which may be governed by rights outside the source repository.

The repository is not archived, and its last push was on 2026-10-16. Release history also lists version 2.2.25 on 2026-09-20, version 2.2.16 on 2026-09-04, and version 2.2.9 on 2026-07-29. These dates show recent code and release activity, but upgrade cost cannot be estimated from them alone. The README does not document release notes, migration procedures, ABI stability, or compatibility between successive versions.

Why Gearmulator Differs from a Conventional Synthesiser

A conventional software synthesiser usually implements synthesis and effects using code written specifically for the host platform, with instrument behavior exposed through a documented parameter model. Gearmulator takes a different route: it recreates the chips used by historical hardware and runs the device's original firmware on them. The resulting software plugin is an emulation environment rather than a conventional reimplementation of every synthesis algorithm.

That distinction can make Gearmulator relevant when firmware behavior itself is the goal. It also creates boundaries that ordinary plug-in synths do not have. Compatible ROMs are required, software legality depends partly on files not distributed by this repository, and successful loading depends on the emulated hardware interacting with original firmware. Without those firmware files, the plugin target cannot become the intended instrument merely by loading the binary.

Gearmulator is also the wrong choice for a host that requires 32-bit plugins or for a musician seeking an immediately downloadable, factory-sound package. Its broad device list does not imply universal hardware coverage. The most defensible use case is narrow but clear: reproduce or study one of the explicitly supported instruments through its own firmware, with the user accepting the ROM and host-integration constraints that follow.

Editorial conclusion

Musicians should consider Gearmulator when they specifically need one of the listed device models and have access to the required ROM files. Software developers may prefer building it when they need to study or integrate its chip and firmware emulation layer. Buyers without compatible ROMs, users seeking 32-bit support, and projects expecting a conventional parameter-driven synthesiser should look elsewhere. The first verification is whether the intended instrument and firmware are supported and can legally be supplied by the user.

Frequently asked questions

Official sources

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