HDX. Period.

[UnderTow]

Originally Posted by OralnHardly

PT10/HDX competely removes plugin latency.

Not true at all: Try putting a linear phase EQ on an aux in HDX (for instance). You will have plugin latency.

Freezing tracks is NOT A GOOD OPTION at all for serious mixes. Freezing is for when your system craps out.

Again, not always true. Plugin latency is not necessarily dependant on the DSP/CPU load of the plugin. It is dependent on the type of algorithm.

Your DAW should't should't be trying to jump through hoops creating errors all over the place. It should just work...adn then tell you when it's maxed out. Period.

I find that a rather limited view on the possibilities of technology... When a system is maxed out and needs to drop audio, it is only an advantage if instead of just giving you a DAE playback error, it gives you an option to freeze stuff. I'm sure Avid could add a "Never show me this option again" check-box for those that don't like this.

Alistair

[OralnHardly]

Delay Compensation works folks. Unless there ar third party plugs that don;t report it properly...in which case all DAWs suffer equally.

Narrow minded thinking happens when folks think that technology is the answer to everything...and that bigger and faster is better.

I n the real world having specific technology devoted to specific tasks is much more reliable than technology that tries to do everything all the time.

This is the problem we see with native rigs. The philosophy is getting in the way of stability. No DAW developer wants to admit that "capping" the DAWs functions makes it more reliable under heavy loads.

There is a reason that after 20+ years folks LOVE RADAR...is is not that sexy...at all...and also why folks love PT...relibility...having the latest bells and whistles is fun...but really...we are making music...how many tracks...how many plugs...how much processing do you think you need???

If your answer is ...more...then I would strongly suggest that you aren't making music, but rather, you are nerding out over how "cool" your rig is.

Which is cool. We all do that to a certain extent.

[Aith]

Originally Posted by OralnHardly

If your answer is ...more...then I would strongly suggest that you aren't making music, but rather, you are nerding out over how "cool" your rig is.

Which is cool. We all do that to a certain extent.

Or it's just someone making electronic music ITB which in fact requires tons of VI's and plugins and just suffers from the unspeakably inefficient resource usage of PT.

[KevWind]

Originally Posted by Aith

Or it's just someone making electronic music ITB which in fact requires tons of VI's and plugins and just suffers from the unspeakably inefficient resource usage of PT.

In which case they should not use PT - problem solved

[mykhal c]

PT plus VEPro = problem solved

[jrhager84]

I really should pick that up.

Sent from my SAMSUNG-SGH-I777 using Tapatalk

[KevWind]

Originally Posted by mykhal c

PT plus VEPro = problem solved

I read this before, does it really allow multiple VI's to run simul. ?

[mykhal c]

Originally Posted by KevWind

I read this before, does it really allow multiple VI's to run simul. ?

yes...absolutely. you can use one VI per one VEPro RTAS insert or multiple VIs within that one VEPro RTAS insert...plus this applies to your 32bit VIs that will of course run in a 32bit VEPro server and your 64bit VIs that will run in the 64bit VEPro server...and of course runnin' at the same time if the session calls for them both. Avid has gotta be silently thankin' the gods for VEPro while PT is still a 32bit app and that RTAS performance, uhh, is SERIOUSLY strained at best.

[jrhager84]

I just know I'm going to buy VEpro only for avid to update it to redundancy...

Sent from my SAMSUNG-SGH-I777 using Tapatalk

[KevWind]

Originally Posted by mykhal c

yes...absolutely. you can use one VI per one VEPro RTAS insert or multiple VIs within that one VEPro RTAS insert...plus this applies to your 32bit VIs that will of course run in a 32bit VEPro server and your 64bit VIs that will run in the 64bit VEPro server...and of course runnin' at the same time if the session calls for them both. Avid has gotta be silently thankin' the gods for VEPro while PT is still a 32bit app and that RTAS performance, uhh, is SERIOUSLY strained at best.

Thanks for the reply

[KevWind]

Originally Posted by jrhager84

I just know I'm going to buy VEpro only for avid to update it to redundancy...

Sent from my SAMSUNG-SGH-I777 using Tapatalk

We are never really going to get ahead of technology it's more like clinging by the fingernails to the comets tail!
My guess ( and only guess) is if that happens ? it would not be until Vr. 11

[Matt Hepworth]

Originally Posted by Doc Mixwell

Matt, Firstly - where is the link you refer to?

The link below says the latency of HDX is 0.7ms and HD Core is 0.96ms

Avid | Pro Tools HDX
follow the "compare systems" link

That is actually highly skewed in favor of HDX. I'm pretty sure they're quoting the 48k latency figures for HD and 96 for everything else. Here's the info on HD with an HD I/O when HDN launched.
http://www.gearslutz.com/board/attac...y-comp-96k.jpg

That was directly from Avid and there were other charts and substantial documentation to prove it.

HDX at 96 is almost TWICE the latency of HD at 96, if using the same I/O.

.7ms for HDX vs .44 for HD.

[Doc Mixwell]

Originally Posted by Matt Hepworth

That is actually highly skewed in favor of HDX. I'm pretty sure they're quoting the 48k latency figures for HD and 96 for everything else. Here's the info on HD with an HD I/O when HDN launched.
http://www.gearslutz.com/board/attac...y-comp-96k.jpg

That was directly from Avid and there were other charts and substantial documentation to prove it.

