Proxima - Synapse Audio

[pummel]

I'd like to see an extended-feature 'emulation' of the legacy VST "Hydra".

Even in 2025, it is among the few unique sounding stand-out VST's from the early 2000's. I realize it is still usable in its present state; but imagine how great hydra could be with Proxima-like features: preset browser with genetics, mod matrix, a second LFOs (retaining LFO delay), real unison, per-voice distortion, effects page, pitch envelopes repurposed as mod envelopes.

Same synth engine, just modern features.

[vurt]

I'll have you know I've lost 25kg this year, I don't look like that any more.

you'll need a new t-shirt!

[Richard_Synapse]

I'd like to see an extended-feature 'emulation' of the legacy VST "Hydra".

Even in 2025, it is among the few unique sounding stand-out VST's from the early 2000's. I realize it is still usable in its present state; but imagine how great hydra could be with Proxima-like features: preset browser with genetics, mod matrix, a second LFOs (retaining LFO delay), real unison, per-voice distortion, effects page, pitch envelopes repurposed as mod envelopes.

Same synth engine, just modern features.

Yeah, that would be cool. We've brain stormed a few times about a successor. The main issue is if we do all the above and then some, it may turn into a radically different instrument. Maybe this is not really an issue, but the question becomes if users would see, feel or hear any resemblance to Hydra

Richard

[D-Fusion]

I just downloaded the demo installer about to test this.

However, I'm always rather disappointed when a newly released modern plugin, doesn't also support CLAP right out the gate.

imho, There's really no excuse not to also support CLAP in 2025+

I feel the same when it comes to native linux support.
You can run them via wine and yabrige but that usually end up using more cpu compared to using a native linux vst 3 or clap plugin.

[seafire]

I just downloaded the demo installer about to test this.

However, I'm always rather disappointed when a newly released modern plugin, doesn't also support CLAP right out the gate.

imho, There's really no excuse not to also support CLAP in 2025+

Maybe if more hosts do, more devs might. Its still a niche market.

[Richard_Synapse]

Our plan was to replace AAX with CLAP, once ProTools supports CLAP. Unfortunately, this has not happened yet. Technically, we can support it, we have an experimental version of DUNE 3 running as CLAP since a long time. But we don't want to maintain so many redundant formats, it makes testing much more difficult. For us it would be the 5th format to support when counting Rack Extensions, or even 6th when counting legacy VST2 stuff. I'm pretty sure those users who want CLAP want it to work flawlessly, take advantage of at least some special features, and not just have it as yet another option.

Richard

[lobanov]

That's incorrect. To replace the public key, you have to modify the .exe or .dll (or in this case, .vst or .vst3.) This makes it a crack, because it's modifying the original file. At that point, it's easier for the cracking group to bypass the DRM entirely, instead of finding the signature checking code, but then leaving it intact and also replacing the public key. No cracking group would bother to do what you're describing, because it's more work than a normal crack, but for no benefit.

I never said that public+private signature checks stops cracks. Nothing stops cracks.

No, it's not easier or harder. Find code that checks signature is trivial. It isn't harder than find the places where key is checked. And a cracker must find code that checks a key anyway. Without it keygen isn't possible.

