Reassurance for those who want to port over to HDX / AAX

[BradLyons]

Moving to AAX is a whole new platform, but it is one that developers must do if they wish to stay in business To advance in technology, that means to ADVANCE and not hang on to what has worked for so many years. It may be frustrating for awhile, that has to be understood----but as the developers get there and issues are worked out, it's all going to be well worth it in the end. Moving from RTAS and TDM to AAX is no small thing to accomplish----any developer will tell you that, especially those that have many plugins to do so with.....and frankly it will cost each manufacturer money to do it, some more than others. But again this is all to create a better "team" moving forward. Understand that those that are "sticking it to us" are not doing so on purpose----this is NOT a simple thing to do.

To address WAVES.....they are one of those that have a couple of plugins (HA!). It's a sticky one because are they expected to be covered under the WUP plan or is it okay to charge a small fee (to cover part of the costs) because this is a completely new format of plugins they have to code for that wasn't part of their typical updates and upgrades. And how to do it in a timely fashion, etc.

[roberts]

Originally Posted by BradLyons

It's a sticky one because are they expected to be covered under the WUP plan or is it okay to charge a small fee (to cover part of the costs) because this is a completely new format of plugins they have to code for that wasn't part of their typical updates and upgrades.

Not very comforting for the users that paid 10K+ for their Mercury SSL TDM bundles
750 to upgrade 8 Sonnox plugins They are off my upgrade list.

[rockridge]

Isn't it only the 'Waveshell' that has to be ported over to AAX?

Like the wrapper Spectrasonics uses...

It won't take them any time at all. If it isn't done already.
They may just be waiting... squeeze out extra sales of RTAS.

[TOM@METRO]

Originally Posted by rockridge

Isn't it only the 'Waveshell' that has to be ported over to AAX?

Hmmm. You may be right about that.

[carlone]

It's not just the waveshell. They have to code each plug-ins for AAX since it's a brand new format and DSP versions have to be written for AAX + a new type of DSP chip. It's not as simple as a new waveshell.

This is why RTAS is still supported for now.

[TOM@METRO]

I guess there is also the 64bit issue.

[rockridge]

There is also a difference between the Mac and PC versions.
So there are other considerations.

But I still think the main work is in developing a waveshell for AAX in the two platforms.

I'll wager the 64 bit thing won't apply to all their plugs either.
I'm guessing of course... but unless someone from Waves says otherwise, we're all just speculating.

Even though Avid introduced their users to AAX recently, the major 3rd party companies have probably known for much longer.

[Bob Olhsson]

My understanding is that the real grunt work is optimizing a plug-in with assembler code so it doesn't use too much cpu power and yet isn't being dumbed down. This code is unique to the cpu being employed.

TDM plugs needed to be written entirely in assembler which demanded extraordinary time and programming skills. AAX apparently simplifies the process however the new chips still require a lot of work for plug-ins to not become resource hogs.

The waves native plugs are extraordinarily efficient compared to many others due to their expertise at this kind of optimization. I think there are legitimate questions of how big the HDX market is going to be and how much real-world advantage a DSP version would have over a highly optimized native version. Some waves plugs are obvious candidates but many of the older, more efficient ones probably wouldn't offer much of an advantage.

[rmajors]

The best way to get information about any plug-in developer's plans for AAX development will be to contact that company directly. With regards to companies that have not yet made statements regarding their development plans, the same is true: one of the best ways to encourage a company to port their plug-ins to AAX DSP will be to let them know about your interest in the platform.

Some companies have made public statements regarding their commitment to the platform and development schedules, and we are doing our best to collect this information in the "Third-party AAX plug-ins" section of the AAX Plug-In Compatibility page:

http://www.avid.com/US/resources/AAX...-compatibility

For a more in-depth discussion regarding the technical details of the new plug-in format, see the excellent "Real Programmer's Perspective" sticky by Frank Filipanits:

http://duc.avid.com/showthread.php?t=310093

As described in that thread, we have done our best to create a format that requires a minimum of effort to support both Native and DSP-based processing. That said, the two processing environments are different, so some specific plug-ins may take extra effort to port to DSP. In addition, AAX DSP does require additional optimization for the best results (in C, not assembly thankfully.) The "cost" of this optimization will vary depending on the specific algorithm and the developer's experience. Again, this is all described in much greater depth in that thread, so look there for more information.

Regards,
Rob

---
Rob Majors
Avid Third-Party Developer Services

[Carl Lie]

One note. Overloud is touting BReverb 2 as AAX but it is Native only.

Something to look out for.

Carl