Cubase 12 dropping VST 2 support (For Apple Silicon)

[Funkybot's Evil Twin]

Well, on u-he's site, there is no mention of the VST2's not being ARM native, so, I (have to) take your word for it.

"Not mention of them not being ARM native?" "Take my word for it?"

Why would everyone be lying about this? I assure you, these are "actual facts" (it's a term I invented - means the opposite of "fake news").

I'm using them in real-life on my 2021 M1 Macbook Pro on Reaper. The native (ARM64) and bridged (Intel) VST2 plugins both work in Reaper, but they show up differently and you can tell which are which just from the plugin names. This is real.

[chk071]

Chill down. I didn't accuse anyone of lying. In the part you removed in your quote, I explicitly said that many DAW's hide what the plugin hosting does from you.

As far as I can see, Logic doesn't support VST, only AU. So, you guys can only run VST2 in other DAW's, like Bitwig or Reaper. Bitwig seems to bridge/sandbox the plugins. I don't know what Reaper does.

Do you acknowledge, that this might be a bit more complicated, and that there could be misconceptions/misunderstandings? Or do you want to go on being angry, and accusing me of lying?

Hope someone who really knows about this can clear this up at some point, then we don't have to go for each other's throat about this.

[zvenx]

......
To the Cubendo users: when your DAW developer keeps treating you like crap and regularly misleads you...you're not in a healthy DAW relationship.

OR
It's time to dump and only support plugin developers who support vst3.

As I said elsewhere my daw is way more important for my workflow than any one plugin developer.

rsp

[rasmusklump]

"Intel VST2 plug-ins can be used (bridged) from Intel to ARM64."

How am I supposed to interpret that in another way than that... they have to be bridged from Intel to ARM64.

You keep referencing Intel VST2 plugins. As I've already mentioned, I am talking about Native VST2 plugins. Different subject matter.

Intel VST2 and Intel VST3 plugins both need to be bridged. Apple Silicon native plugins, whether VST2 or VST3 do not.

Can you name some ARM64 native VST2 plugins?

U-he - almost all plugins (except Uhbik, MFM2, Filterscape, and Tyrell)
Valhalla - all plugins
Overloud - all plugins
Eventide - almost all plugins (except QuadraVox and OctaVox)
Acon Digital - all plugins
etc.

I've literally got over a hundred native ARM64 VST2 plugins. Maybe closer to 200.

...why are you not believing the people who actually own the damn PC's and use these plugins daily? Oh, right...because Steinberg is confusing the issue and putting out misleading information.

+1
UVI falcon and Workstation are arm64 vst2 as well.

[Funkybot's Evil Twin]

To clarify things, I'll do some free PR for Steinberg and provide them with the statement they should've made. Steiny...this one's free, feel free to use this. Everyone else, just pretend this is the message Steinberg actually put out.

Because some developers continue to release VST2 plugins rather than adopting the VST3 plugin standard, Steinberg is taking yet another punitive action against those developers, and ultimately our customers, and will therefore not be supporting Apple Silicon VST2 plugins on ARM-based Macs. There is no technical limitation that is requiring this, but we have simply decided to try to strong-arm any remaining hold-out developers into making the jump to VST3. Thank you for continuing to be a Cubase/Nuendo user despite all of this.

[Funkybot's Evil Twin]

As I said elsewhere my daw is way more important for my workflow than any one plugin developer.

That's you. And that's fine. You're making an informed choice that's right for you. I don't begrudge you that.

I have Cubase 10 and won't be upgrading. Don't use it much anyway. I'd rather give my money to DAW makers who don't create arbitrary limitations on what software I can use, then try to mislead people into believing that there's some technical reason they had to make that choice when there isn't. And yes, that's my interpretation of what Steinberg has done and others are free to disagree with that too.

[pdxindy]

"Intel VST2 plug-ins can be used (bridged) from Intel to ARM64."

How am I supposed to interpret that in another way than that... they have to be bridged from Intel to ARM64.

You keep referencing Intel VST2 plugins. As I've already mentioned, I am talking about Native VST2 plugins. Different subject matter.

Intel VST2 and Intel VST3 plugins both need to be bridged. Apple Silicon native plugins, whether VST2 or VST3 do not.

Can you name some ARM64 native VST2 plugins?

U-he - almost all plugins (except Uhbik, MFM2, Filterscape, and Tyrell)
Valhalla - all plugins
Overloud - all plugins
Eventide - almost all plugins (except QuadraVox and OctaVox)
Acon Digital - all plugins
etc.

I've literally got over a hundred native ARM64 VST2 plugins. Maybe closer to 200.

...why are you not believing the people who actually own the damn PC's and use these plugins daily? Oh, right...because Steinberg is confusing the issue and putting out misleading information.

Fabfilter also...

I have not installed Rosetta and only installed native applications and plugins... so any VST2's on my machine must be native.

[chk071]

I wonder what it means that the VST3.7 SDK added support for Apple Sillicon: https://www.gearnews.com/steinberg-rele ... t-3-7-sdk/

In light of Apple’s announcement to transition its entire line-up to ARM processors over the next two years, Steinberg has also added ARM support to the VST 3.7 SDK. The company says that this lets developers create plug-ins that are compatible with the new ‘Apple Silicon’ chips.

[pdxindy]

Well, on u-he's site, there is no mention of the VST2's not being ARM native, so, I (have to) take your word for it.

"Not mention of them not being ARM native?" "Take my word for it?"

Why would everyone be lying about this? I assure you, these are "actual facts" (it's a term I invented - means the opposite of "fake news").

I'm using them in real-life on my 2021 M1 Macbook Pro on Reaper. The native (ARM64) and bridged (Intel) VST2 plugins both work in Reaper, but they show up differently and you can tell which are which just from the plugin names. This is real.

FL Studio and Ableton Live are also Apple Silicon native now. They are also running native VST2 plugins without issue. Only Steinberg is announcing that they are dropping support for VST2.

[syntonica]

I wonder what it means that the VST3.7 SDK added support for Apple Sillicon: https://www.gearnews.com/steinberg-rele ... t-3-7-sdk/

In light of Apple’s announcement to transition its entire line-up to ARM processors over the next two years, Steinberg has also added ARM support to the VST 3.7 SDK. The company says that this lets developers create plug-ins that are compatible with the new ‘Apple Silicon’ chips.

I haven't seen it yet, but I seriously doubt there's anything required for ARM support, unless buried deep in the code are Stupid Intel Tricks that needed to be abstracted away for a different processor. More likely, they've added Metal on the backend for graphics support. I'm unsure of the state of OpenGL on ARM since Apple deprecated it a few years ago.

There are zero technical reasons for dropping VST2 support specifically for AS Macs. ZERO. It's purely the next step in SB's nefarious plot to rid the world of their Frankenstein's monster that they themselves created.

For as bad as working with VST2 is, it conforms to a simple C ABI that allows programmers to create plugins (i.e. libraries) in any programming language that follows the same ABI. The whole thing can actually live in a single header file. The new VST3 SDK is C++ through and through, making it much harder to use anything but C++. It's a giant, convoluted mess, poorly documented (worse than VST2 is, imo) and fails to treat audio and midi both as first-class citizens, making working with midi far, far more difficult than it needs to be.

[jancivil]

So I'd do the same as I do under Big Sur on the Intel box, VE Pro VST3 hosting virtually every vi (the one thing I'd plug into Cubase is two Reaktor insts so I can interact with its controls via mouse or trackpad and live automate, which I haven't done in years) and /except for when I do work w.committed to 2-files/ every effect (and the FX I apply to audio clips is all VST3 now). VSL has shown no real sign VE Pro is going to host VST3 very soon.
I don't personally have an actual reason for what it does except that VST3 gives up to 48 MIDI ports vs the one so it's VE Pro VST3.

It doesn't seem very strange t'me that a developer would eschew VST3 if they're not forced to adapt, I've never used a vi as VST3, and the FX may be superior somehow on paper but I don't know of any necessity. Probably not going to go to the ARM this lifetime anyway. For me it's does VSL have a proper working VE Pro for it. I think it's via Rosetta 2 at this point, and they just fixed their GUIs not showing under Monterey, acc'ding to change logs.

[Trensharo]

"Intel VST2 plug-ins can be used (bridged) from Intel to ARM64."

How am I supposed to interpret that in another way than that... they have to be bridged from Intel to ARM64.

You keep referencing Intel VST2 plugins. As I've already mentioned, I am talking about Native VST2 plugins. Different subject matter.

Intel VST2 and Intel VST3 plugins both need to be bridged. Apple Silicon native plugins, whether VST2 or VST3 do not.

Can you name some ARM64 native VST2 plugins?

U-he - almost all plugins (except Uhbik, MFM2, Filterscape, and Tyrell)
Valhalla - all plugins
Overloud - all plugins
Eventide - almost all plugins (except QuadraVox and OctaVox)
Acon Digital - all plugins
etc.

I've literally got over a hundred native ARM64 VST2 plugins. Maybe closer to 200.

...why are you not believing the people who actually own the damn PC's and use these plugins daily? Oh, right...because Steinberg is confusing the issue and putting out misleading information.

+1
UVI falcon and Workstation are arm64 vst2 as well.

Recompiling a plugin for ARM64 is not optimizing it for ARM64, and if there are any bugs in the VST2 SDK that the plug-in developers can't themselves fix, this will not be fixed by steinberg. VST2 SDK has been out of development since 2013, and discontinued since 2018.

Once the 2013 announcement hit, developers should have started moving away from VST2. However, DAW Developers helped to slow down this transition - as many took FOREVER to support VST3.

People should not be complaining about Steinberg. They should be asking the DAW and plug-in developers why it took them this long to move to VST3. They've had over 8 years to do so.

Native Instruments had only a few VST3 plug-ins, but suddenly 75% of their plugins get updated to VST3 in a couple of months after this news hit... Unless you're going to try to tell me they've been working on this for years because "VST3 is so much harder to work with," I'm going to have to assume complacency is a huge factor in why it took so long for this to happen.

Releasing a new VST2 plug-in these days is like developing an OpenGL/OpenCL application for macOS.

DAW are basically the operating systems for these plug-ins. If everyone stays on Windows XP, then developers have to target Windows XP as a baseline. VST2 is the Windows XP of the plug-in world. Because so many DAWs took too long to implement support, plug-in developers simply had no choice but to keep targeting VST2. This snowballs, as the continued support decreases the incentive to invest in VST3 support, but the lack of investment in that area in so many applications disincentivizing developers from investing in porting to VST3.

Crying about VST3 being more complicated /shrugs/ Developers aren't not paying us to use products they're developing. We're paying them to use those products.

There are several features in VST3 that don't exist in VST2. The only way to rectify that would be to amend VST2, which could end up even more complicated and far less consistent than the VST3 SDK is right now. And it would completely fragment that market segment, as core features would depend too heavily on what version of the SDK a plug-in is written against.

It would be Android fragmentation in the VST plug-in world. The only benefit from VST2 sticking around as long as it did, is that it allowed VST3 to mature to a point that we don't have to deal with those "growing pains." The baseline is already fairly mature, and relatively dependable in terms of what it delivers.

And VST3 is a lot more efficient than VST2 on large projects with lots of plug-ins.

The issue with VST3 is not the Spec or SDK, it's the level of support in DAWs. Lots of DAWs are still pretty bad with it, becasue the developers can always just ask you if the VST2 works and close your support case when you say "Yes."

[zvenx]

.......
Recompiling a plugin for ARM64 is not optimizing it for ARM64, and if there are any bugs in the VST2 SDK that the plug-in developers can't themselves fix, this will not be fixed by steinberg. VST2 SDK has been out of development since 2013, and discontinued since 2018.

Once the 2013 announcement hit, developers should have started moving away from VST2. However, DAW Developers helped to slow down this transition - as many took FOREVER to support VST3.

People should not be complaining about Steinberg. They should be asking the DAW and plug-in developers why it took them this long to move to VST3. They've had over 8 years to do so.

Native Instruments had only a few VST3 plug-ins, but suddenly 75% of their plugins get updated to VST3 in a couple of months after this news hit...

Releasing a new VST2 plug-in these days is like developing an OpenGL/OpenCL application for macOS.

Huge plus 1.
rsp

[MirkoVanHauten]

Once the 2013 announcement hit, developers should have started moving away from VST2. However, DAW Developers helped to slow down this transition - as many took FOREVER to support VST3.

People should not be complaining about Steinberg. They should be asking the DAW and plug-in developers why it took them this long to move to VST3. They've had over 8 years to do so.

If VST3 offered everything VST2 did and more, I'm sure it wouldn't have been such a hassle to transition. If devs weren't able to transition quick and easy, that already indicates the failure of the new format. Feel free to read topics from actual devs about VST2/VST3 in the kvr developer forum...

[Super Piano Hater 64]

People should not be complaining about Steinberg.

People have every right to complain about Steinberg, because they are the stewards of a platform. If they don't want the responsibilities of that role, they should go ahead and renounce it. The industry will move on without them.

VST3 could be a lot better than it is. It would have been already, if Steinberg had listened to advice/criticism from third-party developers at any point in the last eight years. They could have incentivized developers to make the switch by designing the format with developers' needs in mind. Instead, they designed what was convenient for them at the time and told everyone else to get f**ked, and then acted surprised when developers didn't immediately come crawling back for the chance to lick their shoes.

If we can criticize Apple and Microsoft for this kind of behavior, we can absolutely criticize Steinberg as well.