Do Plug-ins have to be "blessed" as "Apple Silicon Native"? to run properly on M1xxx?

[alexdingley]

I'm not sure I'm 100% reading everything correctly as I look up app & plug-in compatibilities, ahead of my next (later this year or early next year) computer purchase... and I'm wondering if anyone else knows the definitive answer (or if my question is what's broken):

I know that "apps" (like our DAW's and control panels) plus "drivers" are where a lot of the attention is focused for "is it Apple Silicon native?" discussions. Like, Pro Tools just came out with their new 2022.4 versions (but they're still listed as "Works via Rosetta 2", which is fine I guess... but I'm exited for when it's finally native). What I'm curious about is 3rd party plug-ins:

When a vendor says "Works on Apple ARM" or "Works on Apple Silicon", does the plug-in also have a designation of either "rosetta2-required" or "apple silicon native"? — or is a plug-in a less-involved bit of code, to the point that it just maybe needed some tweaking, and it's gonna run however your DAW/Host is running (meaning, it'll be handled by Rosetta2 if your DAW is, but it'll be handled by Apple Silicon native processing, if your DAW is).

Does my question make sense?

I still see a few of my mainstay plug-ins NOT listing compatibility with Apple Silicon, and not yet listing themselves as Monterey Compatible, so I'm still gonna hang back a while regardless, but I'm trying to make sure I have my info straight as I vet my apps & plug-ins ahead of the eventual purchase.

Like DMG: Limitless (the multi-band mastering limiter) — the requirements page says: "Mac OS 10.7 or newer, including Catalina (10.15), Big Sur (11) and Monterey (12) • Intel or Apple Silicon Mac", but it's not calling out "works under Apple silicon so long as your host is using rosetta2", but I'm not clear if that's a distinction that needs to be made.

if anyone knows with more certainty, I'd love to hear them weigh in on this.

[Nick Sevilla]

I am upgrading the studio computer this Summer.

By then, Nuendo 12, which just came out, will be more stable. It has official M1 Silicon support. Before that, Nuendo 11 was running under Rosetta, and not stable. I am reading on their forum tons of initial issues, most I am sure are user install errors and the like. A few plugins have been identified as culprits as well. You may want to check on their forum as to which plug ins they are finding to not be working with M1 Silicon.

https://forums.steinberg.net/c/nuendo/11

As to plug ins, Waves already officially supports M1 Silicon. So are some other plug ins manufacturers.I am sure by the Summer most of the ones I own and use should be there.

If you are unsure about a plugin, contact the company directly. Don't take advice from whoever out here in the wilds.

If you are considering getting an M1 Silicon chipped Mac, at least study the plugins and DAWS you actually use first, to see if they are already officially supporting the new chip.



This is IMPORTANT:

If you are going to run anything on an M1 Silicon chip, make SURE both the DAW and the plugin are both officially supporting the chip. Otherwise it will be very unstable. Many people are mixing and matching, and crashing.

Good luck with the upgrade. I'll post on here once I am on the new computer. It will be a maxed out Apple Studio, as it is cheaper than their tower, and I am not interested in using CPU cards at all anymore.

[Nick Sevilla]

Like DMG: Limitless (the multi-band mastering limiter) — the requirements page says: "Mac OS 10.7 or newer, including Catalina (10.15), Big Sur (11) and Monterey (12) • Intel or Apple Silicon Mac", but it's not calling out "works under Apple silicon so long as your host is using rosetta2", but I'm not clear if that's a distinction that needs to be made.

if anyone knows with more certainty, I'd love to hear them weigh in on this.

Their page specifically states: "All DMGAudio plugins are compatible with M1/ARM macs (native)"

That means it is not using Rosetta. However, if you try them under a Rosetta running DAW, it will likely crash.

[kslight]

I have nothing to add on the audio end, but I have had an m1 Mac mini at work since September, I do graphic design and when it first showed up about half the Adobe suite was not native, but now it is. A couple things worked a little quirky very early on but they were shortly resolved and since everything is fully native it’s been awesome.


It’s kind of embarrassing that Avid hasn’t updated to be m1 native yet tbh, they’ve been out for a year and a half. I would be pissed if I was a paying subscriber to pro tools.

[The Scum]

For simple applications, it should be a matter of throwing a switch in Xcode and rebuilding...M1 native, X86 native, or both in one package.

But PT might be anything but simple. Depending on how their dedicated cards work, they may have some x86 specifics baked in that will be hard to untangle. And I don't know anything about the commonality of PT native vs HD. There are also a handful of audio-domain x86 details that aren't needed on ARM (the ol' Pentium denormal issue, to start, and anything that was hand-optimized to use x86 vector operations will need to be ported to the ARM equivalent).

I did some PCI/PCIe driver work last year, getting legacy cards to work on a Raspberry Pi. Some cards came across OK, just a bit of tweaking to the host OS and driver. Some cards use the x86 I/O space, which is ARM-incompatible (like, legacy stuff back to the 8088), so were a dead end.

Same for plugins - it's possible to write one that's CPU agnostic - but to squeeze the end of performance from the hardware, it might have been adapted such that it's highly dependent on the CPU family it was written for...and rosetta emulation of that might be a real mess.

My gut feeling is that Rosetta is going to be a bottleneck, and that all native code is the way to go. And using Core Audio (made by Apple with M1 support out of the gate) instead of the other drivers.

[analogika]

Well, a plug-in has to be recompiled to run on Apple Silicon to be "native", otherwise there is no other way to run it than to translate it through the Rosetta layer.

However, that generally means that the host DAW also needs to be running in Rosetta mode to see that particular plug-in.

When a vendor says "Works on Apple ARM" or "Works on Apple Silicon", you have no way of knowing whether that means "tested to work in Rosetta 2" or "recompiled to run natively on Apple Silicon".

Most vendors specify exactly which it is in their tech specs.

[alexdingley]

Their page specifically states: "All DMGAudio plugins are compatible with M1/ARM macs (native)"

'doh! Okay, this example is now a bit embarrassing: For some reason, my brain COMPLETELY ignored the first line, and my eyes were drawn to the more-general "Intel or Apple Silicon Mac" — which (now that I read that first line) is kinda redundant, to a degree — unless they're trying to dissuade the last 9 PowerMacG5 users on the planet from attempting to use their plugins)

[The Scum]

Apple actually have decent developer documentation regarding the move to Apple silicon.

This page has a section specifically addressing plugins:

Universal plug-ins are essential if your app loads those plug-ins directly into its process space. Code running in the same process must support the same architecture. If your app attempts to load a plug-in with an incompatible architecture, the system reports an error at load time.

"Universal" being a program that contains both X86 and ARM code inside.

So the breakdown is something like:

• ARM native host needs ARM native plugins.
• Host under Rosetta needs Rosetta compatible plugins.

They also have this guide specifically addressing the problem in audio applications. To summarize: compile universal binaries, and migrate up from the Carbon component manager.