Quad Cortex plugin support officially goes from "soon" to "eventually"

Lysander

Shredder
Messages
1,864
Fresh off the presses:


TL;DR: NDSP is prioritizing work on their plugins, i.e. native Apple Silicon-compatibility, and porting new features to older releases.

"Plugin compatibility requires a lot of work. Embedded systems and architectures differ significantly from x86 processors and consumer computers in general, which means code needs to be ported to ensure optimized performance on the Quad Cortex. Our software teams have prioritized porting our plugins at full speed while only a handful of our team members remain working on new products.

Additionally, only recently have all the plugin formats been made available for development for Native Apple Silicon support. Therefore, the plugins we have already released with Native Apple Silicon support will have to be updated again to support the missing format (AAX), and had we updated all of our existing plugins, they would have to be updated again to include this support, which would have involved a significant time commitment from the development team.

In light of this, we have decided to prioritize making all of our plugins Native Apple Silicon compatible to provide you with an improved experience while we continue to work on bringing the new core features (such as transpose and the doubler) to older plugins and delivering plugin compatibility. A large portion of our development and QA teams will halt work on other projects to expedite this, and we hope to deliver the updates within the next couple of months."
 
Last edited:
I don't understand why they just say "not going to happen" and be done with it?
They are not going to lose customers, people who were waiting for plugins at launch already sold their QC long ago.

Quote:
"Embedded systems and architectures differ significantly from x86 processors and consumer computers in general".

They know exactly the amount of astronomical and unprofitable work it will require, so WTF are they holding on to exactly?
 
"Embedded systems and architectures differ significantly from x86 processors and consumer computers in general".

They know exactly the amount of astronomical and unprofitable work it will require, so WTF are they holding on to exactly?

Yeah, none of this is easy. Fractal and L6 built their own frameworks so they can run the same algorithms on different architectures (DSP and CPUs), but it took them years to get there. It is a shitload of work.

What pisses me off a bit is a certain CEO advertising plugin support as trivial... 2 years ago now.
 
Yeah, none of this is easy. Fractal and L6 built their own frameworks so they can run the same algorithms on different architectures (DSP and CPUs), but it took them years to get there. It is a shitload of work.

What pisses me off a bit is a certain CEO advertising plugin support as trivial... 2 years ago now.
Agree. No doubt this isn't easy but then again, they promised it at launch. I have no sympathy
 
Doh!

“In light of this, we have decided to prioritize making all of our plugins Native Apple Silicon compatible to provide you with an improved experience while we continue to work on bringing the new core features (such as transpose and the doubler) to older plugins and delivering plugin compatibility. A large portion of our development and QA teams will halt work on other projects to expedite this

So…

(a) don’t expect plugin porting any time soon (just as we’ve been saying). Definitely not 2023, and probably not 2024 at their pace. Especially given that they were excited to announce that the Archetype: Plini has undergone several changes (after how many months) and they HOPE to deliver it before SUMMER??? Sheesh.

(b) given that they have team members “halting” other work - that means their glacial Development pace will get even slower??
 
So What Shrug GIF by Amanda Cee Media
 
We can handle that Apple silicon part for them, any bets if they'll take the offer?
What are the challenges for porting this stuff to work with Apple silicon?

Sure, x86 vs ARM but my understanding is that a lot of the tools are already arm64 compatible. At least JUCE and QT framework seem to be and both are listed as something NDSP wants for their Plugin GUI dev role on their career pages.

I don't know much about VST plugin development but you'd think NeuralDSP would take one of their more recent plugins for features, architecture etc and then shoehorn the older plugins' DSP code to work with that. Granted that's not an insignificant amount of work by any means but that's probably how I'd do it.
 
What are the challenges for porting this stuff to work with Apple silicon?

You have to be willing to do it

Sure, x86 vs ARM but my understanding is that a lot of the tools are already arm64 compatible. At least JUCE and QT framework seem to be and both are listed as something NDSP wants for their Plugin GUI dev role on their career pages.

Your understanding is correct. I was looking at the move in sheer terror and then our guys had it all done in the next build. You really do have it correct, its a non excuse, but on the off chance they're having trouble, we'd love to do it
 
You have to be willing to do it



Your understanding is correct. I was looking at the move in sheer terror and then our guys had it all done in the next build. You really do have it correct, its a non excuse, but on the off chance they're having trouble, we'd love to do it
So basically "set compile target to arm64, fix any problems that occur that prevent build, then fix any issues it might have while running"?
 
I don't get all this plugin->QC portage thing anyway. Sure, they promised it, which they defenitely shouldn't have done.
But from my understanding of some earlier information notes (coming straight from NDSP), it was never meant to be as drag'n'drop as on the Helix but rather "yeah, you could possible load plugin presets on the QC but they'd either only cover the amp(s) or be spread over multiple blocks - and doing it the other way 'round would likely only cover amp settings at all".
So why don't they just make a clear cut and split the development equally (or accordingly, proportinally, whatever), come up with some killer amp models for the QC and call it a day?
 
I don't get all this plugin->QC portage thing anyway. Sure, they promised it, which they defenitely shouldn't have done.
But from my understanding of some earlier information notes (coming straight from NDSP), it was never meant to be as drag'n'drop as on the Helix but rather "yeah, you could possible load plugin presets on the QC but they'd either only cover the amp(s) or be spread over multiple blocks - and doing it the other way 'round would likely only cover amp settings at all".
So why don't they just make a clear cut and split the development equally (or accordingly, proportinally, whatever), come up with some killer amp models for the QC and call it a day?
I believe people were supposed to have the capability to bring their presets over to the QC from the plugins once they got ported. At one point I think this might have been mentioned by NDSP as one of things slowing the process down.
 
If I get the amp, cabs, and effects from a plugin, all in different blocks, then in effect I've got that plugin on my QC.

Well, yes and no - for me, one of the appealing things in the HX ecosystem is the pretty much complete drag'n'drop-ability (individual blocks or entire presets). And at least for me, that's a lot more what I'm after than whatever amp models.
 
Back
Top