Hey Steinberg does this mean that we’re getting an ARM native version of Nuendo sooner than later? And what about all the SB plugins, also ARM native?
I was poised to buy a Macbook M4 in a couple of weeks but now this changes things and it would be really useful to know.
Also since SB has had a hand in the fundamental coding of native ASIO and midi 2.0 can we expect improvements in the way Cubendo performs with the new hybrid cpu structure?
There is a Blog from a Microsoft Dev, that tells you more. It is from yesterday, so brand new.
Thanks for the link. Great, then its true! ARM64 Nuendo in the next few months. Interestingly they say it will come in Nuendo 13 which implies that v14 is several months off.
I was ready to abandon Windows due to the bugginess and performance of the new CPUs, but its great to see that SB has addressed the problem by getting in on the ground level with MS and finally getting them to acknowledge that low latency is a major prioroty for us and give Windows more musician based features. Many thanks to Pete Brown.
Also the new MIDI 2.0 stack looks like network midi and virtual devices will be further developed and featured.
Thanks Steinberg!
PS: Please finish Expression Maps 
My thoughts in another thread… this is indeed big news!
Very exciting news but what about plug-in developers?
There are so many wonderful plug-in’s that are now quite stable, in terms of VST3 compatibility so will this be an easy porting or migration because without those 3rd party applications, the whole effort would seem meaningless because it’s those developers that innovate over the longer term.
This is not to mention standards such as ARA.
You’ll be able to use many, if not most, Intel/AMD x64 plugins on Arm devices because Steinberg has compiled Cubase and Nuendo using Arm64EC. I covered caveats in the Cubase thread.
Pete
It will probably take a year or 3 for the main 3rd party ones to be ported.
But what it also means is Microsoft is giving some due attention to musicians and Steinberg is on the ground level with the code.
There was mention somewhere that after the ARM processor release they will turn their attention to x86. Of course much of the code base will port across or is being developed in parallel.
This affects our decisions to jump ship from MS to Apple. Rather timely.
Yes. We’ll work on the x86-64 64 bit versions after the Arm64 version is ready. Most of the code is shared. But also, Intel/AMD 64 bit currently has third-party solutions for most everything.
Pete
Microsoft
@Psychlist1972 One of the things we discussed on Gearspace is that Apple’s Bonjour (latest version from 2015) is starting to play up on our PCs. Because its so old obviously some advancements in Windows and CPU architecture have made it problematic. Yet VSL and iLok, two companies many of us use products from still wont adopt the Microsoft equivalent. VSL have said that it is a huge task to change over to it. Is there really such a big technical hurdle to switch over?
Will MIDI 2.0 somehow incorporate the MS equivalent of bonjour. What is the MS mDNS multicaster called?
Is there any company you can report that is starting to adopt it?
There was mention in one of the press releases about developments in MIDI 2.0 with virtual devices and network midi. Is there any more you can tell us about this? And how would they relate to Nuendo?
Lots of questions there.
The mDNS / DNS-SD support in Windows is just called mDNS and it’s an API like any other in Windows. There’s a WinRT API (which I use inside the MIDI Service for Network MIDI 2.0) and then there’s a regular Win32 API which takes a bit more to use but is structured like our other Win32 APIs. Both work the same and, IIRC, share the same guts.
The advertising part of Network MIDI 2.0 is just a small part of what is needed. The vast majority of the work is in processing the messages and connections that come in after advertising. All of that is done just using normal sockets. rtpMIDI is similar, in that the vast majority of the work is once you’ve connected.
To me, it doesn’t seem like switching over should be a massive amount of work, but having been a software developer for over 30 years, I know better than to speak for others or their code base. Maybe it is a lot of work, or maybe they use something else in Bonjour.
But mDNS is a standard protocol.
Anyway, Network MIDI 2.0 will have no Bonjour dependency. If we end up also doing rtpMIDI, I don’t expect it to have any Bonjour dependency either. I helped (in a small way compared to some other folks) create the Network MIDI 2.0 protocol, and also ensured it all works natively on Windows. That was a big part of why I had a prototype of it at NAMM two years ago. The protocol has changed a bunch since then as it approaches finalization, but the core still applies and works without Bonjour.
In the blog post I put out, I detailed the major release features, including Virtual MIDI devices and loopback devices. You may have missed it because you need to scroll down a bit:
Pete
Oh, and the Network MIDI 2.0 standard is just about to be voted on, so it’ll be ready almost certainly early next year.
I intend to have an implementation of it in Windows MIDI Services at NAMM in January. I can’t make that public (outside of the MIDI Association) until the standard is approved, but it’ll come out at our earliest release opportunity after it is approved.
Pete
Thats great news. Interesting you say, if you end up also doing rtpMIDI.
Does that mean Tobias Erichsen is involved? Will rtpMIDI then be used as the main engine for MIDI 2.0 Network MIDI?
rtpMIDI such a useful thing. I dont have bonjour installed and am quite happy to assign IPs and create sessions etc.
All the code in Windows MIDI Services is from scratch, because we’ve also made it open source at the same time, MIT-licensed.
No one else’s implementations have been used. Tobias is aware of the project, however.
Additionally, the transport model in Windows MIDI Services is completely different. Where the older APIs required everything be a driver, we use service plug-ins instead, and a very specific enumeration approach.
That’s how the USB MIDI 1.0 and USB MIDI 2.0 transports are built, as are the loopback and MIDI 2.0 virtual device (app-to-app) transports, and the diagnostics loopback and ping transports.
FWIW, the Network MIDI 2.0 standard is arguably cleaner and lower overhead than rtpMIDI. It’s a completely new transport, with no dependencies on the extra stuff RTP requires.
I suspect it’ll become more important than USB over time; there are already devices in development which implement it as well (I have a couple here). Apple is aware of the standard, and is also a member of the MIDI Association so I would expect them to have an implementation in macOS/iOS/iPadOS after the standard is approved.
Pete
The ‘preview’ editions of Steinberg products for ARM has its own info/help page (including redirect to actual downloads)…
Preview versions for Windows on Arm (WoA) – Steinberg Support
Very impressive to see that they not only have Cubase and Nuendo for ARM, but also Groove Agent 5, HALion 7, Padshop 2 and Retrologue 2. Another big congrats to Steinberg!
My own respect for the Steinberg devs just went up another notch. I’m not a Steinberg fanboy, and I’ve lodged plenty of criticisms (hopefully constructive!) over the years, and I use a bunch of other DAWs too, but this goes a long way to squash any doubts about Steinberg’s capacity for a modern, agile development process.
Just thinking about the vast amount of source code that all represents, and that it is all running on ARM natively now as a preview/beta, with what appears to be excellent low latency for those demos, and that they expect to have full release/support status by early 2025… it is all a bit shocking TBH. This is no small feat.
Bravo to the whole Steinberg team! If anyone doubts Steinberg’s ninja coding powers, they need to take a look at this ARM situation and ponder it for a minute.
And while no one doubts that Justin Frankel over at Reaper is also a coding ninja himself, and he’s also got Reaper running on ARM as part of this big music on ARM push… and all due respect to Justin and Reaper, which is a great DAW too (er-hem, and Steinberg still needs to copy Reaper’s perfect click-and-drag ripple editing, for god’s sake!), but Reaper’s codebase is a fraction of the vast sum total of Cubase, Nuendo, all those built-in plugins, plus Groove Agent 5, HALion 7, Padshop 2 and Retrologue 2… Wow.
JUST WOW.
Has anyone jumped in yet?
OK, being the tech nerd I am, i purchased a Samsung Galaxy Edge 2024 with snapdragon elite x to run Cubase in Windows Arm. I ran Dom Sigalas’s 3X3 benchmark and I could have 130 tracks, pretty impressive, my Macbook Pro could only handle 110. Of course this just using the Steinberg built in ASIO driver. I have an IX022 coming soon which is supposed d to have actual ARM drivers. My Allen & Heath CQ20B was recognized (no driver) but audio was garbled and useless.
I loaded a project with 24 audio tracks, 8 groups and 8 FX channels (with Steinberg reverbs and delays) as well as Superior Drummer 3, Cherry Audio CR78 and GX80, Kontakt 7 with Grandeur Piano and a bass and the project loaded in 9 seconds and worked perfectly! I had a Donner DMK-25-Pro connected although the latency wasn’t great.
All in all very encouraging though!
Just wondering (don’t know where else to ask) when the built in Windows Arm ASIO driver will appear? The Steinberg “built in asio driver” has way to much latency for real time work.
Hey Pete, I’m loving my new Samsung Snapdragon X Elite. I’m running Cubase 14 with a ton of external plugins but the big drawback now is ILOK support. Without it we’re very limited. Have you heard when that might arrive??
We’ve talked with PACE about iLok. I don’t recall if they’ve made any announcements of any plans, but they are definitely aware of the limitation on Arm64.
Pete