M1 chip Mac

I saw Apple has M1 stuff out already. And the prices are not even bad. Is Steinberg ready for these new Macs??? These new chips don’t work the same as Intel chips… what do you know??


I would wait for official statement, similar to this.

I’m very interested to see how this pans out.
I’m surprised no one with a pre release Mac mini has shed any light in the situation yet.

It all sounds too good to be true but on the other had you would expect Apple to move unless they could mitigate the problems ahead.

I’ve sen benchmarks and they look too good to be true but next week I guess we’ll find out.

I’m in the market for an upgrade and this might be it but I can’t make it my main machine without cubase support and 16gig limit

The current chip is about 1.1ghz… so I’d wait a few years until they improve their tech.
There’s a reason Apple ended the presentation with “give us a few years” and they only included it in the lower end of their lines.
Technically speaking, software should compile similarly if not exactly the same with just a few tweaks and support both intel and silicon chips but… they’re still pretty entry level

If you read into Apple’s advertising more, you’ll notice that their performance claims relate to performance per watt as opposed to actual general performance. General performance I think is really what is necessary for DSP and serious realtime audio. The advertising seems really misleading, but is a little disconcerting. My expectations are low, and I don’t expect M1 is ready.

However, are there any preliminary benchmarks that might be available soon? I am concerned about the future of the Mac platform due to the greater focus on energy than actual performance, but I am hoping to stay on Mac for audio, as I prefer the audio/MIDI stack on macOS.
In short, are there any insights, or are there any benchmarks in the pipeline? I’m curious how Steinberg is approaching the situation.

I wouldn’t worry too much about this… apple will continue to put out their computers with intel processors until their own chips match the speeds of their competitors. My guess the only reason they mentioned efficiency and not speed is because they’re pretty far from it now…

according to other developers though the switch isn’t that intense and when they start rolling out flagship machines with silicon it should be great.

We’ll see. I was hoping to get a new machine, but I’ll probably wait until the transition (i.e. no more choice) before getting an ARM machine. I’m also a programmer and unfortunately Apple’s extra restrictions are making it harder in that side of my life.

I am wondering if I should upgrade to a new intel-based laptop then. It’s probably too late since Big Sur is releasing this week, and there’s no way to downgrade to Catalina. I’m sure most software is still unstable on Big Sur.

Ok I’m not going to go too deep into this but been a software engineer will shed a little light on this for those less technical people.

The existing Mac range was power intel chips using what is known as the x86 instruction set (AMD also make x86 based chips which is why windows runs on both chips without issue). Now the new range will be power by Apple Silicon child which are base on ARM(RISC) this is completely different from x86 in fact its a lot closed to to what Apple using iPhone\iPad. This means that software will need to be rewritten\compiled very differently to run on the new M1 based MacBook’s. Apple have said there is a emulator layer that will allow older x86 software to run and be translated but this is never going to be 100% perfect.

This means software companies will have a bigger decision to make going forward, where previously the wrote there software in x86 and just compiled a version for Windows and then a version of Mac they will now have to write a mac specific version vs a windows specific version. Now whilst I don’t have any figures to hand it does seem that a great deal of mac owners use Logic Pro and of course Apple will ensure a new version of this is written for M1. Where the big question comes is for every software company how much of their sales are made up of Mac and would it be cost effective to continue supporting it with the new overheads.

Take Steinberg for instance say of all Cubase sales the split is 30% Mac, 70% Windows would it be worth setting up a completely new dedicated team to develop and support a Mac version. This has to be taken into consideration with what percentage of the Mac community use Logic Pro vs other DAW’s as well. Whilst there are a lot of reasons Apple has gone down the M1 route both technology and business I personally see there is a risk of it making Apple more insular from a software perspective like it was some 15years ago.

A couple things…

Steinberg doesn’t write code in x86, they write it in C++, or java, or whatever language(s) they use (I don’t know which, and don’t care). It then gets compiled into x86, and almost certainly already uses different compilers for mac and PC. I expect that for mac they use the excellent Xcode environment that apple provides for free, though again I don’t know for sure. I’m certain that apple will make it transparent, or nearly so, for a developer to take their existing code and compile it for M1 through exactly the same tools, simply by changing a switch or two. Until Steinberg gets around to compiling a dedicated M1 version, apple will have a simulator that will allow users to execute the existing x86 executables. Not sure how performance will be running under the simulator (they call it Rosetta) will be, we’ll need to wait and see on that.

Steinberg must already have a dedicated macOS team. Even though macs and PCs use the same Intel CPU, the APIs, graphics environments, etc. for macOS and Windows are completely different. The difference between x86 and M1 on the mac is probably much, much less than the difference between macOS and windows that Steinberg is already coping with just fine.