HDX at 96 is almost TWICE the latency of HD at 96, if using the same I/O.

.7ms for HDX vs .44 for HD.

Hi Matt,

The side note [**] state the following;

** Latency calculated using a 96 kHz sample rate with a 64-sample buffer. Tests run using Pro Tools|HDX and Pro Tools|HD Native with HD I/O, and Pro Tools|HD Accel with 192 I/O.

Sure, the 192 has greater amounts of latency than the HD I/O does, so one could look at it as "skewed", as the latency time will likely decrease on your TDM systems with an HD I/O. It simply appears, to me, they are matching system for system here, and its rightfully so. Old system versus the new ones. There is no reason to test HDX or HDN with the old legacy I/O, for latency spec, because that interface is no longer manufactured.

[AMIEL]

I Heard that HDX cards have lots of issues with I^ I & Intel processors...giving you instability, is that true??

[Doc Mixwell]

Originally Posted by AMIEL

I Heard that HDX cards have lots of issues with I^ I & Intel processors...giving you instability, is that true??

Do you have any documented info about this? I have not heard this before.

I have several HDX card's out in the field running with Mac Pro Intel machines, and I have had no complaints from them about stability. These systems are flying fast!!! I myself, have done several sessions with HDX on an Intel Machine, and had no stability issues with the system, in that time.

[UnderTow]

Originally Posted by OralnHardly

Delay Compensation works folks. Unless there ar third party plugs that don;t report it properly...in which case all DAWs suffer equally.

I was responding to this line from you: "PT10/HDX competely removes plugin latency." That is clearly incorrect: It doesn't remove the latency, it just adjusts recorded tracks to compensate. That doesn't work for live tracks for instance or plugins on buses etc.

Here is an example of where latency can become relevant: Recently on the post-production forum we were discussing what latency was acceptable for automation. (Riding the faders). If you have enough high latency inducing plugins, your fader automation will lag behind the actual audio. Not good. (And in case you didn't know, this latency is unavoidable).

Narrow minded thinking happens when folks think that technology is the answer to everything...and that bigger and faster is better.

I don't know whom you are arguing with but I didn't see anyone claim that technology is the answer to everything. Still, very often, it is the answer to many of the challenges we encounter. Actually, practically EVERYTHING we discuss on this forum is about technology being solutions to problems and opportunities for creativity. The fact that the technology is old and long established or brand spanking new doesn't change that. It is still technology. Some people prefer to work with old(er) technology. That's OK but it doesn't make it better.

I n the real world having specific technology devoted to specific tasks is much more reliable than technology that tries to do everything all the time.

This sounds like a truism on a simple and superficial level but I don't believe it to be true. My home native rig is as stable or more stable than any of the DSP based DAWs I work on. (And I push my native rig well beyond what would be possible on most of these DSP based rigs). In the real world it is all about the implementation. If you are comparing a HDX system to a native system, there is just as much software in the HDX system. Adding the DSP cards to the computer actually makes the whole system more complex.

This is the problem we see with native rigs. The philosophy is getting in the way of stability. No DAW developer wants to admit that "capping" the DAWs functions makes it more reliable under heavy loads.

The reason (most) native DAWs have no "capping" is because no native DAW developer can know what hardware you will run their DAW on and what new hardware will be available next year. (I am not talking about Pro Tools. The "capping" of native versions of PT is purely to prevent them from out-performing and out-competing the more expensive hardware based systems). Also customers would be furious if they could not use the full power of their systems because big brother decided that X number of tracks and Y number of plugins is more than enough to make the government approved music.

There is a reason that after 20+ years folks LOVE RADAR...is is not that sexy...at all...and also why folks love PT...relibility...

I'm sure RADAR systems are good and fit a particular need and budget but there are many reasons why people use any particular technology. Sometimes good reasons, sometimes not. Pretending there is only one reason is a bit silly IMO.

If all you need is straight recording a la RADAR then I would say pretty much any DAW can do that reliably. Combine the DAW software with good quality hardware and your system will be just as reliable.

having the latest bells and whistles is fun...but really...we are making music...how many tracks...how many plugs...how much processing do you think you need???

More.

I'm guessing the music you work with is not the same as I do. In electronic music, the layers and processing can add up pretty fast! (200 stereo tracks and one to two times that in plugins is not unusual). Not that I think a HDX system is the right choice for that type of production but these kind of blanket statements about what is needed to make music are rather meaningless and naive IMO.

If your answer is ...more...then I would strongly suggest that you aren't making music, but rather, you are nerding out over how "cool" your rig is.

So because you don't need more then no one else needs more and are just "nerding"?

Alistair

[Matt Hepworth]

Originally Posted by Doc Mixwell

Hi Matt,

The side note [**] state the following;

** Latency calculated using a 96 kHz sample rate with a 64-sample buffer. Tests run using Pro Tools|HDX and Pro Tools|HD Native with HD I/O, and Pro Tools|HD Accel with 192 I/O.

Sure, the 192 has greater amounts of latency than the HD I/O does, so one could look at it as "skewed", as the latency time will likely decrease on your TDM systems with an HD I/O. It simply appears, to me, they are matching system for system here, and its rightfully so. Old system versus the new ones. There is no reason to test HDX or HDN with the old legacy I/O, for latency spec, because that interface is no longer manufactured.

Hi Adam, I don't think you read my post or followed the link I posted. ;-)

That info IS skewed - and not by a little.