Is there a Surge XT patch bank motherlode

 

Surge sounds utterly awful in every way. I do not understand the appeal when there are free synth that sound good.

 

While I would say to have both, it’s a bit tricky to find the Virus TI firmware to make ostirus run, Surge is ready to go out of the box and is more advanced despite only being bitimbral, nonetheless you still get a very complex monster for free, one of the best free plugins in existence… plus you can have Virus TI wavetables imported into Surge

 

Appreciate the input, folks...

I think I might understand what's going on (and maybe why many synths sound so 'bread-and-butter' or 'shallow' to me), and maybe why U-He's for example, along with few others, might have certain je-ne-sais-quoi's about them (at the 'root' levels) that people pick up on:

Why go through the trouble of emulating the actual chip if it wasn't for its signal flow/architecture that affects the 'signal'/sound?

For the Roland's different chip now, right at the end of one of its YT preview videos (cue at 12:12 in presented video below), they apparently give a hint at 'the trouble', with microscopes and wires and analysis equipment. (This chip may be different from their standpoint where they didn't have the schematics at the outset and so had to 'decrypt' and/or 'reverse engineer' it.)

Here may be another 'hint' from the manual of another synth I like and own:

"We believe that Spectral is an exceptional instrument because of its unique
audio processing capabilities, which result from the fact that we at LinPlug
design most of our audio modules from scratch, sometimes – as in case of
Spectral - following paths no one else would probably even consider." ~ Linplug's Spectral synth's manual

So it might be about the signal, too, and its 'creative' 'flow/paths', not, or not just, the other 'whiz-bang' features 'tacked on'.

 

Last edited: Nov 14, 2025

That’s for the “secret” solution, which might not be accepted everywhere, Surge doesn’t need that kind of extra step and unless you already have a Virus TI, you would have to take the foggy path to the museum like most of us here

 

It's really not that hard and the bins can be found in multiple locations on the net, even including, for example, sometimes on archive.org.

 

There are a few synths-- Vavra, Nord Lead and so on-- The Usual Suspects have done, based on one or more versions of one chip. Now they have ventured into another chip with the Roland.
I think their work is FLOSS, yes? If so, it does beg the question of forks and added features in my mind.

 

Last edited: Nov 14, 2025

That, like Pigments and others, is also about visual feedback of course.

Pet Cat Desert Island Setup:

 

Last edited: Nov 14, 2025

Surge for me, I use it in vcv as well with over sampling. Thing with surge is it has Plaits oscillators & i just really that modern sound in contrast to my analog. Virus is ok its a digital VA reliant on fx, the hardware was very nicely made.

 

Surge on VCV Rack, but I dislike the VST version. Annoying UI. (imho) I've always enjoyed working with a Virus. So i'd have to choose that. The nice thing is however we have a plethora of choice.

 

.

Amen to choice!

Regarding Surge plugin vs. Surge modules in VCV/Cardinal... Sure, the UI in Surge is not the greatest, it's been unchanged basically ever since it was payware and could do with a revamp... mean it's nice that we got scalability and skins but that's not enough.

But it's strength is that the patches are self-contained and easier to share. VCV patches (as we all know) are always very individual and idiosyncratic and they're harder to share in a way to be immediately usable if there's more going on than just MIDI note input. With the plugin you can just map the macros and name them, done, good to go.

(group modulators with generators/processors alongside signal flow or separate the control and audio paths? choices, choices)

An aside, BaconPaul's (one of Surge XT's devs, he was behind the VCV modules) other stuff is great too, some great VCV gear and other plugins too (Six Sines, Two Filters), recommended. But this is veering off-topic, sorry.

 

"Always love the one ya hurt ya hurt ya hurt ya hurt ya..."

 

Last edited: Nov 15, 2025

Do you not understand that it's an EMULATOR and The Usual Suspects do not have any right or even the means to modify, let alone distribute or do absolutely anything with the Virus firmware?? Did you not notice that you are supposed to own the synth and/or find the firmware on your own? After all the work they spent on the emulator itself, do you think they WANT to get sued by Kemper (or Waldorf or Clavia) for infringement and IP theft?

 

So it's the bin file that determines the 'features' then, yes? (What are the bins actually doing?) If so, I wonder when its copyright ends and/or if another, say, FLOSS, bin file could be used or created (one day in the future). What can you do with the chip emulation? Another pseudohardware synth that doesn't exist that's based on the chip emu? Wouldn't be the same 'synth' I suppose, but still, if we have the chips. But I suppose that's how the best emu's work. What would be the point of a non-emu 'emu'? We'd be back to just 'good signal-path' softsynths like Spectral, Sylenth1 or Diva, yes?

