3rd Party Plugins that don't load in Apple Silicon mode

Cubase 12.0.40 running apple Si mode, Mac Studio ultra. All these plugins are supposed to be M1 compatible / native but don’t load. In no particular order :

Everything Roland. includes System 1M, Zenology

Bias Amp2 - TS basically admits something is wrong, use intel mode :frowning: works in Logic

Black Rooster Plugins : supposed to be native, don’t load. Cypress, Canary, VHL-3C. works in Logic

Some of these loading in Logic are seen as AU’s which is fine.

In fact opening Cu VST plugin manager many of these simply aren’t even being seen. Some y are on the blocked list - System 1M, Zenology. Is this a case of needing to force Cu to re-evaluate all VST’s ? or known bug(s) with not loading all M1 native plugins correctly ? especially since Logic and other apps seem to be ok with them.

All most all Arturia works - instruments and FX. Tape Mello-fi only loads at AU
Everything Korg works
Slate Digital works but did require uninstall / reinstall of iLok app + drivers.


@SteveOakley I get what your going through. Some plugins are stated as M1 silicon compatible but that does not mean its M1 native. It Just means they work in Rosetta mode. Thats something that developers are not good at being exact about.

Roland cloud synths are mostly M1 native but only their AU plugin is native. I use BlueCat Patchwork to open that in Cubase 12 native mode.

Basically you need two things to align; the plugin developer has made the plugin M1 native (not just compatible) AND also the plugin has to be VST3 native.

So UAD DSP are all native plugins but they are not VST3 so I have to use Patchwork to open them. But UAD spark are native and VST3 so I can use those directly in C12.

Soundtoys have a public beta that is Native and VST3 out now.

In essence I have spent most of this year waiting for M1 Native plugins but also the developer must make a VST3 Native version too.

When i first got C12 I had hardly any plugins but now its looking much better.

I got BlueCat Patchwork for opening AU and AU Intel Rosetta converted plugins in C12. Its not a perfect solution but it helps.

thanks for that - Patchwork. debating the wisdom of spending $99 to fix the lack of work by devs but it does look interesting for other things. It would also being a couple projects back to life and working on M1.

Roland TS got back to me really quickly and basically said the same thing. No idea what devs are thinking with M1 chips out for the last 1.5 years to of not supported it. If you have an AU working, no good reason not to have a VST3 working. Sure it’s not zero effort but still, some of these plugin co’s are large enough this should have been done… like Roland.


1 Like

I somehow get your point, but in the end it was your decision to get a M1 Mac, even if you knew, that there will be compatibility issues. In general it is not a good idea to jump to a new system if you need to get work done and you don’t know for sure that it will work well.

People complaining for M1 compatibility need to be patient. Developers built der Plugins in the last decades for Intel CPUs mainly, as they had the most market share in the DAW world. Porting everything they did in all those years to a completely different system is a shitload of work.
Not every dev studio has tens or hundreds or even thousands of programmers like big companies as Adobe or Autodesk, heck a lot of our favorite plugin manufacturers are just working alone. Now they would have to stop working on new plugins or supporting, fixing, giving maintenance to their existing plugins, just to port it to a new chip.

Don’t want to be rude here, but if you need a reliable working system, don’t buy something, which is out there for a relatively short time and is known to be problematic.

I have a degree in CS. I used to write assembler as my preferred way of working because it was a lot simpler, for me at least. I’ve directly worked with several of the A named companies :confused: I know many people personally in engineering at one company in particular. their dev groups are surprisingly smaller than you’d expect but also pretty productive too. you are lecturing to the wrong person.

moving from x86 to ARM for well written C++ / Swift can be as simple as a recompile, maybe a few simple odd things to fix. Its not rewriting mostly from scratch. If your plugin is 32bit VST2, ok thats going to take a lot more work, but it may not be that much depending. One thing I have seen is that moving from 32 to 64 bit tends to be the hardest because it does require going through everything. If your code is clean 64bit, high level language and nothing dirty like inlined assembler its more about recompile, checking lib dependencies, If your plugin uses old and deprecated APIs, well thats going to be potentially a lot more work to modernize, but also reflects a failure to engage in maintenance too…

