M1 chip Mac

You might want to reconsider this post. It’s certainly not (about 1.1ghz)

that was based off their claim

Apple claims it gives the highest performance per watt in a CPU, and the four high-efficiency cores deliver the same performance as a dual-core Intel-based MacBook Air

… that’s 1.1GHz…
apparently the tests are showing differently so we’ll have to wait until people actually get their hands on them and give more test results… but so far it’s looking a lot better than 1.1GHz … we’ll just see what extended performance looks like without a fan.

Comparing GHz between two fundamentally different CPU designs and philosophies does not really make any sense. It’s like comparing revs on car engines to compare speed, without knowing which gear the car is in or which car it is. It’s all down to how much ‘work’ the chip can perform per clock cycle . The only way to get a proper comparison is to use benchmarks, e.g. Geekbench results, that is calculated based on tasks of a certain workload.

I too have 30+ years of experience as C++ software developer and I have never had to do a complete rewrite of any of my code in order for it to run on different hardware. Of course there had been issues thad had to be addressed, but the whole point of using a high-level language as C++ over an assembly language, is that you do not have to write specifically for a certain hardware. Being cross OS is actually harder to achieve due to the different API’s for e.g. file access, driver access, GUI and the like, but that have already been handled by Steiny.

Apple have done this before, and in convinced that they have provided alle the necessary tools in Xcode to ease the transaction to Apple Hardware. As I read it, Rosetta 2 converts the X86 binaries to M1 on the first launch, so the actual porting/X86 emulation is done at runtime for apps not compiled natively for M1 giving the developers time to optimise and fix whatever needed before compiling natively vor M1. Also the API’s are more or less the same on Big Sur as on Catalina, so no major rework has to be done on that account.

Of course there will be quicks to be ironed out and have Steiny used any assembly code, it must have to be rewritten to be abe to to be used on the new hardware.

ok

Someone who understands that the black mystic art practiced by software developers, we might make it look easy on the outside but trust us it isn’t. The point most people seem to miss though is that whilst Apple have been on the x86 architecture writing for both Windows and MacOS became a hell of a lot simpler, this was one of the original reasons that Apple switched to Intel to open up the appeal of writing for Mac to what had been Windows only software companies. Now with the switch away from Intel and to ARM Apple have in effect closed that door again, granted some software companies it wont effect as their Mac sales will justify any costs involved in migrating to ARM but for others it could be axe to their Mac or Windows side.

Imagine you had a software company that right now delivered to both MacOs and Windows and you customer split is 25% Mac, 75% windows. To make you app M1 certified you estimate you need to take on 3 Apple\ARM Engineers and they can get all the work done in 3 months. Going forward will mean maintaining 2 separate codebases and support\fixing will potentially need to be done in 2 places etc. So simple question then is does the 25% revenue generation your get from Mac cover and justify this extra cost.

My original question though is ARE Steinberg working on porting it, say they make $100k a year from the mac version but to port it means taking on new engineers to do the port plus more overheads to support going forwards the x86 version and ARM versions. So to port it and continue development is going to cost say $200k a year in manpower and $50k in overheads.

If it were your business what would you do? you cant dismiss the economics and practicalities that ripple from the decision to move to M1\ARM and only time will tell…

If you don’t do it then you are officially exiting the Mac market for good. So I guess the question is. Is it worth just going windows only?

I think they’ve been working on an ARM MacOS Cubase already with some decent probability, as evidenced by support for ARM in the VST SDK. No one can say yes or no, other than a Steinberg software developer or an otherwise Steinberg-employed person.

Here are some more tests I found: SPEC2006 & 2017: Industry Standard - ST Performance - The 2020 Mac Mini Unleashed: Putting Apple Silicon M1 To The Test

The base MacBook Air is showing results on a par with the Mac Pro. Holy cow

Rosetta 2 is neither a an emulator nor a simulator - it translates an x86-64 executable into an Apple-Arm executable off-line - once the process has run Rosetta 2 is not involved again - you are now running native Arm instructions which have been derived from the x86-64 instructions.

There is a lot of truth and a lot of inaccuracy in the posts here as well. Veteran C/C++/Assembly/Mac OS/Windows/Linux developer here. Also have knowledge of DSPs and filtering theory, virtual machines and binary translation. Wrote a phase vocoder from scratch in C many years ago, so I know how hard this stuff is and how CPU intense it gets.

