OB-Xf by Surge Synth Team

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Post Reply New Topic
RELATED
PRODUCTS
OB-Xf

Post

soniccraft wrote: Fri Dec 12, 2025 9:51 pmSo that's the old engine, one voice at a time, with forced 2x oversampling eating CPU.
It's not forced, it is optional, the HQ button on the GUI toggles that.

I am not going to enter a pissing match here, but it is very easy to test that discoDSP didn't in fact recode v3 from scratch, oscillators are identical to v2.11 version and that is a quick thing to check with a spectrum analyzer (among other things you mentioned including the filter).

Post

soniccraft wrote: Fri Dec 12, 2025 9:51 pm
EvilDragon wrote: Thu Dec 11, 2025 7:50 pm Hopefully by the end of year, we'll see!

I'm not sure if anything is missing from OB-Xd 3.x, apart from patch management being different, and patches not being compatible (due to certain parameters changing their scaling and ranges, for consistency reasons). We have improved on almost every aspect of the original codebase, and included some features that 3.x doesn't have at all.
I was curious so I compared and OB-Xd 3 has a completely rewritten engine with some SIMD thing that processes multiple voices at once, better oscillators, polyphonic unison, hardware-accurate modeling and self-oscillating filters. They rebuilt it from scratch with loads of new features.

Meanwhile, you lot are running the 2013 code - your own repo says "continuation of version 2.11." So that's the old engine, one voice at a time, with forced 2x oversampling eating CPU.

So... you've taken decade-old code, added a handful of features that aren't exactly groundbreaking (second LFO, noise modes, independent pitch bends - lovely, but hardly revolutionary), given it a new coat of paint with UI improvements, broken backwards compatibility without providing a converter, and you're genuinely claiming you've "improved almost every aspect" compared to OB-Xd 3? That's either monumentally ignorant or monumentally arrogant, and I'm not sure which is worse.
yea, although the broken backward compatibility is a pity
please know your facts
before you write such things
viewtopic.php?t=621434
and there is more
and even more to come

Post

Happy Disco DSP has a great product! And your analysis that indeed we took the open source code and made it build, fixed some things, added some things, and broke compatibility is spot on.

Folks seem to enjoy it though and I'm glad the open side of the synth is back in working order. If you aren't then thats also cool! There's loads of synths in the world.

I reverted the Linux menu scaling change which broke macOS. Should be a new build in about an hour. Sorry about that. For once I tested linux and not mac!

Post

In theory we can likely do some patch conversion post-1.0, it would require some research and a decent amount of testing. However the main difference is in unison implementation, so those patches wouldn't translate accurately.

Post

baconpaul wrote: Fri Dec 12, 2025 10:34 pm I reverted the Linux menu scaling change which broke macOS. Should be a new build in about an hour. Sorry about that. For once I tested linux and not mac!
Thanks - all good now! :tu:

Post

After my last post questioning the claims being made here, I decided to go directly to discoDSP for clarification. I asked them specifically about the architecture differences and the statements being made.
Thank you for reaching out regarding OB-Xd.

OB-Xd 3 is a complete ground-up rewrite commissioned to Vadim Filatov, the original OB-Xd developer. This was a multi-month project representing a significant financial investment.

The codebases are fundamentally different:

OB-Xd 2: Object-oriented per-voice architecture, no SIMD vectorization, per-voice decimation, standard BLEP anti-aliasing.

OB-Xd 3: Data-oriented vectorized architecture, 128 internal voices (32 playable) with 16-voice polyphonic unison, full AVX2/NEON SIMD processing 4-8 voices simultaneously, template-based design with runtime CPU detection, premium BLEP implementation with 64x internal oversampling + BLAMP + kernel interpolation achieving ~96 dB aliasing rejection.

Regarding spectrum analysis claims: this demonstrates a fundamental misunderstanding of DSP. Properly implemented anti-aliasing produces clean harmonic content. You cannot distinguish a 64x oversampled BLEP with kernel interpolation from a basic polyBLEP by looking at a spectrum analyzer.

Both versions use BLEP-based anti-aliasing, which is already alias-free at base sample rate. The runtime oversampling in both versions is optional and primarily benefits filter and nonlinear processing. However, OB-Xd 3's BLEP implementation is fundamentally superior: 64x internal table oversampling vs standard, SIMD-accelerated kernel application, linear interpolation between kernels for artifact-free correction, and dedicated BLAMP tables for triangle wave derivative discontinuities. This is not the same implementation it's a complete rewrite with professional-grade improvements.

