AAX isn't automagically DSP?

[WombatStudio.Org]

In watching the Recording with HD Native and Icon webinar, in the Q&A I was led to believe that AAX was bringing the ability of having plugin developers only worry about coding one plugin that will work both native and DSP.

I thought that was the whole point of AAX so that completely different code didn't have to be written for RTAs and TDM versions?

Not that I'll ever afford the ability to use DSP, but I just thought that was the whole reason behind the new AAX plugin format.

[Dism]

Originally Posted by WombatStudio.Org

In watching the Recording with HD Native and Icon webinar, in the Q&A I was led to believe that AAX was bringing the ability of having plugin developers only worry about coding one plugin that will work both native and DSP.

I thought that was the whole point of AAX so that completely different code didn't have to be written for RTAs and TDM versions?

Not that I'll ever afford the ability to use DSP, but I just thought that was the whole reason behind the new AAX plugin format.

There will still always be significant coding differences beteen native and dsp formats, (since you still have to test on a DSP card) but the main advantage is opening plugins.

For example:

Say you work on a session in a studio with HDX, and you want to bring the session home with you afterwards. If you have the native equivalent of the DSP plugins you were using, they will just open as normal, with your settings in tact. Vice versa as well. Rather than worrying which plugs are which, they will open on a native or dsp system. That's the main difference from RTAS/TDM.

[RussUK]

This case was overstated, it is not simply pressing 'DSP coder' button - we've spoken with many developers who all confirm this.

The main reason for AAX is 64bit in prep for 11 or whatever it will be called.

[tamasdragon]

The marketing made people believe that from this point on, everyone only need to code one plugin, and that would automatically be both dsp and native. But as we learned this is not the case. Still it is up to the developer to decide whether he/she would code for both. Hopefully many will decide to do a dsp version too.

In my opinion, this was the case where more honesty and less marketing would've done a better job.

[DaveTremblay]

Originally Posted by WombatStudio.Org

In watching the Recording with HD Native and Icon webinar, in the Q&A I was led to believe that AAX was bringing the ability of having plugin developers only worry about coding one plugin that will work both native and DSP.

I thought that was the whole point of AAX so that completely different code didn't have to be written for RTAs and TDM versions?

Not that I'll ever afford the ability to use DSP, but I just thought that was the whole reason behind the new AAX plugin format.

It's more fair to say that this is one of many reasons behind the AAX SDK, but to answer this question...

We've ported about 40 of our own plug-ins (roughly). To the best of my recollection, they all use identical code between Native and DSP versions, but it does take some tweaking and tuning to get the algorithm running well on DSP.

Our process is to port the plug-in to AAX Native and get everything working. Then, try to compile (build) the algorithm for the DSP chip. Simple plug-ins we can often have running within a couple of hours, but we'd never ship them that way. We always spend a lot of time tuning the code to get the last little bit of performance out of them. This can take a significant amount of time. We then run cancellation tests between the two platforms to verify that the processing is identical. Often, it is not exactly the same since these are different chips with different compilers. So, we fix all of those issues.

You can see how this would take a fair amount of time above and beyond making an AAX Native only plug-in. Additionally, you can cheat and take all sorts of shortcuts to get to AAX Native quickly that will prevent the code from ever running on the DSP. Some companies may chose that approach.

I think its fair to say that AAX DSP development is WAY easier than RTAS to TDM development, but it isn't free.

Dave

[tamasdragon]

I really understand that AAX is a necessary step, but we have to wait a little more till we can fully enjoy the benefits. Of course, the working industry needs this somewhat slower transition. Loosing compatibility over one night would be a disaster really.

[phatbeatstudio]

Originally Posted by RussUK

what ever it will be called

Dont quote me like I just did but ,did you just let the cat out of the bag.

You are in the industry arnt you. I could be wrong I don't remember but wernt or arnt you part of a site that sometimes had some very good inside with things like this.
I could be thinking of somebody else . The Jack Daniels was way to plentiful in 2000

Might be cool if they called it X1 and so forth

[Dism]

Originally Posted by phatbeatstudio

Dont quote me like I just did but ,did you just let the cat out of the bag.

You are in the industry arnt you. I could be wrong I don't remember but wernt or arnt you part of a site that sometimes had some very good inside with things like this.
I could be thinking of somebody else . The Jack Daniels was way to plentiful in 2000

Sometimes it's best not to read too deeply into what Russ says.

[hue]

Originally Posted by DaveTremblay

VST doesn't have the ability to build the processing part of the algorithm to live on embedded DSPs.

Can I call BS on this? Well, it doesn't matter because I'm going to. How about UAD and SSL and TC Powercore and Focusrite Liquidmix? All DSP powered VST plugins. We are not ignorant and I find it offensive that anyone would assume that we are oblivious of the technology that's out there. I own and have owned two of these platforms and they both work perfectly fine in RTAS and VST. To be totally honest, they worked much better in VST mode, were far less power hungry and far less buggy.

[Marsdy]

Originally Posted by hue

Can I call BS on this? Well, it doesn't matter because I'm going to. How about UAD and SSL and TC Powercore and Focusrite Liquidmix? All DSP powered VST plugins. We are not ignorant and I find it offensive that anyone would assume that we are oblivious of the technology that's out there. I own and have owned two of these platforms and they both work perfectly fine in RTAS and VST. To be totally honest, they worked much better in VST mode, were far less power hungry and far less buggy.

You might want to get your facts straight before accusing someone of BSing

"Powered" VST plug-ins are simply shells that address whatever is running on the respective DSP card wether SSL, UAD or whatever. A UAD card can't run a VST plug in programmed for Intel chips. In the same way, the UAD cards can't run AU plug-in code. In other words there's no such thing as a "powered" VST plug-in. The VST/AU plug-in is a "middleman" in effect. It's a means of routing between your DAW and the proprietory code running on the DSP card as well as being a "host" for the plug-in's GUI.

The VST/AU plug-in itself is NOT running on the UAD card. UAD could write their plug-ins in VST/AU/RTAS format but they've chosen not to. They'd rather have their own proprietary format which is effectively a hardware dongle.

There's a big difference between this way of working and AAX and AAX DSP.