PDC is killing my love for LOGIC

[skijumptoes]

These producers are probably in the mixing phase, and not live recording perhaps? AND they know their plugins inside out as to what causes latency.

 

I mean any plugin that's adding latency is going to affect the time it takes for the sound to be processed, there's no way around that. All i can think is that you're using something with a high lookahead value which you need to tone down and it won't affect the sound when you're recording in any serious way.

 

i.e. for example, if i loaded up Logic multi-compressor, by default it's giving me 2m latency... not huge.

 

If i was to select a preset with a longer lookahead value, then it rises significantly:-

 

You can see the latency that plugin it causing is directly in relation to the lookahead value i (or the preset) is using in the plugin itself.

 

It's issues like that you've got to be aware of, and that's for any DAW. Whenever you get an issue, always refer back to what the plugins are reporting to Logic. Most of the time you can adjust lookahead right down and it doesn't make a huge difference... In the final mix, yeah, then it gets more critical.

 

If no value is reported then the plugin isn't adding any latency to the project, i think that means it's being processed before the audio buffer expires.... Not sure though.

[robreed2]

You may be right re mix mode, a good friend of mine ( a prominent pro tools use) laughed at me when I asked about this...and just said buy pro tools...I did check it out, but there was a million and one other reasons to hate it..... Ill do more investigation. Edited February 5, 2019 by robreed2

[Dewdman42]

Logic pdc works as follows: audio and instrument tracks playback their regions early in order to compensate. Aux, bus, output channels with latency cause all other channels to be delayed to compensate.

 

Note that when you record to an audio or Inst track there is no region that can be played early, logic expects the player to do it.

 

Hardware monitoring is where the problem is here. As far as I know you have to adjust the record delay slider in prefs after you figure out how much. The problem is not PDC, it’s the recording offset

[robreed2]

thanks Dewdman... Ill check that out, are you saying that if adjust this setting, it will automatically move my newly recorded over dub ( that would normally play back out of time, and play it back in time ), that Ive done to a mix set with PDC to all..?

[Dewdman42]

That’s what that slider does. It adjusts where in the region newly recorded material lands. After you record your overdub if it shows up in the region early or late, adjust the slider. Note though that you will want to set it back to zero when recording software instruments or using software monitoring. And the exact value to use while hardware monitoring will depend on your audio buffer size and latency on your aux, bus, output channels

[skijumptoes]

Just remember it's a moving target though, if you have it set up and then place or remove plugins which could further disrupt the PDC allowance then you will have to re-adjust it to match.

 

Maybe pro tools does that automatically?

 

In fact, why doesn't logic do it automatically if it knows the total PDC applied? Seems quite an easy function to put in to me? Does disabling software monitoring affect the behaviour, do you know dewdman? I know in Ableton Live, depending on what you use to monitor it would apply a recording offset or not. But i'm sure that was based on audio buffer, not PDC.

[Dewdman42]

I do not know but I agree logic may need a hardware monitoring button

[broza2broza]

Yes it is frustrating but all I WANT is Logic to remember within each song whether you left it in track PDC mode or ALL PDC mode! Rather than going back to a session and having to hear it out of time before you realize you need to switch PDC modes. Not sure why this is so hard to implement.

[skijumptoes]

Oh wait, i've been playing around with this - it's so simple, you just turn off Software Monitoring in Logic Preferences > Audio > General.

 

And what you play is in sync, just tried it with a drum loop going through a (track stack) bus with 8x 20ms compressors, played guitar in time (by ear), played back and bingo!. Works great, and REALLY handy to know. Just need that as a quick icon now.

 

Edit: Sorry, just realised OP wants the effects live - ignore me please... lol

 

Edit2: No, wait it IS what they want, as they're hardware monitoring. Someone please tell me i'm not going mad.

 

Edit3: There is a key command and icon for Software monitoring. Damn, i'm gonna make a ton of use out of this now. All this time i've been arming tracks and muting it for my outboard, this is a game changer! Getting assigned to F8 on my MCU as i type! )))

[robreed2]

