ARM64 support in Sonar and Next

[pedwal wally wally wha]

any specific plugins work ok?

[Wookiee]

1 hour ago, pedwal wally wally wha said:

sure, some will work, other won't, but it's a bit like swapping to linux right now, all very well having the host work but what about all the plugins we've bought?

would be nice to know which VSTs the team have tested with (i'm assuming all the bundled plugins work)

You infer that it is the teams/Cakewalk responsibility to ensure someone else's product works with theirs. Why? There is nothing they can do if they don't, can they? They obviously make best efforts to ensure that their software is compliant with the standards of ASIO, current Direct X, VST 2/3, the current MIDI requirements, the currently supported OS's, the majority of Graphics standards. 

What I personally think you should be doing is asking the plugin creators what plugins work on the ARM architecture, that is the real first question to ask.

Then, and only then, if they say they are ARM compatible, but fail in you chosen host product, do you ask that products creator to resolve the issue. 

You are inaffect asking Cakewalk to ensure that their product runs on all the permutations of potential PC hardware combinations, plus test all third party plugins. When we know full well that Cakewalk, applies the latest SDK libraries to their products, but frequently third party creators don't test their products on all other potential hosts. I know this for a fact because when I have approached a number of third party plugin producers with errors. Their response is "Oh we don't test on xwz hosts." The most interesting thing with those plugins is, the Cakewalk team have identified the issue in the plugins creators code, and supplied them with the fix, whilst building a workaround into Cakewalk's code just incase they don't fix it.

[pedwal wally wally wha]

just asked which plugins they tested with, keep yer wig on

[Wookiee]

1 minute ago, pedwal wally wally wha said:

just asked which plugins they tested with, keep yer wig on

No you are inaffect requiring them to do tests. I have a good idea why, you don't ask the creators of the plugins but my paws are tied.

[Noel Borthwick]

5 hours ago, Grebz said:

What about third-party plugins? When you switch to an ARM-based computer, you can now use Sonar's ARM version, which is great, but do the plugins work somehow? I guess not, unless there are specific, available ARM versions of these plugins?

We're building Sonar as an ARM64 EC app which means its "emulation compatible". IOW it will run either native ARM64 plugins or normal X64 plugins in Prysm emulation mode. Prysm is Microsofts emulation layer that is part of the OS which converts between the X64 and ARM64 instruction sets.
All DAW's that host plugins or any third party libraries need to be ARM64 EC because otherwise these components will not load. Its very slick how Microsoft has implemented this so that it works seamlessly with classic X64 components.

The main caveat is that you cannot load X64 drivers on an ARM64 machine. You need native ARM64 drivers for that since there is no compatibility layer at the kernel level. In short, all normal plugins should work fine unless they do something dumb like check the OS version and fail.
We don't need to do testing with plugins on ARM, Its up to vendors to do their own testing. In my experience ARM64 works fine for all the plugins I tried due to the built in emulation layer. In fact you can see the TH-U plugin in the demo that Qualcomm put out showing Sonar on ARM. No changes were made to TH-U for that to work.

 

[Noel Borthwick]

3 hours ago, Wookiee said:

You infer that it is the teams/Cakewalk responsibility to ensure someone else's product works with theirs. Why? There is nothing they can do if they don't, can they? They obviously make best efforts to ensure that their software is compliant with the standards of ASIO, current Direct X, VST 2/3, the current MIDI requirements, the currently supported OS's, the majority of Graphics standards. 

What I personally think you should be doing is asking the plugin creators what plugins work on the ARM architecture, that is the real first question to ask.

Then, and only then, if they say they are ARM compatible, but fail in you chosen host product, do you ask that products creator to resolve the issue. 

You are inaffect asking Cakewalk to ensure that their product runs on all the permutations of potential PC hardware combinations, plus test all third party plugins. When we know full well that Cakewalk, applies the latest SDK libraries to their products, but frequently third party creators don't test their products on all other potential hosts. I know this for a fact because when I have approached a number of third party plugin producers with errors. Their response is "Oh we don't test on xwz hosts." The most interesting thing with those plugins is, the Cakewalk team have identified the issue in the plugins creators code, and supplied them with the fix, whilst building a workaround into Cakewalk's code just incase they don't fix it.

Correct. Its not Cakewalk or any other DAW vendors responsibility to test every plugin in the universe. We test with the big suites and otherwise follow up when there are specific customer compatibility issues that are proven to be DAW specific problems. In any case this mostly doesnt apply to ARM 64 because Microsoft writes the emulation layer. If someone encounters a problem with a plugin not working on ARM, the first contact should be the plugin vendor.

[Noel Borthwick]

3 hours ago, pedwal wally wally wha said:

just asked which plugins they tested with, keep yer wig on

We tested with the plugins we ship with and some of the normally used plugins like NI stuff etc. Thats like asking which plugins have you tested that work on Windows 11. Its not our call.

[Noel Borthwick]

5 hours ago, pedwal wally wally wha said:

Early tests suggest that many x64-based VST3 plugins, including those from major manufacturers like Native Instruments and Waves, can be used on WoA, but iLok-protected plugins might not work, according to Steinberg Support. 

Well yes - ILok installs a driver. If they don't support WoA then the activation is not going to work. Has nothing to do with plugins themselves.
Besides drivers, there is nothing special required for running X64 code on arm for the most part (barring bugs in Microsoft's Prysm emulation layer itself). I found a few issues while porting and reported it to Microsoft.

[Noel Borthwick]

4 hours ago, msmcleod said:

From my conversations with Noel about this, unlike MacOS which forces you to use ARM64 plugins if you run as ARM64, and forces you to use x64 plugins if you're running in Rosetta,  ARM64EC will allow you to run a mixture of ARM and x64 plugins. 

What I'm not clear about is whether ARM64EC will run only ARM64EC & x64 plugins,  or ARM64, ARM64EC and x64 plugins.  I suspect its the latter though.

There will be a small performance  hit when running x64 plugins on an ARM machine though, as it'll be emulating the Intel code.

The performance hit is miniscule. In fact in some cases Prysm does an admirable job and it may even result in improved performance since its running ARM instructions not X86. From a battery life POV it will definitely use less energy running the plugin under emulation than an equivalent laptop on X86.