Waves Will NOT Be Supporting AAX-DSP!!!

[nerd513]

Originally Posted by Shan

What system exactly? This is quite the generalized statement when you say "any native system on any buffer", which is completely false. Obviously if you have an older under powered computer like a G5 & PT LE with the CPU maxed, it's not going to happen. I can clearly demonstrate that you indeed can even on a 3 year old i7, and so can many others. I have both HDX and HDN systems on Mac and PC, which makes it easy to A/B and demonstrate this clearly without any bias. You cant compare your old PT LE system to HDN, especially when you don't own one or never even used it, hence the internet myths are born and spread as "mythical fact".

Shane

with an 003 or a 002 or any mbox or the 001 it wasnt possible under any buffer... i dont see how the computer has anything to do with it... my computer would run and would record at the lowest buffer it just would have latency if i tried to track with plug ins... the statement is not generalized along with the latency the rtas would act very erratic... it is true i didnt bother with HDnative but i would bet my bottom dollar that tracking with plug ins is dodgy to say the least... and a 32buffer really??? how long is that gonna last 10-20 tracks? not to mention digi has never officially supported this idea that tracking with rtas plugins is somehow a good idea(which its not)...DSP on the other hand is a sure thing no latency tracking with TDM plugins at any point in the session as long as u have enough available DSP no latency ever... one more myth i would like to address probably started by the same numbskulls that started the "u can track with rtas plugins in HDnative absurdity"... so some people seem to think that while u can first insert a TDM plug and then an RTAS plug that u will magically then be able to track using rtas in HD without latency.... WRONG!!!!! u will have alot of latency and the dodgy rtas tracking... u will be able to use the rtas just like in native but it will be latency riddled and buggy just as it always has been... this is not choose ur own adventure people things work how they work... just because shan likes to be ghetto and record with rtas doesnt mean its advisable

[Shan]

Originally Posted by WernerF

How many native Decapitators can you run at 32 on a "modern" computer in HD Native while running a high track count session? Some real world numbers would be extremely helpful here. Most plugins don't bog my system down but this one, one of my favorites, for sure does.

You have a valid point here. This is something I don't know, but would be interested to find out. I myself have experienced one plug-in by iZotope a few years back that was very flaky at low buffer settings in native, as you just described. It's the only plug-in I experienced behave like this but nonetheless, I wouldn't see that behavior if it was running DSP. I think this is rare, but it would be a showstopper if my go to plug-ins attributed this behavior. It would be worth revisiting and checking both these plug-ins out in native. We were able to make some OS settings to sort out some of those "CPU spiky" plug-ins on W7 64 a few years back, but not in OSX as of yet.

Shane

[Firechild]

Originally Posted by Shan

The ideal solution is to have a multi buffer DAE engine. Playback tracks stay at 1024, while only record tracks and live MIDI tracks are at 32(or the user defined settings). This would put performance and stability through the roof on both HDX and HD native. It would also make using VI's in HDX/HD much more stable and usable.

Shane

That´s the way Logic Pro 9 works. Two separate buffers, one for playback and one for "live" elements.

[dave911]

Originally Posted by Emcha_audio

So in essence it's a dsp card (although a computing server) that is right in competition with avid.. hmm no wonder they don't want to make avid aax-dsp plugins

Looks like an i7 all on it's, doing just plugin processing.
These system are really for live sound but in general I would say it's AVID that wants to push a closed solution where they make the bucks on the high-end hardware and the main software and control the development approach.


From the soundgrid white paper.

Latency (roundtrip total)40* samples / 0.83 ms80* samples / 0.83ms"Audio Processing
Taking advantage of today’s extraordinary CPU power and the memory
capabilities of Native processing, SoundGrid runs on standard CPUs under custom
optimized Linux OS, resulting in predictability, stability, and low latency that was
previously exclusive to dedicated DSP-based systems. Consequently, SoundGrid
can run large numbers of Waves plug-ins, as well as extremely CPU-intensive
plug-ins that are beyond the capabilities of DSP-based systems. "

[Bob Olhsson]

There's no reason not to think 64 bit Pro Tools won't have this kind of native capability when it no longer needs to be compatible with RTAS and TDM.

[DarylG]

Originally Posted by Firechild

That´s the way Logic Pro 9 works. Two separate buffers, one for playback and one for "live" elements.

I don't really think that the implementation in Logic is anything that Pro Tools should try to emulate. It's pretty much a disaster in some areas. It was designed as a workaround for slow computers and an inefficient operating system, but these days it is more of a hindrance than a help, except with really under powered computers.

D

[Shan]

Originally Posted by DarylG

I don't really think that the implementation in Logic is anything that Pro Tools should try to emulate. It's pretty much a disaster in some areas. It was designed as a workaround for slow computers and an inefficient operating system, but these days it is more of a hindrance than a help, except with really under powered computers.

D

