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

[Shan]

⇧⇧What nigelpry said above⇧⇧

In addition, just to add some reference material:

Originally Posted by ChazC

I may have missed this, but did they say we'd still have user control over the buffers or not?

Originally Posted by DAWgEAR

Will this provide any benefit for someone recording MIDI while playing a virtual instrument?

Originally Posted by Emcha_audio

AFAIK, I thought they said the input was fixed at 32 buffer. Will have to listen back to it.

The H/W buffer preference setting we currently use today, which is user defined, will now set the input channels only instead of being global for everything. Record armed MIDI and Audio tracks will use this setting as defined by the user in preferences. The playback tracks are fixed and made dynamic, hence not user defined in prefs and they don't need to be. Tony Cariddi describes the engine starting here. As far as how a system may work without being a computer programmer and having the code, older solutions that have been there make good conceptual analogies.

Hope that clears a few areas up.

Shane

[nst7]

I think this is pretty simple. It should be just like now, if you hit the spacebar, and you're at a 1024 buffer, there's a very slight delay from hitting the spacebar and seeing your session start to play.

Recording in this situation should be no different. You hit the spacebar to start recording, there's a delay of a few milliseconds, and it starts playing. Your record armed track is at a low buffer, so when you start actually singing or playing, you're hearing it at that low buffer and you start doing your thing.

When you're done, it moves your waveform where it needs to be to line up again.

In other words, by the time you actually record, the 1024 buffer delay has already happened and you're now singing or playing along with how you hear it.

I hope this makes sense.

[Emcha_audio]

Originally Posted by nst7

I think this is pretty simple. It should be just like now, if you hit the spacebar, and you're at a 1024 buffer, there's a very slight delay from hitting the spacebar and seeing your session start to play.

Recording in this situation should be no different. You hit the spacebar to start recording, there's a delay of a few milliseconds, and it starts playing. Your record armed track is at a low buffer, so when you start actually singing or playing, you're hearing it at that low buffer and you start doing your thing.

When you're done, it moves your waveform where it needs to be to line up again.

In other words, by the time you actually record, the 1024 buffer delay has already happened and you're now singing or playing along with how you hear it.

I hope this makes sense.

It does to me!

[scottgreiner]

Originally Posted by groundcontrol

Anybody who's missing mixing with a couple 2" and stereo/TC machines locked/chasing video? :)

Good lord - no! Don't forget to add in the land-patch delay offset for the remote ADR talent. Just thinking about all that makes my stomach hurt.

[Emcha_audio]

Originally Posted by groundcontrol

Anybody who's missing mixing with a couple 2" and stereo/TC machines locked/chasing video? :)

Sometimes as long as I don't have to cut or do the cleaning.. or calibration..

[nst7]

Here's an awkward analogy:

You are singing old school Karaoke, played back on a tape machine. You are singing into a microphone/PA system. Your mic/PA is a low/zero latency system, in the sense that you hear what you're doing instantaneously.

But when you press play on the Karaoke machine, there's a few seconds of tape hiss first, then the song starts. And then you start singing along.

The point is, it doesn't matter how low latency your mic/PA system is, because you don't start singing when you press the tape play button. You start singing when you finally hear the music, and then you're in perfect time. The low latency system (mic/PA) just allows you to do that and not hear a delay on your voice as your doing it.

So it's like this in Protools, and when you're done, Protools lines up and places in sync whatever needs to be placed.

[nigelpry]

I treat this start up delay like its an extra bit of pre-roll. Clients never notice that short delay before sound starts. Especially if they are in another room!

[DAWgEAR]

How is this going work with input monitoring through PT?

Let's assume the input buffer is 32 samples and the output buffer is 1024 samples and you are recording the talent who is singing along to prerecorded tracks. Using the karaoke analogy, the playback of the tracks can be compensated for but how about the live input? Doesn't that need to pass through the output buffer before the talent can hear his/her own voice?

Or is it implied that the input is going to be sent through an (separate?) output buffer of 32 samples? And that the compensation of the prerecorded tracks will take 64 samples into account.

Apologies if this is a stupid question.

[Shan]

Originally Posted by DAWgEAR

How is this going work with input monitoring through PT?

It would have to be treated the same as record enabled tracks, hence use the lower buffer.

Shane

Sent from a plutonium-powered DeLorean in 1985 trying to get Back to the Future

[bortraws]

It will work exactly like NST7 said.

Let me try to explain it in a very simple way.

You always sing or play along to the previously recorded tracks. These tracks can have plenty of delay induced by plugins. The delay on the tracks playing back doesn't matter. You just start singing or playing your instrument as soon as you hear the tracks playing.

To keep the explanation simple let's leave plugins and ADC out of it for now.

Let's say your output buffer is 1024 samples (you won't actually know the output buffer because it will be calculated dynamically but just for the explanation we'll say 1024). So after you hit record all tracks that play back actually do so 1024 samples late. In other words there will be a 1024 samples delay before recording and playback commences

You start singing or playing on the rec enabled track(s) with an input buffer of let's say 32 samples. (Forget plugins on the rec enabled tracks for now I'll come to that later). You time your playing or singing to the 1024 samples delayed tracks. The audio coming in on the tracks recording are send back to the monitors with only 32 samples of delay. So you hear your voice or instrument 32 samples later.

The recorded voice or instrument is actually 1024 + 32 samples late against the clips on the tracks that are playing back. Therefore the recorded clips will automatically be corrected (e.g. shifted earlier in time) by 1056 samples.

Now when you have plugins on the track(s) you are recording on, their latency will be added to the 32 samples of the input buffer. So if you had a plugin with for example 10 samples delay on the recording track, you are hearing your voice or instrument 42 samples later. Thus your singing is 42 samples late. The recorded clips will then be shifted 1024 + 32 + 10 = 1066 samples earlier in time.

Having low latency monitoring on, will of course work exactly as it used to do by deactivating all plugins and sends on the rec enabled tracks.

Now back to the dynamic output buffer. I chose 1024 for my example but the exact number will actually be the highest number of delay induced by plugins on a specific track plus the hardware buffer needed for the CPU to process all the activated plugins on all tracks.

Hopefully that explains it a bit.