hi SKI

Are you saying we can leave it with PDC set to ALL, and now be able to record through hardware and it will play back what was recorded in time.??? if you turn off SOFTWARE monitor.?

[Ploki]

this thread is a mess

[skijumptoes]

hi SKI

Are you saying we can leave it with PDC set to ALL, and now be able to record through hardware and it will play back what was recorded in time.??? if you turn off SOFTWARE monitor.?

Exactly that, i've been trying it with guitar and some synths with arps in time to heavy processed bussed tracks and it all seems to align with Software Monitoring off. I'm amazed i never knew this, and it's not been brought up on this thread to be honest.

 

As Ploki says above though, it's a bit messy thread so maybe it was a case of not seeing the wind for the breeze, as they say. But, this is a massive discovery for me, if it turns out to be reliable. My workflow previously has been jumping through hoops in comparison. And if i ever got sync issues i'd just render down to audio so i didn't get caught up wasting time.

 

Plus, you can set the 'software monitor' mode as a button on your toolbar at the top, and save as default for all future sessions. It's something i would go between off and on states, depending on what i'm doing.

[Dewdman42]

I didn't really know about it either. I did actually ask everyone earlier today if anybody knows about a way to change the software monitoring.

 

I can't find any information about how recording offset is handled in this mode, so I will have to do some testing. It certainly seems like the right way to work when hardware monitoring. I was away from my computer all day or I would have checked myself. Thanks for finding it!

 

one concern I have is that I have to set the record delay to a certain number of samples for my audio device to be spot on. Doing a loopback test, you determine how many samples to adjust and set it in the record delay. Then a loopback, which includes A/D and D/A, both going out and coming back in, ensures software monitored sound is added to regions exactly where it should be. However, when using hardware monitoring, then I believe that record delay value is probably wrong since what I am hearing is not going through the sound card at all... And what I don't know is whether software monitoring OFF corrects that or if I will still have to fiddle around with record delay... There is just not enough information provided to know for sure.

[skijumptoes]

I did do a loopback test, as i too normally run with a recording delay setting, and there is a very slight existence there with hardware monitor (38 samples), but i'm putting that down to the audio interface latency and drivers.

 

I have set it to zero now and just going from there. It would take going over 20ms for me to really notice it, and i can't see any chance of that happening, but it would be nice to adjust by the finest amount and have everything spot on for OCD's sake.

 

As a side note, Countless times in the past i've record enabled a track, then muted it so i can monitor through my mixing desk and then nudged the audio region delay parameter afterwards. It's just been part of my workflow, this just seems to make many tasks so much easier.

 

In fact, this whole thread, while a bit heavy, has really helped me build an understanding of what is going on under the hood there too.

[Dewdman42]

I'm a little tired right now, so maybe the answer is obvious, but I can't really figure out a good way to do a sample accurate loopback test for hardware monitoring. In the case of software monitoring, you have sound going out D/A...and then looping back in A/D. The I/O utility in loopback will tell you how many samples it takes to do RTL beyond whatever the audio device driver is reporting.

 

Ok..fine so far, but with hardware monitoring you are dealing with the sound outside the box...which means its not a true RTL....its just one direction...the sound coming in, that has to be taken into consideration in some way when calculating the record offset. So if the audio device driver is already accurate, then it has numbers for incoming and outgoing and presumably Logic would use just the incoming number to calculate the record offset to use when you record while using software monitoring off. You say it sounds tight, I will take your word for it, but I don't really have a good way to test that out.. But then the situation becomes more complicated if your audio device, like many, does not report the correct RTL, often times they are off by 50 samples, as is mine. So what then should I adjust the record offset to -25 samples instead of -50 samples when I'm using hardware monitoring? (shrug)...I don't really know and I can't think of any good way to do a calibration to figure out for sure.

[robinloops]