Replacement of public keys is easier than cracking of key checks. Signature is checked by some standard way and you just replace public key rather than algo (this public key isn't kept in binary in all cases). Key checks are more or less custom, that's why they can be harder.

Cracking groups bother to write patchers. It is trivial. It is often more trivial than write keygens. It is just search in binary and replacement of some data as we do it with texts. The main problem arises when binary is signed. But as I understand it can be circumvented too.

Nothing stops cracks, it is true.

Offtopic, indeed...

[MrJubbly]

Our plan was to replace AAX with CLAP, once ProTools supports CLAP. Unfortunately, this has not happened yet. Technically, we can support it, we have an experimental version of DUNE 3 running as CLAP since a long time. But we don't want to maintain so many redundant formats, it makes testing much more difficult. For us it would be the 5th format to support when counting Rack Extensions, or even 6th when counting legacy VST2 stuff. I'm pretty sure those users who want CLAP want it to work flawlessly, take advantage of at least some special features, and not just have it as yet another option.

Richard

Thanks for responding. I appreciate it.

Interesting to hear you already have a development version of DUNE 3 running as CLAP, for a long time. Since I happen to own a licence for that plugin, which I use in a lot of my projects. I really wished you could have released that sooner to customers, as I would most certainly have been using that format instead of the VST/VST3 (even without any CLAP-specific features) and uninstalled the latter formats from my device.

I do plan on eventually migrating all my plugins exclusively over to CLAP, as and when each developer supports and makes them available to customers.

I have already done this for all my FabFilter and u-he plugins, as I no longer require the VST/VST3 formats thereof, for any of their plugins. I also have manually migrated most of my older projects that did use those, now legacy formats, over to CLAP for these developers' plugins. The idea being, I will soon be able to completely uninstall VST/VST3 formats completely from my current device.

I understand your point about supporting too many redundant formats. And I also I don't want to install too many redundant formats on to my devices for the same plugins. I prefer to streamline my setup and simplify what I have currently installed on my PC (and what format(s) I will likewise install in the future on any new devices.)

I can't comment on all your other supported plugin formats, such as Reason Rack Extensions, AAX, etc., as I have never used them. However, I do get your point about perhaps being more difficult supporting many formats simultaneously.

It might seem a little unfair to hold back on a potential CLAP release, when the format is already currently supported by several other popular DAWs like Bitwig, FL Studio, Reaper, Studio One. Who must wait until a completely different DAW, ProTools, also decides to support the format? (so CLAP can be substituted for AAX?)

What if Avid decide not to support CLAP, or else drag their heels for several more years before doing so? And would some sort of legacy AAX support not still be required, even if they did? Wouldn't the amount of customers who use other popular DAWs which do already support CLAP, not justify a release thereof?

Either way, I personally believe, that CLAP will eventually become the primary (perhaps only, in some cases) plugin format required for most (non-Steinberg) users, over these next few years and beyond.

That's the reason why I said I found it rather disappointing when a new plugin launches that doesn't already support CLAP. As it can give a (perhaps false) impression, that those developers are not forward-thinking enough.

[Richard_Synapse]

What if Avid decide not to support CLAP, or else drag their heels for several more years before doing so? And would some sort of legacy AAX support not still be required, even if they did? Wouldn't the amount of customers who use other popular DAWs which do already support CLAP, not justify a release thereof?

So far our philosophy has been simple- we want our plug-ins to run in as many hosts as possible. This is why we got into rack extensions, as they were exclusive initially.

Regarding CLAP, I'm curious what your motivation is in attempting to replace your existing VST3s. Is there a specific feature you use/need for your projects?

Richard

[seafire]

I'm happy with vst2.4

[MrJubbly]

What if Avid decide not to support CLAP, or else drag their heels for several more years before doing so? And would some sort of legacy AAX support not still be required, even if they did? Wouldn't the amount of customers who use other popular DAWs which do already support CLAP, not justify a release thereof?

So far our philosophy has been simple- we want our plug-ins to run in as many hosts as possible. This is why we got into rack extensions, as they were exclusive initially.

Regarding CLAP, I'm curious what your motivation is in attempting to replace your existing VST3s. Is there a specific feature you use/need for your projects?

Richard

Right now, without any CLAP-specific features, my motives are very simple. I hope to eventually reach the point when I only use CLAP formats going forward, for all my existing and future purchased plugins, so that I no longer need to also install other multiple, redundant plugin formats on to my workstation.

This decision was mainly triggered by Steinberg's decision to discontinue VST a few years ago, and more recently when several plugin developers also started to discontinue their support thereof and removing VST formats from their updated installers.

I value backwards compatibility a lot and wish to be able to continue reload my old projects both presently and also many years into the future. Automatic migration methods from VST to VST3 have been very hit and miss for several non-Steinberg DAWs and I want to minimise issues arising from inability to correctly access my existing projects / due to missing/unsupported legacy plugin formats.

I don't own any Steinberg software. As I am not one of their customers, I don't believe I should be affected by any of their internal policies regarding their plugin formats support or lack thereof.

An open source alternative is clearly the answer. CLAP will likely make my production life simpler, with less compatibility issues in the future and unnecessary bloating of having multiple installed formats, to worry about going forward.

Therefore, the sooner other developers follow the paths of FabFilter, u-he and others, the better and simpler it will be for customers like me

[revvy]

While for customers like me, AU and VST are fine, no need for clap.

It’s all about individual preferences, after all.

[tumface]

I use CLAP when it's available, and VST3 when it's not. It's nice that Steinberg finally released VST3 under a permissive license, but its COM-like API is still a terrible design, prone to mistakes and complications. CLAP is a lot nicer. I guess that part isn't something most users care about, though.

[Super Piano Hater 64]

Automatic migration methods from VST to VST3 have been very hit and miss for several non-Steinberg DAWs

To expand on this point, a post in the JUCE forum concluded that IPluginCompatibility support is incomplete in Studio One, broken in Reaper, and altogether missing in Bitwig and Live. Furthermore, the Ableton developers have stated elsewhere (in communications with plugin developers who keep requesting it) that they know about IPluginCompatibility and don't intend to support it because they don't see enough demand for it.

Off the top of my head, I don't know what kind of support is available in any of these hosts for CLAP's automatic migration features. At least it's less work (ie. less error-prone, less expensive, easier to justify to The Suits) than what VST3 offers.

[MrJubbly]

While for customers like me, AU and VST are fine, no need for clap.

It’s all about individual preferences, after all.

AU is no good for Windows customers (so at least +50% of the customer base). Perhaps, Linux users also?

VST is no longer supported by Steinberg and many developers have already removed VST format from their updated plugin installers.

CLAP is supported on all OS platforms, already supported by most of the non-proprietary plugin format DAWs. Is the best solution for most people in 2025 and will increase in popularity every year until it becomes the primary industry standard.

The sooner developers support it, the better for most customers (see above)

Steinberg customers can continue using VST3, while others will be free to choose what they prefer.