Transition to AAX: A Real Programmer's Perspective

[kbruff]

Originally Posted by DaveTremblay

I think the long term answer is yes, but ultimately it depends on what the plug-in companies want to sell and how they want to sell it. With AAX, we've strongly encouraged developers to use standard C++ code for their processing which can be compiled for different processors and platforms, but it doesn't mean they will choose to distribute those versions. There might be other factors weighing into their decisions.

Heat is a funny beast because it is technically a plug-in, but it is wired into the system in a very particular way. building the plug-in as Native is relatively simple, but wiring both versions seamlessly in, a little less so...

Dave

So AVID is essentially enabling the pathway for developers, and not necessarily preserving a barrier as was the case with TDM versus RTAS. Therefore there can technically be dismissable difference between a Native session versus a HDX session, provided CPTK and 100% ITB mixing.

Is that a fair remark?

[DaveTremblay]

Originally Posted by kbruff

So AVID is essentially enabling the pathway for developers, and not necessarily preserving a barrier as was the case with TDM versus RTAS. Therefore there can technically be dismissable difference between a Native session versus a HDX session, provided CPTK and 100% ITB mixing.

Is that a fair remark?

To be honest, I'm probably not the best person to answer this question as it speaks to a larger Avid strategy, but I'll try to give you some sort of answer as it pertains to AAX...

AAX was definitely designed to make plug-in development more consistent and simpler across various hardware architectures, and not just the processing code. Across the board, we moved to a much more modular portable design with AAX.

It would be easy to look at 64 bit and HDX and say, "hey, that's why they did AAX". And while that certainly factored into the timing of all of this, it is hardly the only goal... We're trying to set ourselves up for the future and the previous plug-in architecture was just too tied to our past. It was a very difficult project to maintain the important pieces of the past while setting us up for the future, but I think the team did an excellent job preserving our design goals.

Dave

[kbruff]

Originally Posted by DaveTremblay

To be honest, I'm probably not the best person to answer this question as it speaks to a larger Avid strategy, but I'll try to give you some sort of answer as it pertains to AAX...

AAX was definitely designed to make plug-in development more consistent and simpler across various hardware architectures, and not just the processing code. Across the board, we moved to a much more modular portable design with AAX.

It would be easy to look at 64 bit and HDX and say, "hey, that's why they did AAX". And while that certainly factored into the timing of all of this, it is hardly the only goal... We're trying to set ourselves up for the future and the previous plug-in architecture was just too tied to our past. It was a very difficult project to maintain the important pieces of the past while setting us up for the future, but I think the team did an excellent job preserving our design goals.

Dave

Thank you.

[daeron80]

Originally Posted by DaveTremblay

It was a very difficult project to maintain the important pieces of the past while setting us up for the future, but I think the team did an excellent job preserving our design goals.

I agree. People are whining about paying for software that's a transition. I'm just glad there's a transition. It would really suck to not be able to use these fantastic new features just because you invested in HD Accel gear. It's also great that the plugin companies have a transition time where they can continue to sell and maintain RTAS while they develop their AAX lines.

[Farmer Dave]

Originally Posted by daeron80

I agree. People are whining about paying for software that's a transition. I'm just glad there's a transition. It would really suck to not be able to use these fantastic new features just because you invested in HD Accel gear. It's also great that the plugin companies have a transition time where they can continue to sell and maintain RTAS while they develop their AAX lines.

+1

[houser]

Could not agree more.
It seems very well thought out and planned so far..
best
j

Originally Posted by daeron80

I agree. People are whining about paying for software that's a transition. I'm just glad there's a transition. It would really suck to not be able to use these fantastic new features just because you invested in HD Accel gear. It's also great that the plugin companies have a transition time where they can continue to sell and maintain RTAS while they develop their AAX lines.

[BobbyDazzler]

What are the chances of a TDM wrapper for future HDX?

[DaveTremblay]

Originally Posted by BobbyDazzler

What are the chances of a TDM wrapper for future HDX?

I'm not sure exactly what you mean by that, but I will say that the way our legacy TDM plug-ins worked and the AAX DSP plug-ins work is very different. It seems unlikely that we'd be able to resolve those differences in any sort of wrapper without an absolutely heroic effort and some compromises to features and performance.

Dave

[sunburst79]

Originally Posted by DaveTremblay

I'm not sure exactly what you mean by that, but I will say that the way our legacy TDM plug-ins worked and the AAX DSP plug-ins work is very different. It seems unlikely that we'd be able to resolve those differences in any sort of wrapper without an absolutely heroic effort and some compromises to features and performance.

Dave

I think that means NO.

Would RTAS fare any better seeing as it wasn't compiled to DSP specific language first? Is there a potential the someone like FXSpansion could follow up the VST2RTAs Wrapper with a AAX2RTAS Wrapper? I can't imagine you would want to use it when you had AAX available but there might be useful opening legacy sessions containing non AAX plugs.

[DaveTremblay]

Originally Posted by sunburst79

I think that means NO.

Would RTAS fare any better seeing as it wasn't compiled to DSP specific language first? Is there a potential the someone like FXSpansion could follow up the VST2RTAs Wrapper with a AAX2RTAS Wrapper? I can't imagine you would want to use it when you had AAX available but there might be useful opening legacy sessions containing non AAX plugs.

Possibly, but RTAS is supported directly right now. If a third party wanted to write a 32 bit to 64 bit RTAS to AAX Bridge, I guess they might be able to but all bridges come with some significant tradeoffs...

Dave