Yes, I’m sure one could cross-compile Cubase onto ARM with some effort. Maybe this is already being done, in light of the fact that one would want plugins to run on Apple’s portable platforms. The problem is that you lose any custom acceleration you were getting from Intel’s SSE instruction set specially coded for applications like doing codec / filtering / limiting and mixing for your VST plugin. And I guarantee you any plugin worth its salt probably had custom handwritten code - even if it is not in assembly language, using high level Intel specific intrinsics. Those things will not be portable, nor easy to recompile, and while technically, they could be “translated” by a Rosetta type cross-compiler or JIT binary translator, the reality is performance under that scenario will entirely suck, and just in the places where performance was supposed to be critical in the first place. This is not something you get for free by simply compiling with -march=ARM, this is stuff that needs to be redone by humans and will take some time. There is some SIMD magic going on with ARM, if the M1 supports Neon, but it is an entirely different set of magic than one would have with Intel and nowhere near as fancy (compare - Druid magic vs. Sun Magic), so if that is not ready yet, the best bet is probably going with the barebones algorithms, hopefully optimizing for the architecture specific cacheline sizes and leaving the register scheduling to the compiler and CPU itself. Or using the GPU - which will take even more developer time and very mature, battle tested toolkits - which may or may not be there yet.

I’m moderately concerned about this, considering I own a Yamaha THR10X which is supposed to interface with Cubase with a custom ASIO driver - but pretty sure that driver only works on Intel based machines right now. Nevertheless, I am hopeful that Cubase will run on M1 chips in the very near future, and somewhat optimistic that the ASIO driver can be ported as well - because in theory it should just be presenting USB data to Cubase in a format that Cubase understands natively, and that is not actually that hard of a task. Unless of course all the APIs have all changed and the support burden becomes more than the benefit.

Long story short, I pre-ordered an M1 based Mac Mini and will keep you updated on how my travels go. At the very worst, I may have to go do contract work for Steinberg or Yamaha to port the driver myself. :wink:

yup that means that any app runs already at a pretty workable level. yesterday I watched Lon.TV, a popular tech youtuber playing games on a Macbook Air that were converted using Rosetta2. Dolphin Emulator, Steam Games, Rocket League on highest settings - all running smoothly. Converting and rendering videos from Final Cut ran faster than a Mac Mini 2018 and a Macbook Pro 2016.

On top of that, developing a “native” version of known apps, such as Cubase, Dorico, Wavelab, ect. can be as easy as them just re-compiling everything with the new Xcode - if that’s what they are using. Chances are there will be an M1 compatible version pretty quickly. Google Chrome for Apple Arm is dropping today. Others will follow.

I am almost tempted to buy a mac mini for my studio but I am pretty sure there will be “bigger” macs in 2021. General concensus is: Starter - buy away! Professionals with existing tools - wait a little

I didn’t know that, so it’s not like a virtual machine/wrapper? (Which is what i presumed)

It recompiles/translates the binary to run native ARM? Is that for sure?

Yes, there’s a translation step. That’s why it takes longer to launch the first time. I believe there is also some runtime processing though.

I was on the Mac platform when it was Motorola

Then they went PowerPC, and EVERYTHING had to be switched over. I re-bought software / paid upgrade fees.

Then they switched to Intel…same story. Rosetta was a crutch at best until everything was ported over natively. More fees, more upgrades, more plugins lost for periods of time…only to be re-purchased to get RIGHT BACK where I was before…just a little more uumph under the hood.

As soon as Apple announced they were moving over to ARM…I started the transition to PC. I was on an 8 year old Mac Mini, and now am running a PC. I am using Cubase as my substitution for Logic (which I love and am comfortable with), and so far the move has been pretty smooth and I like the workflow. I am running a REDNET Dante system which is fairly hardware agnostic and just needs a PCIe slot. I am not complaining the Mac Mini lasted that long…but Apple recently announced it was dropped from any future OS…and I just don’t trust them when they say it will all ‘work’.

Much as I love the Apple ecosystem, I am tired of re-configuring and re-purchasing hardware and software just to get back to status quo functionality because they want to change the standards…and they love to change standards: NUBUS → PCI / PCIx → PCIe → Thunderbolt → PCIe, Apple Desktop Bus → USB - > Firewire 400 → Firewire 800 / USB → USB / Thunderbolt, Floppy → CD → Superdrive → USB port. Plug → Magsafe connection → USB port.

Exactly but if it were your business your would do it if it is cost effective to do so, your wouldn’t do it to lose money and this is exactly the question that Apple is forcing every software vendor to take now as a result of their move to a new architecture. Ultimately as well wouldn’t Apple prefer it if you were using Logic rather than a 3rd party DAW

I think Apple would love to ditch Logic altogether…like they did with Aperture. Head on over to the Apple.com site and try to navigate to the Logic Pro page. Where is it? You either have to search for it…or follow one little hyperlink 3/4 down the page under “Pro Apps” And they JUST released an update as well…

Probably have too big of a user base to just drop it though. I remember when they bought Emagic…I wondered why they didn’t just buy Avid instead…probably didn’t have the cash at that time. I think it would have been a better fit…hardware / software integration is Apple’s strong suit.

The Emagic Logic controller was a big part of their software/hardware plans at the time so it did make sense as buying Emagic came with the Mackie partnership that was already established. And to be fair, they’ve had an incredibly long run with the Mackie protocol - even today you can run a C4 with Logic.