I use metronome to my headphones and hold them up to a mic to record it. Then I do the same using the audio track just recorded as the sound source and record it again. Then I zoom way in and check the offset. Once I find a zero crossing on the source audio, I leave playehead in that location. Now open the audio editor and use the select tool to select from the playhead to the same zero crossing and make note of the number of samples selected. Then make the adjustment to the pdc setting and repeat process to check. Worked great and compensated for anything the audio goes through on its way to the speaker (or headphone), theoretically including the time it takes a sample to travel through the air to my ears. When it’s dialed in perfectly all three will line up with precision.

 

You can also connect an output to an input (with a cable) and use the i/o plugin to find the time it takes audio to go out and come back in. But I have had better results with the first method.

 

Note: for either of these methods to work the audio must be routed through any external hardware you need to add to the equation. For doing the same test on any digital processors I use my external mixer to add that to the path. Otherwise you could just rewire you main output through it.

Edited February 6, 2019 by robinloops

[Dewdman42]

The I/O plugin is very easy to use, but again...its not clear to me that the value determined that way applies to direct hardware monitoring since these methods detect Round Trip Latency, and with direct hardware monitoring, there is only incoming audio...not round trip. So the record delay value must be wrong..probably something close to double what it needs to be...but I can't think of a way to test or verify that.

[skijumptoes]

Trouble with Logic metronome is that it is within the scope of PDC, and going through the DA then AD loop. I think dewd wants a way that’s generated totally externally (I.e. exempt from DA) and only travels AD. But is also a guaranteed source of Logics timing.

 

That’s too much for me to worry about personally, but maybe a sequenced click on each beat to an external MIDI device, whos audio output is recorded into Logic provides that kind of test?

 

Would require aligning by eye to beat divisions to ascertain the delay.

 

Personally speaking, if I can’t hear it on playback, i won’t even worry.

[Dewdman42]

Yes I know I'm being OCD right now. hehe. midi clicks aren't accurate enough at all to determine that.

[robreed2]

Ok..Tried the software On/Off and it works... !

 

BUT...?

 

The way I work with hardware monitoring, is that I like to SEND TO AUX to reverb and delay VIA the input/record track,

this is now gone when you switch software monitoring off.... as I have no other hardware reverbs, etc...Its a bit of pain, if adding a guitar or vocal...it would be bone dry...ANY thoughts.... its so close to being amazing.!

[skijumptoes]

Software On and PDC set to 'Audio and Instruments', should work for you then? ..in theory... maybe... lol

 

The aux will be delayed a bit, but that's a given if there's latency on a plugin that exists... However, your recording should be ok, as it's Aux busses with latency that create this phenomena that you're experiencing.

 

But PDC back on 'All' when you're not recording, of course.

[Dewdman42]

ski, the problem is still related to the record offset, which is not where he wants it in software monitoring mode. The record offset is effected not only by PDC, but also by audio buffer latency. I'm not sure the PDC pref setting will solve his desire. But my brain is exploding along with everyone else's on this thread trying to deduce it.

 

Robreed2 from you last post it sounds like turning off software monitoring is not an option because in fact you want to use software monitoring in order to use software reverbs and perhaps other things...on AUX channels.

 

software monitoring does two things. It turns on the flow of input audio through the logic mixer...and it also adjusts the record offset of where on the timeline incoming audio will recorded into regions. And that offset is not based only on PDC, its also based on the sound card audio buffer size and latency associated with it.

 

If you are listening to your drums through hardware without any latency, then you probably want software monitoring off so that the audio will be registered to the right place on the timeline based on how you heard it as you played it relative to click. Unfortunately that means you won't be able to use software reverb while you do that.

 

If you want software reverb on while you do that, then you have to turn software monitoring on, which will then mean that you need to listen to your drums through the Logic mixer also, with all its latency, which I doubt you want, but the record offset will assume you are. So if you're using hardware monitoring to actually hear your drums, while Logic has software monitoring mode on...you will not end up with your drums recorded to the right place on the timeline as you would be expecting. Even if you could combine the two modes, the reverb you are using in software would be delayed by some amount compared to the hardware monitoring you're hearing. In theory that might be ok with say a reverb, it would just be acting like a latency-induced pre-delay. Ok. But the real problem here is that Logic is going to assume, with software monitoring on, that you are listening to the software mixer, not the hardware direct sound...and it will register your recorded audio to the region based on when it thinks you are hearing it.

 

