Tracking Apple Silicon Native Hosts, Plugins, Effects

[Rickskii]

Not sure if this is old news but just noticed silicon native beta VST3 version of Serum and Serum FX in my account.

Check the database. That's been posted since February.

I am not talking about serum being new to silicon. I was saying that serum is now VST3 silicon. The update I saw in my account was dated 4th Nov 22.

[Fleer]

By far the best standard is set by FabFilter. They were very quick to release Intel Mac plugins when that change happened eons ago (granted, they only had two plugins out back then) and again super fast in adopting M1 support across the whole range and also updating the older previous version so as not to force people to upgrade!

Yep, kudos to FabFilter. To anyone starting out ITB asking for the best way forward, there’s one company ruling them all.

[teilo]

Not sure if this is old news but just noticed silicon native beta VST3 version of Serum and Serum FX in my account.

Check the database. That's been posted since February.

I am not talking about serum being new to silicon. I was saying that serum is now VST3 silicon. The update I saw in my account was dated 4th Nov 22.

Ah, my mistake. Yes, that is new. Bonus for the native Cubase and Komplete Kontrol users.

[Eight4aWish]

Has anyone tried the Sylenth1 beta via Komplete Kontrol? It would be great to know if old nks files work because the vst2 > vst3 has been coded into the vst3.

[eagle007]

I really do not get why some companies take so long to do the ARM versions. They make it look like it is rocket science!

The reality is, that it's not. I had to move my C++ codebase to ARM64 this week. Server software to run and manage Unreal Engine, heavily Muti-threaded with embedded HTTP(S)/API server, build on my cross-platform framework created for a 3D game. So it's quite a code base.

The most time consuming was setting up the Mac mini development environment. After that it was a 1:1 compile and everything ran without a single bug or compiler error. Which of course makes absolutely sense as ARM64 uses exactly the same memory layout as Intel x86_64.

The only tricky part can be assembly optimized versions that use advanced vector instructions, which cannot be converted 1 on 1. But nearly no plugins use this. The only one I know of that could not run on my Mac cheese grater due the lack of AVX support was Massive, and even that is now native.

[machinesworking]

I really do not get why some companies take so long to do the ARM versions. They make it look like it is rocket science!

The reality is, that it's not. I had to move my C++ codebase to ARM64 this week. Server software to run and manage Unreal Engine, heavily Muti-threaded with embedded HTTP(S)/API server, build on my cross-platform framework created for a 3D game. So it's quite a code base.

The most time consuming was setting up the Mac mini development environment. After that it was a 1:1 compile and everything ran without a single bug or compiler error. Which of course makes absolutely sense as ARM64 uses exactly the same memory layout as Intel x86_64.

The only tricky part can be assembly optimized versions that use advanced vector instructions, which cannot be converted 1 on 1. But nearly no plugins use this. The only one I know of that could not run on my Mac cheese grater due the lack of AVX support was Massive, and even that is now native.

From what I understand (and you could probably enlighten me on this), the issue comes with old GUI frameworks that developers have been patching with school glue and workarounds for years to match any Apple requests to modernize. This is at least NI's story, they say that their GUI frameworks are in some cases based on 15 year old code and not the same code for all products etc., so it's not been a simple port for them because the entire interface has to be updated to modern Mac OS etc. standards.

So in the opposite case, developers that had recently updated their GUIs are having a much easier time to port, i.e. Arturia, MOTU DP etc. or ones that have a standardized GUI like Fabfilter, Melda etc. If all that is the case the ones that shock me are iZotope and VSL for instance who both have modern looking GUI's but are either dropping plug ins in leu of AS or haven't ported anything yet like VSL.

[Johnny!]

