Transition to AAX: A Real Programmer's Perspective

[Sonopolis]

Originally Posted by DarylG

Avid has said "yes" to this question on another thread, as well as "yes" Freeze.

D

Thanks for the info.

[Marsdy]

Dave

Thanks for your info in this thread.

If you're still watching I have a couple of questions re. HDX.

1. I was wondering about chip sharing on the new HDX cards. On TDM systems there are some "chip hog" plug-ins. For example, an instance of Virus Indigo uses 13% of one chip, the remainder of the chip's capacity being unusable for anything else. Not even another instance of Virus Indigo can use the remainder. If I only use a single instance of a McDSP plug-in like Retro EQ in a mix, it uses 18% of one chip, the remaining 82% is then unusable for anything other than another McDSP plug-in.

With HDX having fewer chips than say an HD3 system, are "chip hog" plug-ins going to have a bigger impact on overall DSP capacity? I'm thinking a few greedy plug-ins might eat into the advantage HDX has over my HD3 system because fewer DSP chips are available per system. Maybe you could comment on how chip sharing is managed on the HDX cards? Or is this down to the plug-in developers?

2. Will AAX plug-ins read user preset files created by their TDM equivalent?

3. Are we likely to see many DSP AAX virtual instruments? If so, could an AAX VI running on an HDX card stream samples off disk?

[Andres Gonzalez]

I read this thread a few days ago but do not recall if this question was already asked or if already answered. But I will ask it anyway here.

One of the PT v10 features is "RAM-based play back"

Since PT v10 will still be a 32 bit application, is it safe to assume that RAM-based play back in PT v10 running on a 64 bit OS, will still only have access to roughly 4GB of RAM for play back?

It appears to me that this new feature in PT v10 is of limited value running on an already memory-stressed application. If we are using just one VI, there will not be enough memory available to run even a single track directly from memory.

-Andres

[DaveTremblay]

Originally Posted by Sonopolis

Could AAX plugs support off-line bounce?

I can't comment on future products or engine improvements as we are a public company.

I will say that we overhauled AudioSuite when bringing it into the AAX world, so all developers have to do is add a single line of code to make their AAX Native plug-ins work as "AudioSuite". This one line change tells the system that this AudioSuite processing is identical to the AAX Native processing. I'll let you infer anything beyond that.

While we're talking about this, there has definitely been some confusion on this idea that AAX plug-ins just automatically support DSP acceleration. Frank mentions this in his original post, but it is not true. What we've done with AAX is create a modular little plug-in spec that separates the actual processing code from the "data model", which is the piece of code that stores that actual parameters and such. While making this separation, we made it so the data model (again, the storage of parameters and conversion of those parameters into things the processing code needs to actually...process) doesn't actually know where that processing code lives. It could be on a DSP, it could be on the Native CPU. We take care of that communication in an abstract way and route it to the proper location. Because that processing code is a tight little package that doesn't need to know anything about the system its running on, we've made it pretty easy to just recompile that processing code for our DSP chips. The same exact code can be compiled for either processor.

Sounds simple enough, and in many cases it is, but that code won't necessarily build and run in an optimal way for the DSP processors. I can tell you that, for our plug-ins, we can get them to build easily enough and even run right away from AAX Native (in most cases), but we go back and spend a decent amount of time really tuning them to run lean and fast on those DSPs so you guys can get your money's worth out of these new cards. I would expect third party developers to have to go through a similar process (which is more work) to provide DSP accelerated versions of their plug-ins.

It is WAY easier than TDM, but it still isn't free.

Dave

[DaveTremblay]

Originally Posted by TDigi

-Toby Dunn
Avid Engineering

Cool! Toby has joined the party! :)

Dave

[DaveTremblay]

Originally Posted by rockridge

Are there routines that would benefit from 16 bit or even 8 bit?

Back in the Atari 1040ST days, since RAM and processing power was scarce, I heard that programmers would code in multiple languages.

Using the most efficient wherever they could.
That always impressed me.

Is that still necessary these days?

Not really. There are ways to make those types super fast if you use SSE instructions in the processor. Things like this are done in the graphics world for instance, but for Audio, it isn't really worth the tradeoffs. 8 bit color is fine. 8 bit audio sucks. (unless you're going for that sound of course) There are also ways to use SSE for floating point and double floating point, which we do use to squeeze out every last bit of performance from the machine.

We generally use C++ for everything today, as Toby mentioned. The compilers are really good if you know how to give them the latitude to optimize and quite frankly the chips (even the DSPs now) are ridiculously complicated with all their parallelism.

Dave

[DaveTremblay]

Originally Posted by anearforgear