That is based on the presumption that people will tend to play things early, subconsciously adjusting how they play so that the actual sound they hear is on the click. In truth, we probably do that, but I think with longer latencies we don't. Just my opinion. In any case, the point is, Logic assumes you are doing that...even if its a longer latency and that you are listening through the software mixer...not the real drums in the room or direct from the hardware...when software monitoring is on. it assumes that what you heard and played relative to click is what you want, after taking into consideration PDC and audio card latency, it places the audio into the "right" place in the region.

 

The only other way to work around that would be to use software monitoring mode on and adjust the record delay slider until recordings are landing where they are supposed to, while you listen to your direct monitoring, along with delayed software plugins and whatever they add to the sound. You can probably figure out how to calculate a value for the record delay or just slide it until you like the results.

 

Then later when you are recording software instruments and mixing, change the slider back to 0.

[Dewdman42]

Regarding the PDC pref setting, setting to only audio and instruments would result in AUX channels still being delayed, while audio and instrument channels are not delayed, the way you hear them..including the click itself would not be delayed, UNLESS the audio track in question is bussed to a latent AUX channel, then they would sound delayed.

 

So in theory that might lessen the impact of the record offset issue, but there would still be an issue due to audio buffer latency. Also, to be clear, without some tests to figure out for sure, we don't really know for sure that the record offset still won't be wrong even if the AUX PDC is off. If Logic assumes that when we hear it is when we want it, the AUX channels would be delayed...the audio channels would not be delayed any more then audio buffer latency and any plugins that are on the audio tracks themselves, unless they are bussed to an AUX, then they would sound delayed...so... So the PDC engine is one thing, but the record offset calculation is a separate issue...and I believe in general LPX is going to factor that calculation based on when it thinks you heard the sound relative to click.

Edited February 7, 2019 by Dewdman42

[Dewdman42]

Someone needs to make a mind map of all of this and show all the possible workflows people try to do and what the LPX PDC and monitoring settings need to be for each situation.

[skijumptoes]

Hey, there's only 12 combinations.

 

[Dewdman42]

Don't forget the other dimension of adjusting the record delay slider

[Dewdman42]

Well anyway, not all of those 12 combinations are actually useful. The grid to think about is more like use cases, and in each use case, which one of the 12 combinations, in combination with the record delay slider..is the one to use.

[Dewdman42]

another couple dimensions to add including substituting non-latent temporary plugins and using external outboard FX while tracking, as adding more possible solutions in combination with the above 12.

[skijumptoes]

I may be tempted to just set up 30ms latency on inserts, and 60ms on busses and run some tests. All we're interested in to start with is how the audio sounds live when software monitoring, and how it records when not software monitoring, right? Initially i mean. The results would determine their suitability.

 

What i don't get is how robreed2 is hardware monitoring, yet hearing a bus reacting to their live recording.

 

All i can think is they are using a pre-fader send, with fader down on the track they are recording into? Otherwise it must sound terrible what they're doing, i.e. could effectively be hearing 2 additional monitor sources during recording behind/on top of the hardware/dry monitor. I think that would annoy me as much as the delay!

[Dewdman42]

Here are some free plugins that might help you in testing:

 

https://www.voxengo.com/product/latencydelay/

That one is a little confusing because it adds 10,000 samples of delay MINUS whatever value you set. So you leave it set to zero, it adds 10,000 samples of delay and reports that much to PDC engine.

 

http://www.expert-sleepers.co.uk/latencyfixer.html - That one does not add any delay. But what it does is report a latency amount to the host to force PDC to engage. This is a useful tool to get PDC to engage without adding any delay, but may or may not be useful for testing our theories, where you need to get both the delay and the reporting. if you use a delay plugin in combination with this one, then you can basically get both things..the delay as well as reported latency, at whatever length you wish.

Edited February 8, 2019 by Dewdman42