Tracking Apple Silicon Native Hosts, Plugins, Effects

[teilo]

All DDMF software supports Apple Silicon, not just the above-mentioned (apart from Bridgewize, of course, which doesn't make sense anymore on a pure 64 bit system).

Thank you. Updated.

[discoDSP]

asb2m10 - Dexed FM synth verified as U2B (ARM and x86).

https://asb2m10.github.io/dexed/

[fgimian]

More Voxengo goodies, this time SPAN Plus - https://www.voxengo.com/press/voxengo-s ... eased-425/

[Ploki]

YES, Async enabled.
It's SO SMOOTH

also i never noticed WIDE view till now. great. happy

[Tronam]

Although still running under Rosetta, Image-Line's just released FL Studio v20.8.2 shows a massive performance boost. In my case previously unplayable projects are running very smoothly now, even at low buffer sizes. This bodes really well for their upcoming native build which they say is still a few months away. Interesting IL quote about this:

"The Rosetta compliant build is doing this by replacing Intel specific Assembly with ARM functions. So yes it contains ARM specific code."

[teilo]

"The Rosetta compliant build is doing this by replacing Intel specific Assembly with ARM functions. So yes it contains ARM specific code."

I'm glad they are working on a native port, but that response is pure BS. It absolutely does not "contain ARM specific code." These are exactly the kind of games that I hate that devs are currently playing with the term "native".

[Tronam]

"The Rosetta compliant build is doing this by replacing Intel specific Assembly with ARM functions. So yes it contains ARM specific code."

I'm glad they are working on a native port, but that response is pure BS. It absolutely does not "contain ARM specific code." These are exactly the kind of games that I hate that devs are currently playing with the term "native".

Oh really? Interesting. I don't know much about it, but whatever they did improved Rosetta performance by 2 or 3 times compared to v20.8.1. Perhaps it was something else which they're not sharing.

[Ploki]

They fixed bugs, sounds like previous version is broken.
Whatever runs under rosetta runs natively on an intel mac, it cant contain arm specific code

[Tronam]

They fixed bugs, sounds like previous version is broken.
Whatever runs under rosetta runs natively on an intel mac, it cant contain arm specific code

That makes sense, but I get the impression this is a debate over semantics because when they said "ARM specific code" I don't think they're implying the current version is ARM native at all. They make no claim of that and say it's still several months away. According to Image-Line the main reason why versions prior to 20.8 wouldn't work on M1 is because of specific x86 assembler optimizations which Rosetta couldn't translate correctly. They must know something about ARM functions to properly optimize it for translation.

[discoDSP]

According to Image-Line the main reason why versions prior to 20.8 wouldn't work on M1 is because of specific x86 assembler optimizations which Rosetta couldn't translate correctly. They must know something about ARM functions to properly optimize it for translation.

That's very likely what happened but it should be stated as Rosetta 2 compatible, not U2B. Stating it contains ARM specific code only happens via Apple's x64 to ARM converter. You be the judge about that.

Anyway based on Apple past actions Rosetta 2 should be removed in a few years and the developers who were advertising their products as "ARM compatible" will get a lot of pissed customers.

Sound Magic has updated Nameless Grand with U2B support at KVR database but after contacting the developer asking about native Apple Silicon compatibility he stated it's running via Rosetta 2 so he's likely to remove the tag until it gets a native ARM build.

Looks like we're going to see this misleading U2B tag trend happening for quite a while. No reply from KVR on this matter btw.

[Ploki]

That makes sense, but I get the impression this is a debate over semantics because when they said "ARM specific code" I don't think they're implying the current version is ARM native at all. They make no claim of that and say it's still several months away. According to Image-Line the main reason why versions prior to 20.8 wouldn't work on M1 is because of specific x86 assembler optimizations which Rosetta couldn't translate correctly. They must know something about ARM functions to properly optimize it for translation.

I haven't found anything that didn't work on Big Sur intel that didn't work on Big Sur M1 via rosetta tho.
If there's anything ARM specific it simply wouldn't work on Intel because there's no rosetta to run ARM on x86.

[Tronam]

That makes sense, but I get the impression this is a debate over semantics because when they said "ARM specific code" I don't think they're implying the current version is ARM native at all. They make no claim of that and say it's still several months away. According to Image-Line the main reason why versions prior to 20.8 wouldn't work on M1 is because of specific x86 assembler optimizations which Rosetta couldn't translate correctly. They must know something about ARM functions to properly optimize it for translation.

I haven't found anything that didn't work on Big Sur intel that didn't work on Big Sur M1 via rosetta tho.
If there's anything ARM specific it simply wouldn't work on Intel because there's no rosetta to run ARM on x86.

Right, but I'd guess the FL Studio application does a system check and knows it's running on Intel, so it uses different assembly code for those functions.

[teilo]

That makes sense, but I get the impression this is a debate over semantics because when they said "ARM specific code" I don't think they're implying the current version is ARM native at all. They make no claim of that and say it's still several months away. According to Image-Line the main reason why versions prior to 20.8 wouldn't work on M1 is because of specific x86 assembler optimizations which Rosetta couldn't translate correctly. They must know something about ARM functions to properly optimize it for translation.

I haven't found anything that didn't work on Big Sur intel that didn't work on Big Sur M1 via rosetta tho.
If there's anything ARM specific it simply wouldn't work on Intel because there's no rosetta to run ARM on x86.

Right, but I'd guess the FL Studio application does a system check and knows it's running on Intel, so it uses different assembly code for those functions.

Maybe. But it's still x64 assembly it's running. There are certain x64 instructions, such as AVX, which will not translate to Arm, since it's fundamentally incompatible with Neon. Honestly, this is no different than what any Intel binary does when it sees that the current processor does not support AVX.

[discoDSP]

TBProAudio has updated mvMeter2, ISOL8 and sTiltV2 with Universal 2 Binary support (verified for ARM and x86).

[discoDSP]

New updates from TBProAudio with AMM, dpMeter5, FinalLoud, gEQ12, LAxLimit and SLM2 as Universal 2 Binary (ARM and x86).