This is seriously overstating things.

Steve has spent years continuously optimizing his code base. It was already clean and relatively free of cruft compared to code bases of similar age.

If you are developing on something like JUCE and don't have an extensive amount of optimized assembly or AVX instructions to deal with, yeah, porting is fast. Likewise if your suite uses a common framework (ala MeldaProduction, FabFilter, uHe, etc.).

NI's code base is not clean, and they have the organizational problem of developers coming, developing a product, and then leaving, orphaning the code base. Brian Clevinger is doing his own thing now with Rhizomatic, so good luck every seeing Absynth native. But NI has maintained active development of Kontakt because it is their cash cow, and thus their first native release. But Reaktor? Massive? Massive X? Nowhere in sight.

Further, like many developers, they have the added problem of VST3, which is a royal PITA to get right. Since Steinberg is trying to pull the rug out from all native VST2 development on M1, many larger developers like NI don't want to risk the potential lawsuits. They also have no choice but to push out native VST3s, since Cubase 12 does not support native VST2s.

So there are a lot of economic and technical pressures at work that you have to take into account.

The fact remains though that a loooot of producers use Macbook Pros, and I'm assuming many will be upgrading to M1s within the next couple years. I'm genuinely curious when the pressures will actually force these large organizations to take the transition seriously.

VST2 used to be the standard development and testing target, which was then wrapped to other formats. But all of the developer workflows built around it are now at risk because of Steinberg's asshattery. I know for a fact that this has delayed a number of plugin releases, as developers have to put time into refactoring their code around a new standard target. Thank God for u-He and Bitwig leading the way here. I've tested the Surge XT CLAP build in Bitwig and it just works.

Is it? Steve Duda has no choice, his lunch is getten eaten by Matt Tytel and the folks at Native Instruments. If he wants to keep selling his $150+ plugin, he better stay on the cutting edge.

For everyone else though, I find it hard to blame them. Overnight you get a complete architecture change that you need to buy test hardware for, test-compile for ARM, find out what breaks, source new ARM-compatible libraries for what dod break, re-write some/all of your codebase to account for these changes, profile the performance difference, re-evaluate if the native version is worth it, then set up a testing and CI pipeline for a second architecture. Since most of these plugins are written with the notoriously fragile JUCE framework in C++, I can see why it's not just an overnight task to get it working on Apple Silicon unless you drop everything and make it your top priority.

Except it didn’t happen overnight, Apple announced it 6 months in advance. There has been affordable hardware available for porting since june 2020, almost 2 years ago. If a developer hasn’t gotten around to it by now, I doubt it is a priority for them, let alone their top priority.

Native Instruments straight up told me on facebook that they will not even test their plugins on any betas when they're available.

My point is that companies like Native Instruments have vastly more resources and developers than one individual developer, and still very few of their supposedly flagship products are M1 compatible. It's been a year and a half, and Massive X still isn't updated. You'd think they would toss at least one developer at it. I guess that maybe points to organizational rot more than anything (I guess Massive X generally being an outdated flop is also evidence of this), but the point stands.

BTW, if you have a license for Live 11, version 11.1 forward has a Universal build, so it can run natively on M1 Macs rather than through Rosetta. [0]

[0] https://help.ableton.com/hc/en-us/articles/115001261150-Mac-...

FL Studio also has a build for ARM, but it runs each non-ARM plugin in a wrapper which somehow uses an entire CPU core. After loading more than a couple of plugins I see something that is otherwise unheard of on my M1 Macbook - 1000% CPU usage and fans at full speed.

So I stick to running the app via Rosetta - higher-than-average CPU usage in general, but it means my plugins behave.

I guess the risk of data loss is acceptable .