Surge XT: a GPL-3.0 hybrid synthesizer you build with CMake

What Surge XT is, and who the repository is written for

Surge XT began as Surge, a commercial hybrid synthesizer written and sold by Claes Johanson at Vember Audio. In September 2018 he released a partially completed version of Surge 1.6 under GPL3, and a group of developers has been improving it since. The README is explicit that it serves as the root of developer documentation, and that musicians looking to use the synth should download a binary from the project website rather than build it. That split matters. The repository is not trying to be an end-user distribution channel; it is the source tree, the build system and the developer guide. The people it is for are plugin developers, contributors who want to work on the DSP or the UI, and technically inclined users who want a GPL-3.0 synthesizer they can compile themselves. The topics listed on the repository are audio-units, synthesizer and vst3, which matches the plugin formats the build produces. The last push to the default branch was on 2026-09-18, and the repository is not archived.

How the build is structured: CMake, submodules and staged assets

Surge XT uses CMake for all build-related tasks. The README states that the code depends on submodules, so the clone step is followed by git submodule update --init --recursive before any configure step. The repository layout backs this up: there is a .gitmodules file at the top level, alongside cmake/, libs/, resources/, scripts/ and src/. The documented workflow is a two-step CMake configure and build, and the default target mentioned is surge-staged-assets, which the README says produces all the Surge XT binary assets in build/surge_xt_products. For developers who only want the VST3, the README gives a narrower target, surge-xt_VST3. There is also a separate path for building a VST2, which requires a local copy of the VST2 SDK pointed to by the VST2SDK_DIR environment variable, and a Python bindings path that uses pybind to expose the synth internals to Python. The README names the surge-python repository as the place where uses of those bindings are shown. One structural detail worth noting: the README mentions that Surge XT 1.3 family moved to JUCE 7, which is what brings LV2 support into the build, but LV2 is not built by default and not built in CI, so it has to be turned on deliberately.

Building Surge XT from source: install and first build

The README assumes a development environment is already set up and points to platform sections for Windows, macOS and Linux if it is not. The commands below are the ones the README gives as a reliable formula across platforms. Clone the repository, pull the submodules, configure a Release build into a build directory, then build the staged assets target.

git clone https://github.com/surge-synthesizer/surge.git
cd surge
git submodule update --init --recursive
cmake -Bbuild -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release --target surge-staged-assets

After the build finishes, the README says the binary assets are in build/surge_xt_products. If you only want the VST3 rather than the full set of assets, the README offers this substitution for the final command.

cmake --build build --config Release --target surge-xt_VST3

If you are working from a fork, the README says to fork the project on GitHub and clone your fork instead of the main repository, and that the remaining steps are unchanged. The README does not document how to install the built plugin into a host, so treat the build output directory as the endpoint and consult your host's plugin path conventions separately.

Optional build paths: VST2, LV2, ASIO and Python bindings

Three optional paths are documented, and each has a different cost. The VST2 path requires you to obtain a local copy of the VST2 SDK and set VST2SDK_DIR to that folder before configuring a fresh build directory. The README gives both an export form for Unix-like shells and a set form for the Windows command prompt, then builds the surge-xt_VST and surge-fx_VST targets into build_vst2/surge-xt_artefacts/Release/VST and build_vst2/surge-fx_artefacts/Release/VST. The README states plainly that VST2 builds may not be redistributed due to licensing restrictions, and that they are possible only for personal use. The LV2 path is a single CMake flag, -DSURGE_BUILD_LV2=TRUE, added on the initial configure. The README explains that LV2 is not built by default or in CI for a variety of reasons, which is a signal that this path gets less exercise than the default targets. ASIO support on Windows is described as available out of the box, with the README crediting Steinberg for adding GPL3 as a licensing option, so no special build procedure is needed there. The Python bindings are the most involved: configure with -DSURGE_BUILD_PYTHON_BINDINGS=ON into a directory of your choosing, build the surgepy target, and look for a .so file on macOS and Linux or a .pyd file on Windows. The README's example output shows a file named surgepy.cpython-311-darwin.so, which tells you the extension is tied to the CPython version you build against.

Where the documentation is thin, and the VST2 redistribution limit

The largest limitation is not technical. The README is a developer document, and it does not cover installation for end users at all; it redirects musicians to the website binaries. If you came to the repository expecting a step-by-step setup guide for your DAW, the README will not give you one. The second real constraint is the VST2 licensing position. Even though the README explains how to build a VST2 for personal use, it states that such builds may not be redistributed. That rules out shipping a VST2 build of Surge XT in a product or handing one to other people, regardless of how straightforward the build is. A third gap is the LV2 path: it is documented as a flag and an explanation for why it is off by default, but the README does not describe testing or support expectations for it, and the fact that it is excluded from CI means regressions there would not be caught by the pipeline the README links to. Finally, the recent releases list shows a Nightly build dated 2024-08-07, which is not a stable version number; the README and the release list do not give a versioned stable release, so pinning to a specific tagged version is something you would have to confirm elsewhere.

How Surge XT differs from other open source synthesizers

The closest comparison is not another synthesizer but the history of this one. Surge XT is a commercial hybrid synth that was open sourced partway through development, and the README is candid that the released version was partially completed. That origin shapes the project: it already had a sound engine, a preset format and a user base before the GPL3 release, and the work since 2018 has been improvement rather than a from-scratch rewrite. Compared with a synthesizer that starts life as an open source project, Surge XT carries the expectations of a paid product, including a developer guide, a Discord server for design and testing discussions, and a documented workflow around GitHub issues. The trade-off is that the codebase reflects decisions made for a commercial product, and the build system reflects that too: submodules, a staged assets target, and separate optional paths for VST2, LV2 and Python bindings. If you want a small, single-binary synth you can read in an afternoon, this is not that. If you want an instrument with a long history and an ongoing development process, the last push on 2026-09-18 suggests the work continues.

Licence and upgrade cost

Surge XT is released under GPL-3.0. The practical consequence is that the source is available and you can build and modify it, but if you distribute a modified version you are working within the terms of that licence, which is a question for your own legal review rather than something this article can settle. The VST2 situation is the clearest licence implication in the README: the VST2 SDK is not covered by the same terms, which is why the README says VST2 builds may not be redistributed. The ASIO situation is the opposite, with the README noting that Steinberg's licensing now includes GPL3 as an option, which is why ASIO support needs no special procedure. On upgrade cost, the repository does not describe a migration or upgrade process, and the release list shows only a Nightly build, so there is no documented stable upgrade path to follow. The build itself is the upgrade mechanism: pull the latest main branch, update submodules, reconfigure and rebuild. That is cheap if your environment is already set up and expensive if it is not, which is the same trade-off the README makes when it tells musicians to use the website binaries.

Editorial conclusion

Adopt Surge XT if you want a GPL-3.0 hybrid synth you can build from source, or if you are a developer who wants to script the engine through the Python bindings. Do not adopt it if you need a redistributable VST2 build, since the README states VST2 builds may not be redistributed due to licensing restrictions, or if you expect the README to walk you through installation as an end user; it points musicians to the website binaries instead. Before committing, verify that your toolchain produces the surge-staged-assets target on your platform, and check whether the LV2 path, which requires -DSURGE_BUILD_LV2=TRUE and is not built by default or in CI, matters for your host.

Frequently asked questions

Official sources

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