OB-Xf carries the OB-Xd open source synthesiser forward on Surge's infrastructure

A continuation, not a fork that stopped

OB-Xf is a continuation and modernisation of the last open source release of OB-Xd by 2DaT and later discoDSP, and it is inspired by the venerable Oberheim OB-X.

The lineage matters here, because the situation with OB-Xd was specific. 2DaT wrote the original, discoDSP continued it, and at some point the open source release stopped moving while the closed source version carried on. OB-Xf picks up from that last open source point and keeps going, which is what makes it a continuation rather than a new synthesiser with a similar name.

The second half of the description is the interesting part. The project brings together several efforts going on in the audio space and combines them inside the Surge Synth Team infrastructure. That means the build system, the plugin formats, the asset pipeline and the release process come from the Surge synthesiser project rather than being invented here, and the main repository points at Surge for the broader context.

The project is explicit about its maturity. The synth is currently in a beta phase, with a few features still under development, but the plugin is feature stable and working rather well, as the README puts it. So the split to hold in mind is between the plugin, which is usable, and the surrounding feature set, which is still moving.

Installers for every desktop platform, and the nightly channel

Installation is handled with prebuilt installers rather than a build, and the format list is worth reading: a signed DMG for macOS, an EXE for Windows on x64, ARM64 and ARM64EC, and a DEB for Linux x86_64 built on Ubuntu 20. The link points at the Nightly release page, and the README says to see that page for the installation instructions.

A nightly build being the primary download is a deliberate choice for a project in a beta phase. It means the installer carries the most recent work rather than the most recent tag, and it means the release tags and the nightly are two different lines you choose between.

The release list shows both. There is a Nightly tag dated 2025-06-08, and then v1.0.3 from 2026-03-27 and v1.0.2 from 2026-03-26, two version tags a day apart. The ordering is a little confusing, because the nightly entry carries an earlier date than the version releases while the repository itself was pushed to on 2026-10-16.

For a user, the practical question is which channel to run. The nightly is where new features land first and where regressions also land first, and the version tags are the more conservative choice for a working setup.

OB-Xd patches and banks import, with one pitch caveat

The compatibility story is the part that matters most for anyone moving from OB-Xd, and the README is unusually precise about it.

Patches and banks created by OB-Xd are compatible with OB-Xf, using the Import OB-Xd Bank option in the patch browser, or by simply drag-and-dropping OB-Xd FXP and FXB files onto the interface. That functionality was introduced in the v1.1 update, which is worth knowing if you are comparing versions.

The caveat is the tuning reference. Fidelity of conversion is retained in all cases except one, because OB-Xd has an offset of 12 semitones when all coarse tuning controls are set to 0 semitones, so middle C produces roughly 464 Hz instead of the expected 232 Hz. OB-Xf has fixed this reference pitch, and compensates for the discrepancy by increasing the Transpose parameter by 12 semitones.

From there the behaviour branches, and the branches are the part to read carefully. If the Transpose parameter was already at its maximum, both oscillators are pitched up by 12 semitones. And if either of the oscillator pitch controls does not allow for an increase of 12 semitones, the imported patch will sound one octave lower than it did in OB-Xd.

That is a genuinely useful level of detail. A user who does not know about the reference pitch difference will hear an imported patch as broken rather than as transposed, and the branch conditions tell you which imported patches to check first.

The CMake build, the staged target and the assets

Building from source uses CMake, and the sequence is three commands:

git submodule update --init --recursive
cmake -B Builds/Release -DCMAKE_BUILD_TYPE=Release .
cmake --build Builds/Release --config Release --target obxf-staged

The submodule step comes first because the project pulls in its dependencies that way, and the target name is the interesting part. Building obxf-staged builds the supported plugin formats and places them in builds/Release/obxf_products.

The asset step is the thing to know. If you self-build, you are responsible for installing the assets from assets/installer in the appropriate location. The README adds a helpful detail: when you run the plugin or the standalone, it will show you where OB-Xf attempted to look for the assets, if you get it wrong. So a silent-looking failure is diagnosable from the application's own output rather than from a log file you have to find.

On a unix system there is a convenience for the factory assets after a build:

cmake --install Builds/Release

and this may need sudo, and it uses the CMAKE_INSTALL_PREFIX for the shared location.

