Who else doesn't get how different input and output buffers shall work?
 

Is it just me or is anyone else not able to explain how two separate buffers shall work? How could you record with an input buffer of 32 samples when your output buffer is 1024 samples (or more) and still be in time? Any theories? I say it's impossible without deactivating all plug-ins when recording that induce more than 32 samples of latency, which would be flawed of course.

Re: Who else doesn't get how different input and output buffers shall work?
 

I can't really explain the technicalities behind this feature, but it allows you to track with ultra-low latency (low latency input buffer), but still have a larger playback buffer setting for VIs and plugins in general. This is great because we no longer have to sacrifice CPU power (decrease the buffer) to track with very low latency.

Huge feature in my opinion, and I can't see why it should be impossible.

Re: Who else doesn't get how different input and output buffers shall work?
 

I think it's really just the mystery that surrounds it. It was pretty confusing to me, too, and I imagine to many others.

I certainly have a few questions about it... How exactly does it keep latency low? If output buffer is automatic, then will latency be dynamic? What kind of latency should we expect? If we set the input buffer to 32, can we expect a consistently low input delay even with a large session? Does this really mean the end of CPU spikes and error messages? Is there any other hidden cost like artifacts?

Re: Who else doesn't get how different input and output buffers shall work?
 

Yes, I know, that's what the press release says, but think about it: with one or many plug-in that are inducing a lot of latency on a record-enabled track it's impossible to have no latency on the headphones when monitoring it without disabling the plug-ins.

Re: Who else doesn't get how different input and output buffers shall work?
 

The only thing that I can imagine is that the output buffer is automatically set to the amount of samples the delay compensation is reporting. I still can't think of a way how it should be possible to record with plug-ins and still have 32 samples of latency (even if the plug-ins need more samples for processing).

Re: Who else doesn't get how different input and output buffers shall work?
 

Well... they claim to have figured it out. At this point, only time will tell when users actually start getting their hands on the software.

Re: Who else doesn't get how different input and output buffers shall work?
 

DC-Out (High) ---- Listening
DC-in (Low) -----Playing to the above without noticeable delay

Or the old/current way

DC-Out (High) ---- Listening
DC-in (Same High) -----Playing to the above with noticeable delay

How they do this is for programmers (and Discovery's How it's Made)
As a user, if this works, I'm happy.
One less thing to keep adjusting.

Re: Who else doesn't get how different input and output buffers shall work?
 

No facts - but here is my conjecture...

It is simple to take existing tracks and time shift them in the application so they all play together no matter what plugins are present.

For the input side it seems quite illogical that you can have any plug in present to monitor through that adds any substantial delay to the input buffer. With the AAX improvements a great number of EQ's and Dynamics should be zero delay adders. Guitar simulators and other VI's is where it becomes not as clear. At some point the delay of one of these could exceed the input buffer.

Re: Who else doesn't get how different input and output buffers shall work?
 

See this is where I become interested in how the separate buffer system works. Eventually, there will be delay added if you load up the tracks enough. I want to know how that will affect the delay of a buffer set at 32.

Re: Who else doesn't get how different input and output buffers shall work?
 

the number of gets is reduced on the playback buffer therefore reducin' the CPU load for reads durin' playback of all trax except those in record mode. the ADC still takes care of timing playback. the old/current way places a HUGE load on the entire session because the record/playback buffers are the same. so if you have 100 trax all at 32 buffer the gets and puts are workin' their azzes off. reduce the gets for reads and your cpu load goes down...a lot!!! make sense??? maybe???:D