I've always wondered (and heard through the grapevine) about consolidating regions, or "clips" as we're now calling them. I'm always a bit hesitant to hit option+shift+3 because I've heard that when you consolidate you're adding dither as a result.

Is this true?

I believe this depends on whether you have the AudioSuite Dither option turned on. That is what I'd infer from watching plug-ins get created and destroyed behind the scenes. At least historically...

I believe that option+shift+3, consolidate, no longer uses AudioSuite plug-ins to perform this task though (as of 10), so I would guess that we don't apply dither during a consolidate regardless of that option now. But someone could easily step in and prove me wrong here. I'm not super familiar with the changes in this feature for PT10.

And yeah... IdeaScale is your friend. Regardless of what anyone else in the forums say, we do watch this...

Dave

[DaveTremblay]

Originally Posted by Marsdy

1. I was wondering about chip sharing on the new HDX cards. On TDM systems there are some "chip hog" plug-ins. For example, an instance of Virus Indigo uses 13% of one chip, the remainder of the chip's capacity being unusable for anything else. Not even another instance of Virus Indigo can use the remainder. If I only use a single instance of a McDSP plug-in like Retro EQ in a mix, it uses 18% of one chip, the remaining 82% is then unusable for anything other than another McDSP plug-in.

With HDX having fewer chips than say an HD3 system, are "chip hog" plug-ins going to have a bigger impact on overall DSP capacity? I'm thinking a few greedy plug-ins might eat into the advantage HDX has over my HD3 system because fewer DSP chips are available per system. Maybe you could comment on how chip sharing is managed on the HDX cards? Or is this down to the plug-in developers?

AAX is a multi-shell environment, so all plug-ins share. It isn't an additional option like it was with TDM. Turns out this is very difficult to do in a general way, but I think we've nailed it. There are some circumstances where plug-ins will hog a chip right now because of non-deterministic resource contentions on the chip, but these cases are rare. And these outliers as far as chip resource usage tend to be the huge plug-ins, which would likely end up taking most of a chip anyway. I think you'll see these chips being packed much tighter than the legacy TDM system was capable of. Please let us know if you don't, and we can take an additional look at how to optimize the allocations.

Originally Posted by Marsdy

2. Will AAX plug-ins read user preset files created by their TDM equivalent?

Yes, if the plug-in developer sets up their plug-ins to be compatible. All of our AAX plug-ins convert seamlessly between their legacy and AAX counterparts. This includes conversion of types when you switch decks, settings saves in the session, presets, etc. This was actually a pretty tough compromise to make in the design, but we're not in the business of pure technical research. We understand that you guys switch between systems and we needed to make this transition as painless as possible.

Originally Posted by Marsdy

3. Are we likely to see many DSP AAX virtual instruments? If so, could an AAX VI running on an HDX card stream samples off disk?

Good question. I think that ultimately depends on the third party companies. There are a couple things that would need to happen. Your actual processing code for your instrument has to be pretty disentangled from the rest of your plug-in. You'd want the VI to be pretty deterministic in how much CPU it will take, which could be tough in many cases. And lastly, we have much less memory on the TI chips than in the host, so large samplers are probably not an appropriate fit for the DSP. If I had to guess, I'd say we might see synths someday on the DSP, which would be cool. Samplers, I'd guess not, but you never know. We're certainly willing to collaborate with the plug-in developers on creative ways to make all of these things possible...

Oh, and to answer your second question... not really. You can read the samples off disk from the host side of your plug-in and push them down to the DSPs just in time, but you'd have to really analyze whether this is a good use of the DSP and the CPU.

Dave

[DaveTremblay]

Originally Posted by Andres Gonzalez

One of the PT v10 features is "RAM-based play back"

Since PT v10 will still be a 32 bit application, is it safe to assume that RAM-based play back in PT v10 running on a 64 bit OS, will still only have access to roughly 4GB of RAM for play back?

I should check with Andy before committing to this answer, but I believe that the Disk Cache feature in PT10 HD uses something we call keyhole, which allows us to tunnel through to another process. I believe Disk Cache actually runs in a different, true 64 bit, process and can access all available RAM. This would mean that the Disk Cache doesn't eat up the limited memory in your 32 bit Pro Tools process. Pretty darn cool feature if you ask me...

Dave

[Marsdy]

Originally Posted by DaveTremblay

I think you'll see these chips being packed much tighter than the legacy TDM system was capable of.

This I like the sound of!

Dave, Many thanks for your answers. It really sounds like you guys have thought this one through!

One more question!
Altiverb can take up a huge number of chips on a TDM system. The longer the reverb time, the more chips get used. I understand this was due the limited amount of RAM available to each chip on a TDM card. Has this improved/changed with HDX?