Transition to AAX: A Real Programmer's Perspective

[M-ManLA]

Great Article. Thank you for this.

[Sonopolis]

This is indeed a very interesting discussion. It gives a lot of insight to the technical background of the new format, thank you. Now the really interesting question for me is:

Could AAX plugs support off-line bounce?

I guess the fact that this wasn't implemented long ago has much to to with it not being possible with Real Time Audiosuite (and certainly not with TDM).

[DarylG]

Originally Posted by Sonopolis

This is indeed a very interesting discussion. It gives a lot of insight to the technical background of the new format, thank you. Now the really interesting question for me is:

Could AAX plugs support off-line bounce?

I guess the fact that this wasn't implemented long ago has much to to with it not being possible with Real Time Audiosuite (and certainly not with TDM).

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

D

[rockridge]

Originally Posted by DaveTremblay

I apologize for confusing the issue. LukeHoward's post is spot on. Things that we want to be 32 bit for performance reasons can stay 32 bit. Just the amount of memory that we can use increases.

Dave

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?

[Bob Olhsson]

Originally Posted by b1daly

I have a question I've pondered for years. In general, I find my results when mixing ITB to be inferior to using an analog console. My main theory about this is that the computer GUI is just harder to mix on.
But I do get this kind of slightly grainy, smeary, plastic sounding edge in my ITB mixes, once all the plugins are on...

This is off topic but I can offer a couple comments to consider.

1. the low level noise and distortion of a console seems to make balances less ambiguous which allows them to translate better. Apples vs. oranges in the box becomes right vs. wrong using a console. An analogy might be a ground glass focusing screen in a camera. HEAT and VCC seem to help a lot.

2. plug-ins are all over the map sound quality-wise as are the sonic interactions between them. Mastering with them is often a shoot-out to determine which sounds best. While there are a few real dogs that never sound very good, I've often been very surprised by which sounds best across a given mix. Ones I've almost written off can turn out to be golden on the next project even beating all of the analog gear!

[Tobias Eichelberg]

Thank you to Frank, Dave and everybody else who's providing such insightful information! I appreciate this!

[DaveTremblay]

Originally Posted by b1daly

1) is my understanding of how dither is used in the TDM signal path correct?
2) is it different in PT 9 native mixer concept ( i.e. dither not needed between plugins)
3) is the mix engine different in PT 10, even running RTAS plugins? (meaning old mixes might sound better!)
4) Do the AAX plugins offer sonic advantages over RTAS?

1) I don't have enough direct technical knowledge of legacy TDM systems to answer authoritatively.

2) I would say that dither is not needed between plug-ins in a 32 bit floating point signal path. Floating point has fundamentally different numerical representation that makes use of dither awkward. Dither is really intended when you are reducing the bit depth to a final integer representation, like right before you go to your converters. Since all plug-ins are now 32 bit signal path, DSP and Native, you shouldn't need dither between any plug-ins, only before you hit your converters.

3) Good question, and not simple to answer. I'm not positive, but I believe the native mixer stayed the same. For the HDX Mixer, it has obviously been rewritten for the new DSPs and now uses 64 bit floating point accumulators internally, which is a significant improvement.

4) Not necessarily, the signal quality in and out of the plug-in are both 32 bit floating point. I will say that in our efforts to move over to AAX, we took some opportunities to modernize pieces of our code, internal to the plug-ins, which could/will make them sound better and perform better. That said, there is a benefit that there aren't all these conversions back and forth between 24 bit for TDM and 32 bit float for RTAS.

Dave

[TDigi]

Yes, thanks Dave (and Frank!) for the informative posts - nice job I'll chime in on a couple of these from mr. daly and rockridge:

1) So I always assumed the signal was dithered from 48bits to 24 bits at the output of every plugin.... It is up to the TDM plug-ins themselves, and not all do this (many do internal processing at 48-bit, but don't necessarily add dither to go down to 24-bits). As this dither would be at roughly -144 dB it is often a better choice to avoid the extra processor cycles required. The "dithered" mixer will add dither at its final output stage on any given output path, but this only happens once at the 48->24 bit truncation.

As far as the native mix engine, it is not significantly different (in terms of signal path) with native PT10 systems. However, as Dave mentioned the new HDX system is different from legacy HD/TDM systems, one advantage being that audio is kept at 32-bit between the host CPU and the HDX cards, so you don't lose anything (as opposed to needing to convert to 24-bit fixed point when sending the audio signals to the HD/TDM cards).

Re: coding in different languages -- fortunately we are able to keep the PT10 system mostly to high level languages (C/C++) for both the host system and HDX/DSP plug-ins, although the processors are different for the new plug-ins so a bit of tweaking at a lower level is sometimes needed to get the very best performance. And of course FPGA coding is a different ballgame as well (!)

-Toby Dunn
Avid Engineering

[anearforgear]

Since we're playing twenty questions...

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?

The most frequent use of this for me is when bouncing stems out of Pro Tools. Sometimes I need to print a short segment of audio, say the 'bridge' of a song, but then need to export 'from 0' so the stem will line up. So I print the short clip and consolidate back to 0 in order to make the stem length appropriate. But not only have I now created a whole new audio file (in addition to the clip I intended to create), I may have added dither as well!

What would be really great is if we could just use the 'region group' feature, creating the appropriate length clip and export THAT, thereby removing the need to create additional audio at all!

...maybe I should post this on ideascale.

[jeremiahmoore]

It's cool to get to learn all this technical stuff.

Where does FPGA come in on HDX? Is it used for routing? Summing?

What dither is (or isnt) applied in the new mixer, and where? I gather there is none internally to the mixer (unless within a particular plug-in). Is there automatic dither on output to I/O or files?

It's truly been a long road to modernize the ancient codebase. I think (hope!) the more rapid deployment of new features we're starting to see may be the dividends starting to pay off from that investment. just today I was sitting in the room with Josh Rosen, one of the authors of Pro Tools 1, and talking about how far it's all come.

-jeremiah


Sent from inner space