So, latency on HD Native vs HDX?

[JFreak]

Misinformation?

Just sayin' most "studies" assume zero plugins, which in real world isn't the case. Build your mixer and add plugins, the numbers change even if you only add TDM plugins. Even with zero native processing, a TDM latency can be unbearable for tracking. And in this scenario there is this small limitation of not being able to use native processing.

Which is why HDN and 96k@64 buffer wins hands down. There is only native buffer in the equation and not variably growing TDM latency at all. As soon as first native plugin is added to a TDM session, the game is over.

[brianjanthony]

It's not academic for me, as much as it is a buying decision. I have HDN and an ancient 2010 Cheese grater with 40gb ram. I do a ton of mixing and tracking.

Sometimes, like the last week, I'm tracking 32 ins for days on end. and sometimes I'm tracking 1 or 2 in on a session sent from somewhere where there's hundreds of plugins. And every now and then, let's say 1 every 2 weeks, RECORD will stop with a 9073. That's not cool.

Is that worth "trying" HDX? I know in the exact same scenario, my old TDM rig would buck and puke every now and again (HD6).

I don't plan on using DSP plugs only. Quite the opposite will happen actually. I inherit a lot of sessions and most run native, esp crazy effects tracks. So my main concern is/was, in a session that in native needs a 256 buffer to run smooth, in HDX I will still need the 256 buffer. And then the record track would need a DSP trim first, then native plugin after it, and I put it into record. Will it feel like a 32 buffer in native land? I don't think so. Even if I only use a DSP compressor on the vocal track, I think I'll still have issues.

Having said all that, again, its a "where to spend the Dollars?" Self argument. Might I be best served dumping the 3k from an HDX card in more ram/souping up the machine?

Affording is not the concern. It's being prudent and most effective with the money/tech that I'm after. Hope that makes sense.


Sent from my iPhone using Tapatalk

[JFreak]

Originally Posted by brianjanthony

And every now and then, let's say 1 every 2 weeks, RECORD will stop with a 9073. That's not cool.

That's not cool, but at least you only get it so seldom others who make a lot of noise about this give the impression that 9073 comes couple of times a day. Now that would be a problem...

[propower]

Originally Posted by brianjanthony

I don't plan on using DSP plugs only. Quite the opposite will happen actually. I inherit a lot of sessions and most run native, esp crazy effects tracks. So my main concern is/was, in a session that in native needs a 256 buffer to run smooth, in HDX I will still need the 256 buffer.

Yes

Originally Posted by brianjanthony

And then the record track would need a DSP trim first, then native plugin after it, and I put it into record. Will it feel like a 32 buffer in native land? I don't think so. Even if I only use a DSP compressor on the vocal track, I think I'll still have issues.

No - if you use a Native plugin on a record enabled track (with a AAX-DSP plugin right before it - it will not bypass the Native plug in REC) and the Round Trip Latency (RTL) will be some where between slightly longer than HDN and a ms or two - (All depending on session setup). If this is how you have to run - keep HDN - HDX won't help.

Now if you only use AAX-DSP on the REC enabled track and have no Native plugins in the path to the Physical output to the musician (no Native plugs on SubMaster or Master for that output) then set the buffer to 1024 and there will be significantly less RTL than 32 buffer for the musician.

AFAIK - the dreaded -9073 issue exists in all versions of PT12 on both Native and HDX. FWIW - I run sessions with mostly AAX-DSP plugs at 96kHz (less than 1ms tracking latency) and don't get a lot of -9073. But it is does happen enough to be annoying.

PS - HDN 96k/64 many plugins barely run there if at all (Abbey Road Plates, Kontakt etc...). (96K/256 much better) - Latency wise your better off 44.1/64.

[JFreak]

Originally Posted by propower

I run sessions with mostly AAX-DSP plugs

That's the way HDX platform has been designed.

Too bad not all of the plugin vendors are in. For me, transition from TDM to HDN/HDX was headed towards HDN much because of lack of Waves support. As a previous Mercury TDM customer I now laugh at their "we support all major platforms" promise. In plain english it means "we support whatever we choose" and AAX-DSP is apparently not a major platform as per Waves.

[arche3]

But you can run an hdx system just like a hdn system so I don't see the point of debate. Hdx just adds dsp if needed.

If I run my hdx only using native plugins isn't it exactly the same as a hdn system? Or is it different somehow?

Sent from my SM-G935V using Tapatalk

[Matt Hepworth]

Originally Posted by arche3

But you can run an hdx system just like a hdn system so I don't see the point of debate. Hdx just adds dsp if needed.

If I run my hdx only using native plugins isn't it exactly the same as a hdn system? Or is it different somehow?

Sent from my SM-G935V using Tapatalk

No, it's double the latency of HDN if you're only using native plugins. Unusable.

[Matt Hepworth]

Originally Posted by JFreak

That's the way HDX platform has been designed.

Too bad not all of the plugin vendors are in. For me, transition from TDM to HDN/HDX was headed towards HDN much because of lack of Waves support. As a previous Mercury TDM customer I now laugh at their "we support all major platforms" promise. In plain english it means "we support whatever we choose" and AAX-DSP is apparently not a major platform as per Waves.

Waves is the reason I'm still on TDM, but I did try HDX last year. Too few plugins, too much latency for my workflow, and too little power.

I also have an HDN system. Not all plugins will run at 64 buffer 96k and if I have to go up to 128 it's unusable.

[JFreak]

Originally Posted by Matt Hepworth

Waves is the reason I'm still on TDM, but I did try HDX last year. Too few plugins, too much latency for my workflow, and too little power.

That's their excuse, not the real reason. How come other vendors have seen benefits in moving from TDM to HDX but suddenly Waves is incompetent in plugin development? The real reason is they don't want their plugs running on S3L/S6L

[Matt Hepworth]

Originally Posted by JFreak

Misinformation?



Just sayin' most "studies" assume zero plugins, which in real world isn't the case. Build your mixer and add plugins, the numbers change even if you only add TDM plugins. Even with zero native processing, a TDM latency can be unbearable for tracking. And in this scenario there is this small limitation of not being able to use native processing.



Which is why HDN and 96k@64 buffer wins hands down. There is only native buffer in the equation and not variably growing TDM latency at all. As soon as first native plugin is added to a TDM session, the game is over.

Yes, misinformation.

I run pretty significant tracking sessions (32 inputs and separate headphone mixes) with MANY plug-ins and always have less than 20 SAMPLES of latency at 44.1kHz.

Facts: most TDM plugins have four samples latency, or less. Most look-ahead enabled plugins have 64 samples latency.

Facts: most HDX plugins have 33 or more samples of latency. The absolute minimum is 9 samples. Most look-ahead enabled plug-ins have 80+ samples of latency.


Wherever you were getting this 300+ samples of latency on a TDM system was certainly user created. It's very hard to get TDM latency even close to that high without sandwiching native plugins in between two TDM plugins (which will add the native processing delay), or using the handful of very high latency plugins that have no place during tracking.
Or, you were using native plugins on auxes for headphone mixes that were being fed record armed tracks.

I'm not being facetious when I say this: I am glad that you have a very high tolerance of latency. I wish that every artist I work with did—it would make things a lot easier and cheaper for me and I would be running HDN for everything.