Bye bye VST2

[dayjob]

VirSyn was already coding VST3 plugins when many of you weren't even born yet.

And? But also, no.

[MrJubbly]

I'm curious, but are there VST2/VST3 to CLAP migration tools? Would that even be possible? If it's even possible, I'm not expecting to exist at present except for maybe Bitwig, but it's more of a question of "can it even be done".

Migrating VST2 to VST3 is replacing a dead thing for a stinky thing. I'd rather go VST2 to CLAP.

It seems, according to Urs Heckmann from U-he, that it’s possible (he did speak about that in another thread

It's not really witchcraft. The VST2 to VST3 migration works just fine, wherever it works. We have huge customer base with NKS, and once we deployed it, it just worked. So our experience isn very good in that regard.

Nothing speaks against doing the same thing with any plug-in format to any other. CLAP has a draft extension for this, but it has not been a priority afaik. I think it'll be more interesting once more host devs with multiple formats take part in the discussion and design of these things.

It would be great if all formats became interoperable in hosts that offer a variety of choices.

This really should become a major priority, imho. Since, it would inevitably massively aid mass CLAP adoption.

But, what would practically need to happen and be in place, in order to facilitate such automatic VST/VST3 to CLAP migration?

Could it be something that might be implemented purely on the DAW/plugin-host side? Or would each individual plugin with VST/VST3/CLAP equivalents also need to implement something to facilitate such migration?

Also, once supported within either the host and/or plugin. Would it then be universally supported for all plugins? (i.e. a fairly quick and straightforward process?) Or would each separate plugin (and/or developer) have to have their own individual 'conversion' method(s) included for each of their equivalent plugin formats (i.e. something which would be far more time-consuming and convoluted for developers to invest time and resources into?)

I'm just trying to gauge the temperature of how realistic such a feature would even be. Because, as we all know, if it's closer to the latter, rather than the former, then we probably shouldn't get our hopes up of that happening any time soon (if ever), since it's doubtful that many developers will be willing to invest a lot of additional time and resources into adding that extra CLAP migration support.

For the record, I really hope this could be realised. Since, I would prefer to move to a fully CLAP environment as soon as possible.

[jamcat]

what about FXP preset files? CLAP versions cannot read these?

what to do with all presets then :/

A developer could build FXP loading into their plugin. It's just an XML file.

[jamcat]

Your prior sentence reads like VST2 doesn't work on Apple Silicon, which isn't the case.

I wanted to come back to this. Because the sentence you are referring to is this:

Not to mention, anything that isn’t VST3 also isn’t Apple Silicon anyways, so I don’t think this affects any of us on Mac that much.

That can only be interpreted to mean one thing:
"No VST3 ⇒ No Apple Silicon"

So how did you or anybody else get "Apple Silicon ⇒ No VST2" from that?
VST2 wasn't even mentioned.

[teilo]

So how did you or anybody else get "Apple Silicon ⇒ No VST2" from that?
VST2 wasn't even mentioned.

Feel better?

[jamcat]

So how did you or anybody else get "Apple Silicon ⇒ No VST2" from that?
VST2 wasn't even mentioned.

Feel better?

You compiled the ASaudio.tech database, so you would have pretty good insight into this question:
How many native Apple Silcon plugins other than Airwindows don't support VST3?

[BONES]

Your bandmate is wise. He avoids all the hassle of a modern world where we are constanly under pressure to upgrade.

Pressure? I can't say I have ever felt any pressure at all to upgrade anything. Ever. I used to do it all the time because it invariably made things better but that hasn't been the case for a long time now. I still use 3DS Max 2009 because it does everything I need, to an extremely high standard. I also stopped upgrading my Adobe suite at CS6, which was released in 2012 and, honestly, there's not been much added since to tempt me into an upgrade, so that's what I still use for freelance work.

These days I mostly upgrade to support the developers, not because I see any real value in upgrading.

That, is 100% beside the point to me. Simply put, I was happy enough with a Mirage, Mac, Moog, and TX81Z in the 80's. All of this just convenience besides maybe granular and other new tech things.

You were happy enough with your Mirage, so if someone had offered you an S1000 or an Emulator 2 you'd have said "no, thanks, the Mirage is good enough", would you? I was happy enough with my Korg M1 until the O1/W came along and I was happy with that until the Trinity came along. OTOH, when the Triton came along, it didn't seem to offer anything over the Trinity, in terms of sound quality, so I was never really interested.

Similarly, buying newer and newer VSTi through the 2000's and 2010's generally led to improvements in sound quality but for the last few years those gains have definitely plateaued. Instruments like Diva and DUNE, both 10+ years old now, have been matched but not greatly surpassed.

[PAK]

How many native Apple Silcon plugins other than Airwindows don't support VST3?

Once you include wrapping? More than you’d think. EG Right now, without changes, this new situation kills the original Korg Legacy Collection plugins since both the AU and VST3 versions (including native Apple Silicon) are wrapped VST2’s.

I don’t know if they can still “get away with it” if they wrap the VST2 plugins in self contained files (It's not a VST2, honest!) rather than linking externally to the VST2, as they do now?

And do these changes impact the ability of solutions, like JUCE, to offer the same wrapping ability for VST2, to other formats, without breaking Steinberg’s new terms? Anyone know?

[rod_zero]

IMHO the company that would make a big difference for the adoption pace of CLAP is Ableton, they have the second biggest user base, only second to FL studio which already has CLAP support in beta. I think that DAW companies might be the more concerned about this since they are the ones that are going to be hit the most with complain from customers when they stop support of VST2 and may push them to adopt CLAP. Unlike the 32 to 64 bit migration this time the depreciation is totally imposed by Steinberg.

In the long run if VST3 loses market share it might get relegated to Cubase/Nuendo and then developers will stop making versions for it just to piss Steinberg.

[Calagan]

No, he's saying he has >800 Apple Silicon plugins that ARE VST2. Your prior sentence reads like VST2 doesn't work on Apple Silicon, which isn't the case.

If anyone interpreted it to mean that, it was not my intention.

What I said (clearly, I thought) was that practically every plugin that has been updated for native Apple Silicon has also had a VST3 version released. Because generally it's only old abandoned plugins that never got a VST3 version, and those plugins also never got an Apple Silicon version.

Chris understood that to be what I said when he corrected me that Airwindows are AS native but not VST3. However, Airwindows are fairly unique in that position. Also, they're not commercial.

Black Rooster plugins come to mind. No VST3 version, but Apple Silicon compatible.

[No_Use]

If we wanted to do that on Windows, we had to deploy VST3 in a folder ("bundle"). I don't think many hosts support this, either.

REAPER does, just FYI.

[Urs]

In the long run if VST3 loses market share

I don't think it will, and I don't think CLAP will "cost" VST3 any market share.

I think CLAP will fill the gap that removing VST2 opens, e.g. like for the aforementioned plethora of plug-ins that are VST2-wrapped-as-VST3/AU.

IMHO the main problems that CLAP seeks to solve in the long term are

- reducing ambiguity and complexity of plug-in and host development
- firewalling the internal codebase against non-permissive and non-standard licenses
- overcoming limitations of VST2 (e.g. sample accurate time info)

By providing a *working* and fully featured wrapper, developers can create VST3 plug-ins without risking to run into the same situation as now. I can not think of a scenario where a CLAP can't forever run wrapped in any VST3 host - even if licenses are terminated completely. Worst case: User needs to install CLAP and wrapper separately.

Likewise, if developers choose to not enter into any non-permissive license agreement, their user base can still use their CLAP plug-ins in VST3 hosts. Such that these non-permissive licenses do not prevent companies from access to that kind of market.

And also, unlike VST2-wrapped-as-VST3 plug-ins, wrapped CLAP plug-ins can offer loads of modern features of VST3, such as Note Expressions and sample accurate automation.

Therefore, in the long run, any CLAP will automatically be available as VST3, and hopefully support more modern features. But without the headaches: Easier to do, no strings attached.

[machinesworking]

That, is 100% beside the point to me. Simply put, I was happy enough with a Mirage, Mac, Moog, and TX81Z in the 80's. All of this just convenience besides maybe granular and other new tech things.

You were happy enough with your Mirage, so if someone had offered you an S1000 or an Emulator 2 you'd have said "no, thanks, the Mirage is good enough", would you? I was happy enough with my Korg M1 until the O1/W came along and I was happy with that until the Trinity came along. OTOH, when the Triton came along, it didn't seem to offer anything over the Trinity, in terms of sound quality, so I was never really interested.

Similarly, buying newer and newer VSTi through the 2000's and 2010's generally led to improvements in sound quality but for the last few years those gains have definitely plateaued. Instruments like Diva and DUNE, both 10+ years old now, have been matched but not greatly surpassed.

We're not in disagreement here. I'm just saying that DAWs, plugins etc. are all just convenience. For sure there's no way I would want to go back to using hexadecimal to edit samples on a numeric display like the Mirage, but it got the job done at the time. We even had a sample editing program for the Mirage on the Mac+ in the late 80's. I agree even about Diva and Dune etc. ending any complaints one could possibly have about the 'quality' of hardware. The point was all of this is convenience. Hardware hasn't been bad for 30+ years, but now we have that all in a computer for 1/10nth the cost.

[Audiority]

Making a VST3 correctly replace a VST2 instance is indeed a priority, but who's using JUCE as a main framework (like us) is facing a huge issue. In a JUCE project, the param ID is a string so that adding new parameters for an already existing product won't mess up previous sessions. The string ID is available for all formats, EXCEPT VST2 which is still numeric only.

Now, in a JUCE project you have to flags: the first (JUCE_VST3_CAN_REPLACE_VST2) will allow the host to replace the VST2 instances with a VST3 version of the same plugin. This is enabled by default; the second (JUCE_FORCE_USE_LEGACY_PARAM_IDS) sets the parameter IDs as numeric. This is DISABLED by default.

The worst is that there's nothing in the documentation that told us that you MUST enable this last flag to grant interoperability between the two VST formats. Not a clue.

Here you can see one of the JUCE's main guys talking about the issue with Steinberg: https://forums.steinberg.net/t/managing ... st3/884119

Long story short: with this scenario (which is basically the one I'm living in), I don't see a way to grant migration without breaking something. Hopefully there's a workaround or a dirty trick to accomplish that.

[aMUSEd]

Making a VST3 correctly replace a VST2 instance is indeed a priority, but who's using JUCE as a main framework (like us) is facing a huge issue. In a JUCE project, the param ID is a string so that adding new parameters for an already existing product won't mess up previous sessions. The string ID is available for all formats, EXCEPT VST2 which is still numeric only.

Now, in a JUCE project you have to flags: the first (JUCE_VST3_CAN_REPLACE_VST2) will allow the host to replace the VST2 instances with a VST3 version of the same plugin. This is enabled by default; the second (JUCE_FORCE_USE_LEGACY_PARAM_IDS) sets the parameter IDs as numeric. This is DISABLED by default.

The worst is that there's nothing in the documentation that told us that you MUST enable this last flag to grant interoperability between the two VST formats. Not a clue.

Here you can see one of the JUCE's main guys talking about the issue with Steinberg: https://forums.steinberg.net/t/managing ... st3/884119

Long story short: with this scenario (which is basically the one I'm living in), I don't see a way to grant migration without breaking something. Hopefully there's a workaround or a dirty trick to accomplish that.

It is possible though and in my tests your own plugins Grainspace and Xenoverb migrate (in a NI host - Komplete Kontrol) - I compiled a list of plugins that support migration within Komplete Kontrol on the Native Instruments forum (although this is for NKS presets but they are the equivalent of host projects). Not all of these migrate perfectly, it's not uncommon especially to get automated params not copied 100% because they often don't align between the VST2 and VST3 versions but it's better than nothing.

https://community.native-instruments.co ... -a-list/p1