Best regards,
discoDSP Tech Support
https://www.discodsp.com/
So let me translate this for everyone:

@EvilDragon from Surge Team - Your claims are factually wrong:

1. "Oscillators are identical to v2.11": Completely false. The oscillator code was rewritten from scratch.

2. "Easy to test with spectrum analyzer": This proves you don't understand what you're measuring. BLEP is designed to produce alias-free waveforms. A properly implemented BLEP saw wave will measure identically to any other properly implemented BLEP saw wave. That's not evidence of copied code. That's evidence of correct implementation. You might as well claim two calculators are identical because they both say 2+2=4.

3. "discoDSP didn't recode v3 from scratch": They paid Vadim Filatov. New architecture, new data structures, new processing model, new filters... What part of "ground-up rewrite" is unclear?

4. Your fork's architecture: OB-Xf is, by your own description, a "continuation of version 2.11." That's the 2013 per-voice scalar code. You've added some features on top. That's fine. But claiming you've "improved on almost every aspect" compared to a modern SIMD-vectorized engine with 128 voices and polyphonic unison is delusional.

You made definitive public statements, based on analysis methods that are technically meaningless, about code you've never seen, while running a decade-old codebase you apparently don't understand well enough to recognize the difference. That's not expertise. That's ignorance presented with confidence.

And frankly, you don't need to respond. Maybe spend more time actually studying the code you're supposedly maintaining.

Good luck, lads.
EvilDragon wrote: Fri Dec 12, 2025 10:13 pm I am not going to enter a pissing match here, but it is very easy to test that discoDSP didn't in fact recode v3 from scratch, oscillators are identical to v2.11 version and that is a quick thing to check with a spectrum analyzer (among other things you mentioned including the filter).

Post

You talked to the discodsp chatbot?

Post

Yup that's exactly what happened.

If an alleged rewrite produces identical sounding results it is not sonically superior in any way, it is producing identical sounding results. It doesn't matter if the code is 10 years old if it sounds identical. LOL.

Also we have polyphonic unison, too.

Post

soniccraft wrote: Sat Dec 13, 2025 8:36 am 4. Your fork's architecture: OB-Xf is, by your own description, a "continuation of version 2.11." That's the 2013 per-voice scalar code. You've added some features on top. That's fine. But claiming you've "improved on almost every aspect" compared to a modern SIMD-vectorized engine with 128 voices and polyphonic unison is delusional.
Hmm, what they actually said was: "We have improved on almost every aspect of the original codebase" - by "original codebase" I read as, they improved on the V2 codebase they started with.

Nowhere in the posts you quote did they claim they improved on every aspect of the *V3* version, which you seem to be interpreting their words as saying. If they did, I missed it - I'm just going by what you quoted and then kicked off about.

Maybe I'm reading it wrong, or maybe you're just wanting to shout at them for a claim they aren't actually making. Either way - not sure why you want to rant about this - you can use discoDSP's superior V3 version, and just ignore this one - no one will mind. Relax and enjoy.

Post

rasmusklump wrote: Sat Dec 13, 2025 9:02 am You talked to the discodsp chatbot?
:wink:

What is the name of their friendly Chatbot ?
No auto tune...

Post

AI Overview
There is no evidence from the search results to suggest that discoDSP, a company that produces virtual instruments and effects, uses a friendly chatbot for customer interactions.
:lol:

Maybe they use a nasty one. I don't know!
Anyone who can make you believe absurdities can make you commit atrocities.

Post

:lol:
FL Studio 25 | AudioThing JULY - Deimos - U-he Filterscape - NI Kontour - Softube Model 80 - LUSH-2 - UAD Opal - WaveOSC

Post

https://github.com/surge-synthesizer/OB-Xf/issues/490

I repeat this, the previous way of having the patches was better. This pop out browser completely invalidates having banks.

Post

Banks had various issues across different hosts, so we had to backtrack on that idea. Great majority of plugins don't use banks anyways, so there's not really a huge loss there.

There will be patch browser updates in 1.1 and beyond.

As it stands, you can absolutely group patches in "banks" , use the Project field when saving a patch, this creates a separate folder just for the patches stored to that same project.

Post

Who cares what the "great majority" do. The banks worked well with the groups. As you've put this new file browser in, it's now a pain to go between groups whilst the previous pop out just showed the entire bank/group layout cleanly and clearly. The skeuomorphic button navigation might be alright on a touchscreen but not with a mouse/keyboard

Post Reply

Return to “Instruments”