Remember, apple already did this once when they switched from PowerPC to x86. They understand the importance of the developer community. I expect that they will make this transition pretty painless and transparent.

P.S. - There may be some assembly language code in the steinberg universe that they would need to re-write by hand, but I expect that there is little or none of that.

Steinberg already added ARM/Silicon support in the VST SDK, and has invested time into building a Metal graphics backend. I think compiling for ARM is not that terrible. You may want to be able to add some optimizations here and there though.

Like i said i didnt want to get into languages etc and make this some techie conversation, writing for x86 vs ARM is like apples and oranges. Yes Rosetta is a interim emulator\simulator that will allow x86 to run but as you state at what performance and also will never be 100% accurate. Cubase is written in C++ and then compiled using the relevant platform compiler, some libraries are switched in\out depending on platform a small percentage of the code is platform specific.

There is no way of taking C++ written for x86 and compiling it for ARM\RISC is has to be written completely differently to work on a different architecture. So as i stated given Apple are the only people at this time on ARM\RISC this would mean writing a version specifically for their platform until some other manufacturer builds an ARM\RISC based platform. Amazingly Microsoft actually built a version and released an ARM\RISC version of windows on Surface Pro X but the uptake of this has been very slow at present.


The only big issue I see right now is that it’s not comparable to the current top-end Intel chips. They’re more efficient in their category, but it’ll be a few years before I look to upgrade to something for a production environment.

Apparently, they are faster at compiling code in xcode though, which I do for a living. So I may upgrade sooner than later if benchmarks can get close.

Sure there is. Cross-compilation. You don’t need to rewrite your C++ code to re-compile the source for another platform. That only comes into play if you used ASM/platform-specific code. However, sure, you might want to add some platform-specific flags and change some things around if the specific platform has some extra instructions you’d like to use for more performance.

ok im wrong, 30+ years as a software engineer and having worked for the the major software companies and on pretty much every platform\architecture known its as a simple as write something in C++ and then just compile it or what ever platform I want it on. Software programming is so easy and straight forward what have I been doing for so long LOL

*note to Steinberg all you need to is take the Cubase source and compile for M1 and bingo you have the new Apple Version, also could you do a compile only Debian as well please should only take a few hours compile time.

I’m not questioning your experience, but regardless of what you think, C++ is actually a high-level programming language. It can be compiled for any platform with a C++ compiler toolchain, What you’re talking about is platform-specific intrinsics. Like SIMD instructions. Or inline ASM. Maybe you’re experienced in embedded programming. You’re incorrect about not being able to compile. You are correct that you need platform-specific tweaks and considerations for maximum performance.

I can compile hello world on ARM and x64 devices for sure.

As I said above, Steinberg is already investing time into Mac-specific technologies such as Metal graphics and the ARM chip (for VST). The point is that we need not be worried about whether they’ll put in the time.

There are a lot of other things you have to do to port software this complicated. While C++ is “actually a high level programming language,” the programming language doesn’t dictate whether or not the port to arm will be adversely affected by dependencies not having been ported to ARM.

For example, there is Cubase Pro, and then there is WaveLab, and SpectraLayers, and Groove Agent, and HALion, and everything they depend on… and everything those things depend on.

There is also the possibility of there being a lot of inline assembly (or assembly language modules) used in parts of the DAW, Plugins, subsystems that are very performance-sensitive, as well, though we cannot say for sure if this is the case (since we don’t have the code). Assembly Language is notoriously non-portable between processor architectures. You cannot recompile an x86 Assembly Module for ARM. It won’t work.

If third party libraries are used, then those would need to be ported or the code would need to be redeveloped to eliminate the dependency.

Et cetera.

My guess is that Rosetta is going to be the interim solution, for a good minute.

I severely doubt Steinberg will want to release Cubase Pro for ARM macOS before most things in the package are also ported over. There is a lot of dispirate pieces cobbled together in that package, too.

However, my guess is that Apple has given them access to pre-release builds/prototypes and they’re simply under NDA. They’ve likely been working on this for a while, already.

However, this is not the type of application that you can simply recompile and get to work off the bat.

I never said that they could compile immediately and have something magically. Of course there’s effort involved. I was responding mainly to the post suggesting that Steinberg might ditch macOS because it’s too challenging to re-write for ARM. My point was that not literally everything would need to be rewritten, and that Steinberg was likely already working on porting to the new platform.
Are we on the same page now? :slight_smile:

Preliminary Geekbench numbers - for what they are worth - are looking much better than entry level, and it’s clocking in at 3.2 GHz. We still have to wait for real world benchmarks of course, but this is very promising so far:





lol WHAT… that is promising… someone mentioned it was a lot worse… we’ll see how it scales in a couple years… I think it’ll take them a bit at least to get something seriously competitive

One issue that I see never mentioned about this new Apple platform is the lack of device driver support for audio hardware.