iOS support that is deliberately self-build only

iOS support is being added incrementally, and the reasoning behind the way it is distributed is the most interesting part of the README.

The initial CMake wiring enables iOS-safe formats, AUv3 and Standalone, and disables desktop-only packaging steps. The current setup targets iPad, with TARGETED_DEVICE_FAMILY=2. A starting point for generating an Xcode project is:

cmake -B Builds/iOS -G Xcode -DCMAKE_SYSTEM_NAME=iOS -DOBXF_IOS_DISABLE_CODESIGN=ON .
cmake --build Builds/iOS --config Release

The no-signing default is there so the build works without a team. If you want to sign for device install, you set your team ID and turn the no-signing default off:

cmake -B Builds/iOS -G Xcode -DCMAKE_SYSTEM_NAME=iOS -DOBXF_IOS_DISABLE_CODESIGN=OFF -DOBXF_IOS_DEVELOPMENT_TEAM=YOURTEAMID .

The distribution decision is the real story. OB-Xf is GPLv3 software, and the project does not distribute an iOS build through Apple's App Store because Apple and the FSF disagree on whether App Store distribution is compatible with GPLv3 terms. As a result, iOS support is self-build only.

Packaging and asset installation for iOS are not complete yet, so the iOS path is a work in progress in both senses.

What the project promises, and what it does not

The copyright statement is worth quoting in substance, because it sets the tone of the whole project. This repository and the source code is under GPL3 licence, and OB-Xf is and always will be free in all contexts and for all uses, with the source code available and modifiable, and the software usable in any context, free or commercial.

That last clause is the one that matters for adoption. A synth plugin that is free in commercial contexts is usable in a commercial product, and a lot of instrument projects are not, so this is a real differentiator rather than a statement of intent.

The honesty is equally notable. The project calls itself a beta, says the plugin is feature stable and working rather well, points at a Trello-style board of remaining work in the wider project, and says plainly that iOS packaging is not complete. There is no claim of stability the README does not back up.

The primary language is C++, and the repository layout is a plugin project: a src directory, a libs directory, a resources directory, an assets directory, a cmake directory, a scripts directory, and the .clang-format and .clang-tidy configuration files at the root. The asset installer lives in assets/installer, which is the path you need if you are building rather than installing.

Where OB-Xf is the wrong choice

The first limit is the maturity, and the project says so. A beta phase with features still under development means the plugin works and the feature set moves, so if you need a stable, supported instrument for a release you are producing, this is a risk you take on purpose rather than by default.

The second is the iOS distribution, and it is absolute. There is no App Store build and there will not be one, because of the GPL position the project states. If your workflow is on iPad and you need a signed build, you are self-building with an Xcode project and a team ID, with packaging and asset installation still unfinished.

The third is the channel. The primary download is a nightly, which means the binary you install is the most recent build rather than the most recent tag, and a project that ships nightly as its main channel will move under you.

The fourth is the OB-Xd import caveat, which is a real edge case rather than a general failure, but an edge case in patches you already own. A patch whose Transpose was maxed out, or whose oscillator pitch controls cannot absorb 12 semitones, comes in wrong, and there is no automatic fix.

The fifth is that this is a synthesiser, not a general audio tool. If what you want is a plugin that does something no Oberheim-style instrument did, this is the wrong project, and if you want a service rather than an instrument, there is nothing here for that either.

Editorial conclusion

OB-Xf fits a musician or developer who wants the OB-Xd sound and patch set, and who wants a project that is still moving rather than frozen at the last open source release. It is the wrong tool if you need the App Store or a signed iOS build, since the project deliberately does not distribute one because of the GPL and App Store incompatibility, and it is the wrong tool if you want a stable release, since the project describes itself as being in a beta phase. Before you build or install it, check three things: that your existing OB-Xd patches and banks import without the tuning shift, since the 12 semitone reference pitch difference is handled by the import path and can leave a patch an octave low in one case, that you pick the right build target, because the CMake build produces several plugin formats, and that you read the asset installation step, because a self-built binary does not install the factory content for you. The code is GPL-3.0, the latest tagged release is v1.0.3 from 2026-03-27, nightly builds are published separately, and the last push was on 2026-10-16.

Frequently asked questions

Official sources

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