...Looks like the UI's are ok, at least legally, anyway...

Maybe they have a good lawyer.
So apparently the Motorola (DSP), etc., chip design emu at least was legally-fine then... with different synth manufacturers apparently building on it/them. I wonder how that works, and vis-a-vis TUS' work.

 

Last edited: Nov 15, 2025

~ The Clean-Room Binary ~

Me:
The Usual Suspects are emulating the dsp chips used in hardware synthesizers. What is the purpose of that?

AI:
The purpose of The Usual Suspects emulating the DSP chips used in hardware synthesizers is to create highly accurate software replicas of classic digital synthesizers by replicating the original digital signal processing (DSP) hardware at the core of these instruments. This method involves emulating the specific DSP chips—such as the Motorola 56300 series or the Toshiba TC170C140 'ESP2' used in the Roland JP-8080—rather than simulating the synthesizer's overall sound engine. By doing so, they aim to achieve bit-accurate output that matches the original hardware, preserving the authentic sound and behavior of the vintage synths. The emulation allows users to run these classic instruments as plugins (VST, VST3, AU, CLAP, LV2) within modern digital audio workstations (DAWs) on Windows, macOS, and Linux, including Apple Silicon Macs. The project emphasizes that the emulator itself is not illegal, but users must provide their own legally obtained ROM or firmware files from the original manufacturer, as sharing these files is prohibited. This approach enables access to discontinued or rare hardware synths while overcoming limitations of the original hardware, such as outdated control software or physical degradation.

Me:
Why is the emulator legal but its bin file is not? Also when would the bin file become legal? When would its patent or copyright period end?

AI:
The emulator itself is legal because it is software that replicates the functionality of hardware through original, reverse-engineered code, which does not infringe on the original manufacturer's intellectual property. However, the bin file (such as firmware or BIOS) is typically copyrighted software embedded in the original hardware. Distributing or downloading these files without authorization violates copyright law, even if you own the hardware.

You can legally use the bin file only if you extract (or 'dump') it from your own hardware for personal use— this is often considered a backup under certain interpretations of copyright law (e.g., U.S. Title 17, Section 117). Sharing or downloading these files from third parties remains illegal.

Regarding when the bin file becomes legal:

Copyright, not patent, protects firmware. In most countries, software copyright lasts for 70 years after the author's death (or 95 years from publication for corporate works).

Most vintage synthesizer firmware from the 1980s–1990s will remain under copyright until at least 2050–2070 or later, depending on jurisdiction and publication date.

It only enters the public domain— and becomes legally shareable— after the copyright expires.

Until then, legal use requires either owning the original hardware and dumping the firmware yourself or waiting for the manufacturer to officially release it (e.g., as open-source or abandonware, which is rare).

Me:
Why is reverse-engineering the emulator legal but not reverse engineering the bin file? Could another bin file be used/programmed to get around the original bin file's copyright?

AI:
Reverse-engineering the emulator is legal because it involves creating new software that mimics hardware behavior without copying copyrighted code— typically done via clean- room design, where one team analyzes the system and another, isolated team implements it from functional specifications.

Reverse- engineering the bin file (firmware) is legally risky because the resulting code may still be considered a derivative work of the original copyrighted firmware. Even if recreated independently, if it performs identically and contains protected expression (not just functional elements), it can infringe copyright.

However, creating a new, clean-room firmware binary from scratch— based only on functional specifications, without copying or decompiling the original— can be legal. This new bin file would avoid copyright infringement by ensuring no protected code or structure is copied, relying solely on interoperability needs.

 

Me:
What does the binary file actually do and compared, and in conjunction with, the dsp chip or its emulation? How easy would the binary be to create from (clean-room) scratch?

AI:
The binary file (firmware) contains the low-level program that runs directly on the DSP chip, defining how it processes audio signals—such as synthesis algorithms, filtering, and effects. It is specific machine code tailored to the DSP’s architecture and is essential for the chip to function as intended in the original hardware.

In emulation, the DSP chip is simulated in software, and the binary firmware is loaded into this virtual environment so the emulator behaves exactly like the original hardware. Without the firmware, the emulator lacks the actual instructions needed to generate the correct sound.

Creating a clean-room replacement binary from scratch is extremely difficult. It requires:

• Deep understanding of the DSP’s instruction set and hardware behavior.
• Functional specification derived from observing the original system (without disassembling copyrighted code).
• Recreating complex audio algorithms (e.g., FM, wavetable, or physical modeling) with cycle-accurate timing.

While legally safe if done properly, it demands significant reverse-engineering effort and expertise in both audio DSP and embedded systems. Most projects rely on dumped firmware due to this complexity.

 

Duplicate post.