At 6 months in, ok sure. at 1.5 years in, no. Yes they should stop work on new things to get the old thing working. You have to support your existing users, as well as make your product attractive to new ones who have new hardware. You might even get an upgrade fee as several apps I use have done with full ver updates that added M1 support.

OTH I use several apps that have a dev team of 1-3. Actual complex apps. They have long ago released M1 native vers. The reality is some of the small devs actually have day jobs working for other people. They coast along for years w/o doing little to no maintenance while making whatever they do. I don’t per se blame them, but lack of M1 support if they have 64bit / VST3 already is not really excusable. I mean, its their product / job. I have a couple plugins that suffer from this.

1.5 years isn’t a short time. Its like waiting to install the last vers of the old OS when the new one comes out because you are actually 2 vers behind. I know those people. The ones that complain something doesn’t work or isn’t supported in their OS ver, but won’t update to the one that does out of fear it will not work. “problematic” is as often truth as it is an entire litany of other actual casues and the problematic item actually isn’t.

1 Like

And I am a Informatics graduate engineer. But I don’t really care about degrees tbh, as it is just a piece of paper, what you make of it is important.

In the end it was your decision to switch to a new system, even if lots of plugins wheren’t even compatible, and from an IT standpoint, that was just not a good one.
Imagine a company moving to a new system where your programs don’t run properly and you have to rely on several third party vendors who haven’t even adapted their plugins to the new system. That would be a disaster.

sometimes you don’t find out until after the fact. when doing some intial research M1 compatible was taken at face value to mean exactly that. its not like I can’t run in Rosetta2, but that does bring larger projects into the zone of needing to render more tracks out. not the end of the world.

if it were up to IT people desktops would still be running XP or win 7 because they are often vastly too risk adverse to keep things moving forwards. always afraid. vastly frustrating to deal with. its why one network kicked its IT dept out of the creative dept which took over its own support because they couldn’t install updates or apps as needed.

also not “lots of plugins” are a problem, just a a few. and there is a workaround so no its not a disaster, just a really annoying inconvenience.

This is not something Steinberg can control, so hopefully you have also sent messages to those plugin manufacturers.

Moved to lounge.

Sorry, but this is complete nonsense. EOS OS’s are a big risk for a company, especially when connected to the internet, and every halfway competent IT guy knows that. The general consensus is to always install the latest updates, but test them before if possible and necessary.
I literally don’t know any successful company around here, which still runs Win7 as their main OS.
Seems like you have a very limited view on IT departments mixed with bad experiences.

1 Like

@SteveOakley I got an M1 pro in Nov and I have about 1200 plugins and with Patchwork i can use nearly all of them.

Native M1 and VST 3 I have these effects available in C12:

And these instruments:

So there are lots of them about. The rest like UAD DSP and SSL I use the AU version via patchwork.


That site tracks them which is a big help.

There have been a couple that caused issues but nothing to speak of. Cubase 12 in Native mode runs amazingly well and I get 20% larger project’s in native mode. But then each plugin becomes more efficient so its a bit of an aggregate over time. It starts at 20% better and grows from there.

I have a project where I tested its limits and i have something like 114 track of which 30 are VSTi. I have about 200 plugins, Lots of sends to Fx tracks plus I have 10 group tracks all with plugins and master bus with plugins as shown in the screenshot. Thats only half the project. I know 114 tracks is not an amazing amount but If I had only 10 synth tracks I would have a lot more audio and sampler tracks with more plugins.

I think my 14 Core Intel desktop would had me freezing VSTi tracks way before that.

Of course I’m never going to use 30 synths in a real project but its good to know it can handle these things.

I have also used a fair amount of Kramer tape across the tracks too.

As you can see by the tab under the mixer that is only half the project.

Plus, if i want, I can work with that project on the train or a plane.

Now I’m not one of those ppl that says the M1 is bad in certain DAWs but has not really got any idea. Or they have heard it from someone’s cousins’ aunty:

Because I also use Cubase, Ableton, Luna, Pro Tools, Logic, MPC.

There was an issue with pro tools but that was fixed months ago. But i have found it to be amazingly stable now. Teething troubles way back in Jan in Feb but now its a no brainer to get and M1 or M2.

Anyway you will not regret getting your Mac Studio.

And for the Intel crowd, well they have exciting new CPUs too :slight_smile: though i have heard there is a bit of an energy crisis going on.