I wouldn't say the multi buffer alone is the big hindrance in Logic, but more so the combination of making the plug-ins inactive under the hood when no audio passes through them. This cant really be predicted with any type of look ahead algorithm in the CPU area. Any place in the timeline where no audio is passing through a plug-in, Logic will make the plug-in inactive under the hood. This is easy to see with a few benchmarks. Though a brilliant idea to reduce CPU load, it has no way to tell how much CPU is remaining or it's threshold and does it to everything. If there's an area with a lot of audio and plug-ins that surpass the CPU limit, Logic will active them all at once and bring the system to it's knees. Combine that with a mutli buffer system, and you'll definitely get problems when it spikes the CPU limit. It needs a little more intelligence in the algorithm for sessions that start to tax the CPU limit. A multi buffer system on it's own wouldn't have this type of unpredictability as the tracks and plug-ins are all active prior to recording, which establishes the CPU threshold in advance. One big advantage with PT is adding the new Disk Cache algorithm with this, which would greatly reduce CPU load as the audio in the timeline is all in RAM.

Shane

[Shan]

Originally Posted by nerd513

...DSP on the other hand is a sure thing no latency tracking with TDM plugins at any point in the session as long as u have enough available DSP no latency ever...

DSP plug-ins are not latency free as you continue to claim. Never have been, never will be. They have more latency than their Native counterparts. A difference anywhere between 3 to 10 samples.

DSP:



Native



Start putting DSP plug-ins in series without being careful or even aware of this, and you'll definitely hear the latency. The latency of the plug-ins get added to the throughput latency of the hardware I/O. DSP cards alone do not guarantee a latency free recording environment, just by the fact that plug-ins themselves arent latency free. Insert Maxim and tell us your latency free.

Sorry if you took offence to my post, but you need to back up what you're claiming as fact, which you have yet done. I've clearly demonstrated and shown my claims which anyone can go see and hear themselves.

In regards to your HDN statements, since you've never even tried it and somehow believe it's the same as your past PT LE/G5 experiences, I wont waste time on such a debate. If it really did what your claiming it does, none of us would even own it.

Shane

[Philthy]

Originally Posted by Shan

DSP plug-ins are not latency free as you continue to claim. Never have been, never will be. They have more latency than their Native counterparts. A difference anywhere between 3 to 10 samples.

DSP:



Native



Start putting DSP plug-ins in series without being careful or even aware of this, and you'll definitely hear the latency. The latency of the plug-ins get added to the throughput latency of the hardware I/O. DSP cards alone do not guarantee a latency free recording environment, just by the fact that plug-ins themselves arent latency free. Insert Maxim and tell us your latency free.

Sorry if you took offence to my post, but you need to back up what you're claiming as fact, which you have yet done. I've clearly demonstrated and shown my claims which anyone can go see and hear themselves.

In regards to your HDN statements, since you've never even tried it and somehow believe it's the same as your past PT LE/G5 experiences, I wont waste time on such a debate. If it really did what your claiming it does, none of us would even own it.

Shane

You're comparing apples to oranges. Those numbers ignore the host buffer setting required to run plugins off the host processor. You can start at 32 additional samples for any native plugin and go up from there as you push your processor with more native plugins. Plugins running on the ProTools DSP cards are not subject to host buffer latency.

"The table below indicates how much latency (in samples) is produced by each Waves plug-in." That's deceptive. They should point out that native plugins are dependent on an environment of host-induced latency from the start. You will never monitor through a native plugin with anything approaching 0 samples of latency, and in just about every situation the latency will be less through a DSP-hosted plugin vs a native plugin. Having spent years being forced to tweak my host buffer setting to successfully run native VI's I am painfully aware of this fact.

You talk about 96kHz sample rates and a 32 sample buffer... how about all the music studios still working at 44.1, which is still by far the most common sample rate I come across... what's that latency native? And how about when you're at 60 or 80 or 100 tracks and still cutting vocals into the session? You still running at a 32 sample buffer on the native system, and if not, what's the buffer setting at now, and what's the total latency at now? On the TDM system it's exactly the same as when you recorded the first track in your session... with 100 tracks, still less latency through a TDM plugin than through the native plugin in a session with one track.

[Shan]

Originally Posted by Philthy

You're comparing apples to oranges. Those numbers ignore the host buffer setting required to run plugins off the host processor. You can start at 32 additional samples for any native plugin and go up from there as you push your processor with more native plugins. Plugins running on the ProTools DSP cards are not subject to host buffer latency.

I'm not making any comparison to native systems here at all whatsoever, and that's not the point of my post. The throughput of the chosen buffer in native systems gets added to the latency of the plug-ins. In DSP the throughput is fixed at .7ms in HDX and 1ms in HD, which also gets added to the total latency of the DSP plug-ins. In native it relies on the chosen buffer setting which is 1.6ms at it's lowest and moves up from there. I've done throughput tests on everything I have. You've got no disagreement from me here at all.

On a different note, adding native plug-ins to a DSP system is a whole other story. I avoid that at all costs.

Shane