Often the main issue for many developers struggling to update is the use of some external libraries in their software, which are not being updated by their original developers, and are hard (or just don't have enough economic sense) to replace with something else.
Still - software shouldn't be made with "commit and forget" methodology. Actually such transitions as X86-->ARM make at least some devs clean up and update their code.

[JonathanLevine]

Auto-Tune Pro from Antares isn’t going to get updated for Apple silicon according to their support team, despite the fact they’re still charging almost $500 for it. They said to look out for Auto-Tune Pro X which will have native support upon release.

And with that news, I won’t be buying another thing from that company again!

Edit: Looks like it’s out now, what are the chances it comes out right after I post this comment!?

[teilo]

Auto-Tune Pro from Antares isn’t going to get updated for Apple silicon according to their support team, despite the fact they’re still charging almost $500 for it. They said to look out for Auto-Tune Pro X which will have native support upon release.

And with that news, I won’t be buying another thing from that company again!

Edit: Looks like it’s out now, what are the chances it comes out right after I post this comment!?

Auto-Tune Pro X is just the next version of Auto-Tune Pro after 9. It's not a new product. Yes, you will have to pay for an upgrade to v10, just like you paid for an upgrade to v9. I hear it's $175. Yeah, it sucks they didn't offer v9 native for existing owners, especially since this doesn't look like that significant of an upgrade. Supposedly they do offer a lock-in free update for those who purchased v9 within a given window.

In any case, they did update Auto-Tune Pro. It's not unusual for developers to wait till the next major release to add support, like Steinberg did with Cubase 12.

[JonathanLevine]

Auto-Tune Pro from Antares isn’t going to get updated for Apple silicon according to their support team, despite the fact they’re still charging almost $500 for it. They said to look out for Auto-Tune Pro X which will have native support upon release.

And with that news, I won’t be buying another thing from that company again!

Edit: Looks like it’s out now, what are the chances it comes out right after I post this comment!?

Auto-Tune Pro X is just the next version of Auto-Tune Pro after 9. It's not a new product. Yes, you will have to pay for an upgrade to v10, just like you paid for an upgrade to v9. I hear it's $175. Yeah, it sucks they didn't offer v9 native for existing owners, especially since this doesn't look like that significant of an upgrade. Supposedly they do offer a lock-in free update for those who purchased v9 within a given window.

In any case, they did update Auto-Tune Pro. It's not unusual for developers to wait till the next major release to add support, like Steinberg did with Cubase 12.

Well the most annoying part of it all is that they didn't update their former flagship product with native support when they should have. They updated every single other one of their products months ago, and left out V9 purposefully so they could use native Apple silicon support on their new flagship product as a way to entice people to upgrade. Never mind the fact that they decided to increase their perpetual license products' prices by 20% over the summer to try and make them so unreasonably priced that they trick you into thinking that their subscription model is actually a good deal.

I liked V9 but no way in hell I'm paying that amount of money to upgrade to X. bx_crispytuner seems like a good alternative, but Plug-In Alliance doesn't seem like they plan on giving native support to that plug-in anytime soon and other than that one I only have like 7 plug-ins left that aren't native yet (all or most of which come from Native Instruments, of course).

Oh well.

[alexekki]

Can we stop adding betas to the database? (e.g. Sylenth1, Relab LX480)

Most users don't really care about betas and only want to install actual release versions.

But once the beta is added to the database, you don't get notified of the actual release version in the recent updates section anymore.

[JonathanLevine]

Can we stop adding betas to the database? (e.g. Sylenth1, Relab LX480)

Most users don't really care about betas and only want to install actual release versions.

But once the beta is added to the database, you don't get notified of the actual release version in the recent updates section anymore.

Shouldn’t really make a difference. Most of the betas are completely usable with minimal bugs anyway. The point of the website is to show what plug-ins have native support and the version when that comes, beta or not.

[revvy]

Can we stop adding betas to the database? (e.g. Sylenth1, Relab LX480)

Most users don't really care about betas and only want to install actual release versions.

But once the beta is added to the database, you don't get notified of the actual release version in the recent updates section anymore.

I’m not gonna stop adding betas as welcomed as the Sylenth one to an open thread on a free internet forum, in the appropriate thread.

I’m not asking for it to be added to a database. If somebody searches this thread they’ll find it, which is what I do.

Unless they’ve already muted me, which you’re free to do if you want.

[rhye999]

Please keep adding betas!

[cadiz]

Can we stop adding betas to the database? (e.g. Sylenth1, Relab LX480)

Most users don't really care about betas and only want to install actual release versions.

But once the beta is added to the database, you don't get notified of the actual release version in the recent updates section anymore.

Shouldn’t really make a difference. Most of the betas are completely usable with minimal bugs anyway. The point of the website is to show what plug-ins have native support and the version when that comes, beta or not.

Fully agree!