PDC is killing my love for LOGIC

[skijumptoes]

.. then use the routing system shown to send the over dubbed vocal or guitar to a internal reverb or delay when track laying them ( I can live with a slight delay on these, just to give a bit of feel)

 

Don't forget to try this option if you want to hear the bus fx while playing AND your recording stay in sync:-

Software Monitor = ON

PDC = Audio & Instruments

 

If it suffices for your needs, great, super simple.

[drakepeterdrake]

I'm only going by what's coming out of the speakers re the absence of unwanted predelay with the setup I described. I in fact do have an aux with 200 ms of plugins and it does not effect the reverbs in any way. I don't know what would happen with recording, as I don't intend to record with plugins, etc. I'm just trying this in a mix situation whereby I can keep my reverbs from being unintentionally predelayed by latency-inducing plugins being placed in auxes. So far it seems to work. My ither question was whether I had to make up these inputs in the environment for each new song or if they could be saved as a template, etc.?

[Dewdman42]

it is another nice approach actually the way you're using a dedicated channel on your console to use as a send into LPX, and just return the audio back to the console again. So that basically your hardware monitoring in the console, includes that bit...and its not leaking anywhere else in Logic. Just be advised, that you will still be getting some latency from that plugin... and that plugin will still effect PDC on other channels of the mixer and visa versa.... but at least its totally separated from the record offset issue and to a certain degree you can manage all of your monitoring from your console rather then inside LPX.

[Dewdman42]

.. then use the routing system shown to send the over dubbed vocal or guitar to a internal reverb or delay when track laying them ( I can live with a slight delay on these, just to give a bit of feel)

 

Don't forget to try this option if you want to hear the bus fx while playing AND your recording stay in sync:-

Software Monitor = ON

PDC = Audio & Instruments

 

If it suffices for your needs, great, super simple.

 

yes it will work, but while you're using that approach your other tracks may not be properly in sync.

[robreed2]

Hi SKI

Don't forget to try this option if you want to hear the bus fx while playing AND your recording stay in sync:-

Software Monitor = ON

PDC = Audio & Instruments

 

If it suffices for your needs, great, super simple.

 

 

 

THATS how Ive always worked, but the start of ALL of this was the nightmare with FX on buses in that mode.... BUT hopefully thats all sorted..! TA

[Dewdman42]

I'm only going by what's coming out of the speakers re the absence of unwanted predelay with the setup I described. I in fact do have an aux with 200 ms of plugins and it does not effect the reverbs in any way. I don't know what would happen with recording, as I don't intend to record with plugins, etc. I'm just trying this in a mix situation whereby I can keep my reverbs from being unintentionally predelayed by latency-inducing plugins being placed in auxes. So far it seems to work. My ither question was whether I had to make up these inputs in the environment for each new song or if they could be saved as a template, etc.?

 

that doesn't make complete sense to me and I have to go out the door now so I won't be able to continue this discussion until a few days from now most likely... but anyway, If you have PDC set to all and you have another AUX with 200ms of latency, then this one should be getting delayed too... but hey...maybe not...

 

yes you have to save it in a template.

[Dewdman42]

Dewdman, I think I have made it work for my purposes. In the environment I created an input, named it "emt feed," assigned input 21 to it, had it output to bus 10. I assigned the send on my console to that input. Created an aux, bus 10, placed the UAD 140 into it. As shown in the screenshot, there is about 200 ms of latency in the sum marked BV. This has no impact on the predelay of the UAD in Aux 5 while it is being fed signal from my console. All this is while PDC is set to "ALL." So, for my reverbs, I have essentially crested live feeds for them that are not subject to PDC, which is wonderful. There are a couple of oddities: while the EMT 140 plugin is fully functional, for some reason the input meter on the plugin itself shows no input, even though I am cranking into it. This is a minor issue. Also, no level shows on the meter of the "emt feed," also not an issue. Output does show on the main console from the UAD 140, which is sent back to the console. Software monitoring is off.

 

My questions are these: In your earlier post you said the input I created, here called "emt feed" would show up on the main console, but it doesn't. Not a big problem. Also, if I set up these live feeds for the 6 or so reverbs I use in a typical mix, can I use this setup in other songs or do i have to create live inputs for each song.

 

Thanks again.

P

 

By the way, in that situation it probably would be truly simpler for you to just use a single AUX channel, you don't need to bother creating the input channel for it. You're not bussing channels together or anything. for the plugin you're taking as a send from the console that is. And other approach would be to use that I/O plugin in some capacity... because truly you are trying to isolate that channel away from the rest of your logic mix and just use it as a send from the console. But it all works and I think it will just depend on your workflow and/or how you want to layout the mixer, etc..

 

ok really gotta run....hope you guys figure out in the next few days, I will be pretty much offline until tuesday

[drakepeterdrake]

My experiments were wrong. The setup I showed in the above screenshot, shows the bv track being fed by bus 2, going to outputs 5-6. If you delete that bv track, then import or create another sum for the bv and place latency-inducing plugins, it creates the unwanted pre-delay I spoke of earlier, when PDC is set to ALL. W hy it works in the test, but not in a real-life situation is beyond me. I took a working test, then imported an bv setup from another song, and all the latency issues came back. All is lost.

[drakepeterdrake]

I went back and rebuilt things using the I/O plugin for the reverbs, and so far, in several songs, this seems to be working.

P

[Dewdman42]

Yep. What I am deducing is that the OUTPUT of AUX channels is where PDC is applied.. So if you use an I/O plugin to get the AUX channel stuff after your plugins but before hitting the OUTPUT stage from the channel then the PDC won't be applied to it. Like this:

 

 

same result here, regardless of latency on other AUX channels, this one ignores the PDC...so it could be used as an FX bus for the console itself...only latency will be that imposed by audio device. Actually in my case because I'm using an X32 and the audio is already in digital domain before hitting the send, I expect it to be 2.8ms RTL at 64 buffer...which is quite usable. Not sure how I could test that theory, but anyway, its not a bad way to go if the console has the ability to isolate a send. Because I'm using up all my inputs on my X32, I had to do some funky routing to test it out, but it definitely works here too!

 

One downside is that the channel meter won't show the audio going through it. Have to use some plugin that has a meter on it in order to see what is happening before hitting the I/O plugin. The above can be done with one simple AUX or INPUT channel, I see no difference other then where the channel strip will be placed on the mixer from left to right, etc.

 

I like that peter drake. Please let us know how any of this effects your external midi issues from before...I assume this is mainly by getting software monitoring off that record offset might be correct now.

[Dewdman42]

But the above assumption also makes me realize that for people without a fancy hardware console with sends, they could simply use the I/O plugin instead of the channel OUPUT, of any AUX channel, regardless of the source, in order to avoid PDC on it..so long as it doesn't have to be bussed anywhere else in Logic. if it just needs to go to the stereo outs...

 

So for example...here's some of my previous examples....but adding the I/O strategy on the AUX FX bus to avoid the PDC applied to it:

 

 

So in the above example... two input channels have input coming in to be recorded. The INPUT channels are bussed to the AUX FX bus...where the output is intercepted by I/O plugin rather then going through the channel output and mixer. I added another AUX channel with 10,000 samples of latency and the AUX FX channel is unaffected by that. But everything else would be! Buyer beware... but anyway... more to chew on...

[Dewdman42]

I want to point out one more thing about this mode. If you isolate an AUX channel with the I/O plugin so that it will not be effected by PDC from other AUX channels that have longer latency, that is fine and good, but its still good to remember that THIS aux channel, the one you're trying to isolate, will still effect all other channels in the project if it has any latency itself, unless either: (A) PDC mode is set to AudioInstOnly, or (B), you use the I/O plugin on all of them to keep them from being effected by the latency of your AUX channel.

 

The advantage of option (A) is that its easy to turn on and off, the disadvantage is that its global and so all other tracks/channels in the project that have AUX channel interactions may not be playing synronized as expected until you set PDC back to ALL again.

 

The advantage of option (B) is that you can explicitly determine which channels should be effected by the latency of other latent AUX channels in the project, the main disadvantage is that you would have to add that I/O plugin literally to every channel and if you're using busses it could be messy and difficult to manage...its a kludge that way.

 

I also want to point out one more option that hasn't been talked about thus far. It may be preferable to setup a completely separate AU host application to use for hosting a monitoring FX bus, rather then inside LPX. In this way, it would not be effected by PDC and its own latency would not effect any other tracks/channels. You could, for example, use MainStage or AuLab, or some other simple AU host... it would do what it needs to do without any PDC interactions. I think in many cases that might be preferable when used for monitoring while recording through hardware monitoring in general. Kind of a hassle though and I would assume CPU usage would be quite a bit worse.

[drakepeterdrake]

Hi, Dewdman,

 

I haven't even thought about the MIDI nightmare - I pretty much now just use LPX internal instruments to write and then my external synths when it's time to mix. However, my experience with the I/O plugin on reverbs was somewhat different than yours. I put it in front of the reverb, as shown in the screenshot. So far I'm getting no PDC-induced predelay in the reverbs, even when adding a bus to the mix that has a lot of plugins. I found that after setting things up with the I/O plugin, I still assigned the output of the reverbs to outputs in the mixer, especially as I was using a mono-to-stereo reverb and the I/O plugin didn't seem to have that, so I used mono. Even using a mono I/O, I got stereo reverb by assigning the reverb out to a stereo pair. By making sure there was no input on the channel strip and that the output was assigned to where I wanted it, I got good results.

P

[Dewdman42]

When you use the i/o plugin for output you are bypassing pdc on that channel in terms of other aux channels having any delaying effect on it. However the channel with I/o plugin can still impact other channels if it has more latency then anything else. But it will also cause the metronome to be delayed so when the metronome is delayed it will all sound fine but if another instrument on an instrument track is delayed because of your I/o channel you will experiemce that delay when you try to actually play it. You cannot avoid this unless you change pdc to audioinstonly

[drakepeterdrake]

It sounds like it would be best to save all this for mixing, and then keep latency-inducing plugins to a minimum on auxes of any type. I think it's ridiculous that we even have to have this type of conversation. Those smarty-pants at Apple should be able to figure this out.

[Dewdman42]

Generally if you put latency plugin anywhere while recording tracks you are going to experience heartache I don’t care what daw you’re on, there really isn’t any way around it. There is no magic way to get rid of latency. They are trying their best to make sure tracks play in sync. Logic has the “bug” related to the record offset when aux plugs have latency but aside from that I don’t see anything it can’t do that others can. I have found numerous cubase users complaining too. Latency is a complicated issue and logic tries to give options. Were it not for that “bug” we wouldn’t even be talking about the workaround. But even without that “bug” you still end up with latency delays to the point that in any daw you’re just better off avoiding latent plugins while recording tracks and even further using hardware monitoring whenever possible

[Dewdman42]

Hi, Dewdman,

 

I haven't even thought about the MIDI nightmare - I pretty much now just use LPX internal instruments to write and then my external synths when it's time to mix. However, my experience with the I/O plugin on reverbs was somewhat different than yours. I put it in front of the reverb, as shown in the screenshot. So far I'm getting no PDC-induced predelay in the reverbs, even when adding a bus to the mix that has a lot of plugins. I found that after setting things up with the I/O plugin, I still assigned the output of the reverbs to outputs in the mixer, especially as I was using a mono-to-stereo reverb and the I/O plugin didn't seem to have that, so I used mono. Even using a mono I/O, I got stereo reverb by assigning the reverb out to a stereo pair. By making sure there was no input on the channel strip and that the output was assigned to where I wanted it, I got good results.

P

 

I was just looking at your image above, now that I'm back to my own computer... one thing I notice is that you might not be using the I/O plugin quite right. You have both the input and output audio ports defined in I/O and I don't think that is doing what you might be thinking it is doing.

 

The I/O plugin is primarily designed for a different purpose, which is to setup an external FX loop out to hardware FX units. So you specify that output audio port for the send...and the incoming audio port for the return. Note that audio comes into the channel strip and then hits the plugin stack. When it hits the I/O plugin (in its normal use), the audio goes OUT and then comes back in...then whatever comes back in is routed down the rest of the plugin stack. The order matters here. Audio enters the plugin...first goes to OUT and then receives the IN and finally that result is sent to the next plugin in the stack.

 

You are attempting to highjack this plugin for a slightly different use here, in that its the other direction. You want the audio to come IN first...go down the rest of the plugin stack and then finally go back out again. Think that through a little bit and check your results. Using the I/O plugin with both ports specified I do not think is doing what you want...as it will by default assume the the channel sends the input to the OUT FIRST and then receives the INPUT second...and you need the inverse relationship for your use.

 

When I used one, I put the I/O plugin at the bottom of the plugin stack.. so the audio came in from the normal input source...then down through the plugins, then rather then feeding through the channel's output and mixed in the mixer (with PDC)...use I/O to just send the audio out. The Input is ignored in the plugin at that point. like this:

 

 

The main point is that it bypasses the rest of the channel strip, takes the final audio directly to the audio port and completely skips being fed to the mixer with its PDC.

 

if you wanted to bypass the input to the channel strip also, using I/O plugin for that as well, you'd need to use two instances of the I/O plugin, one to handle input and the other to handle output. I don't think this is necessary though because I think the PDC is handled when the channel strip result is fed into the mixer on its way to an output the normal way. By using I/O plugin for the output, you skip the PDC of that strip. but anyway, if you wanted to handle both input and output from I/O plugin, you'd need to do it like this:

 

 

And as previously noted, even when you use I/O plugin to avoid the channel having extra latency added to it by PDC, you still can't get around the fact that the existence of the plugins on this channel strip will still effect other channels in the project if it is the longest latency channel, then other channels will all be delayed to match it.

[drakepeterdrake]

Thanks, I'll play with that. I had in fact tried using the I/O plugin before and after the reverbs, but found that by just having it placed before the reverb, it seems to work fine. I have no unwanted predelay on the reverbs. I'm sure if i had a huge latency reverb it might mess with all the other auxes, but the fact is I never have more than 1 UAD reverb, about 25 ms latency, which is far less than I am using in other channels. Also, bear in mind that I'm only doing this for mixing/playback and not trying to record through any channel with an aux, etc.

[Dewdman42]

The way you have it before the plugins cannot possibly be working fine... This is the chain I see happening in your setup...

 

channel 19 console--->I/O Plugin IN--->> through the UAD plugins...then back out the channel strip out....

 

That means PDC still happening...

 

On top of that, you have output happening in two places...its happening once in I/O plugin...where its outputting nothing... And then again at the output of the channel strip, where its outputting something....

[drakepeterdrake]

I just checked it again, and it is in fact working with my setup. My idea of "working" may be different than yours, in that all I'm looking to do is eliminate PDC-induced predelay on the reverbs. The setup I have seems to be taking the reverbs "out of the equation" re PDC. I'm getting full stereo on the reverb outs back into the console. I can also load as many high-latency plugins into the BV bus and not have their latency introduce predelay in the reverbs. It may be that the I/O plugin, which is assigned to channel 19 of the 19-20 pair I use to send reverbs back to the console, is "hijacking" the signal before it gets to the output of the channel strip. Go figure...

 

One thing i did learn from all this, via your posts, was that even in low-latency mode, any plugins in busses introduce PDC-related anomalies - you have to remove them, not bypass them.

[Dewdman42]

I don't think its working the way you think it is..but hey if you're having fun, then enjoy

[drakepeterdrake]

I wouldn't call it "having fun..." I did try your proposed setup, as shown in the attached screenshot. It works like my setup, except for the fact that if LPX is put into low-latency mode, the plugin is disabled. That is not the case with my setup.

[Dewdman42]

as I said, I don't think the setup you are using is working as you expect. I'm sitting here trying it and its not working for me at all your way. Somehow you're hearing the sound, I hear you, maybe the UAD is doing some direct monitoring you're not taking into account in your explanation...

[drakepeterdrake]

It could be my terminology of "mixer" vs. "console, etc., but it is absolutely workin on, and this is the important part, my system. I have found that personal studio setups can be very idiosyncratic. I don't know about the UAD doing direct monitoring. I have a couple of native reverbs in the setup as well and they work properly. I made extra-sure that the latency-inducing bv bus had lots of latency, and made sure it was assigned and that signal was going through it and appearing in sync on the console, both in and out of LLM.

[Dewdman42]

As I said, you are using UAD and it may have some direct monitoring or routing happening that is bypassing LPX's mixer..in which case your situation is entirely unique to you so good luck. But the way you are describing I/O plugin usage, does not appear accurate to me. Certainly what you have shown does not make sense to me at all. but anyway as I said, if you're happy, then carry on

[drakepeterdrake]

I don't think it has anything to do with UAD, as the same problem and solution occurs with my native reverbs, assigned the same way. It may well have something to do with the fact that I am not monitoring this through Logic. Everything is brought up on my console so that may allowing me to bypass some layer of Logic's weirdness. I've made test mix recordings to make sure this is transferring, and it does. I also checked again that the BV bus was potentially introducing latency by playing LPX's internal acoustic piano sound, and it was hideously late unless I put LPX into LLM. I shall carry on...

[Dewdman42]

I discovered something else last night that is interesting related to the I/O plugin. It imposes its own reported latency. Bleh. The amount of latency it reports appears to be your audio buffer size times 2 plus 21. For example, if you have audio buffer set to 128, then it will add 128 *2 + 21 = 277 samples (~5ms) of latency as reported to the host...not sure its actually adding the delay, but its definitely reporting that and PDC will adjust accordingly if the channel in question is outputting to the output bus in LPX. I'm also not sure if that 21 number is specific to my audio card or my record delay setting (current -48).

 

 

You knew this couldn't be simple right?

 

If I/O plugin reports latency, then PDC in LPX will be effected, even if I/O plugin is not actually adding any latency. It looks to me like that reported latency is based on Round Trip Latency(RTL) based on current audio buffer size. I'm not sure what the extra 21 samples are for. That makes sense since the normal intended purpose for this plugin is to do an FX loop out to external outboard gear...and it believes the RTL will be present in that FX loop...and may need to be adjusted by the user to be even longer.

 

You can use the latency offset inside of I/O plugin to assign it a negative latency offset, to bring it back down to anything you want, zero is the lowest you can go. So in the above example you can set it to -277 samples and then the plugin will not be reporting any latency any more.

 

However, its not entirely clear to me what the reported latency should be...since its sending audio out to your audio device and there is SOME latency for that...but probably not the audio buffer 2x + 21, which is the RTL. Might be correct to subtract only 1x of the audio buffer size so that only reporting the outgoing latency. (shrug).. not really sure...but its worth noting this.

 

You can make the negative offset greater then the value required and it will be ok, it will never go below zero. But it does max out at 500 samples. So that means you can't get zero latency reported from this plugin once you are using audio buffer of 256 or greater. If you only try to half the latency reporting, then you can use a 256 audio buffer with correct latency reported, but at 512 it will start to be over reporting latency again.

 

I have come to the general conclusion that using the I/O plugin to workaround PDC is not the best way to go. I ran through a bunch of scenarios last night and there are better ways generally to deal with each scenario.

 

The one place where the I/O plugin might be useful is if you're trying to create a completely isolated channel that can be unaffected by PDC and also not effect others. For example the hardware console FX loop concept that DrakePeter suggested might be a place where you just want the isolated channel to have the lowest audible delay as possible, and the actual reported latency doesn't matter, because its just a live connection to the hardware console. The RTL and plugin latency will be whatever it is...and the reporting won't matter. In that case, the I/O plugin can be useful. The trick to that is that the channel in question must have the output of the channel set to "No Output". If the channel outputs to one of the output channels, then it will effect PDC, regardless of whether the I/O plugin is sending out its own audio to avoid itself being effected by PDC.

 

However I stress that using the I/O plugin on the rest of your project for the purposes of skirting around PDC is generally not a good idea. Besides the fact that its adding this incorrectly reported latency, they would all have to be removed from each channel during mix down for true proper synchronization.

Edited February 13, 2019 by Dewdman42

[Dewdman42]

I think I am going to write up a PDF, both for myself and to share, which lists off each typical recording scenario and how to best configure LPX for PDC issues, with some notes about bugs and oddities that have been reported by many. This is such a confusing matter and so many variations, but actually when you run through the scenarios, in each scenario there is usually one way that is clearly the best way to approach it. Maybe Apple will catch wind of this PDF eventually and consider improving some of the workflow related to PDC because it shouldn't need to be this complicated.

 

To simplify it down to simplest terms for now... what I can say is:

 

1. Whenever possible, avoid latent plugins while recording tracks. Use Low Latency mode or use alternative zero latency plugins during the recording process.
    
    
   
2. If you have the capability to use hardware direct monitoring, then by all means use it, this can eliminate audio buffer latency in addition to plugin latency. Turn off software monitoring button in LPX when doing this for correct record offset.
    
    
   
3. Whenever you are using an AUX channel pretty much anywhere in the project with latent plugins on it, then set PDC to AudioInstOnly while recording any tracks. Set PDC back to ALL when you're done recording tracks. The entire project will not sound perfectly in sync while in that mode, AUX channels with latency will be audibly delayed. But track recording will happen much more sensibly that way without the drifting overdub problems expressed by the OP. There are some cases where its possible to combine hardware monitoring with PDC=ALL and the project will generally sound more in sync while the recorded audio track will still be correct. But when in doubt, just set PDC to AudioInstOnly while recording tracks. The Exception is if the AUX channel in question is isolated from the rest of the project by specifically setting its output to "No Output", then it will not effect other tracks being recorded.
    
    
   
4. If you absolutely must include latent plugins in the signal path of a track you are recording, then realize you will hear audible delay while you're recording and there is nothing you can do about that. If the latent plugins are directly on the audio/inst track you are recording to, then even though you hear the sound monitored late, the record offset will be based on when you played it, not when you heard it late. However if you are using latent plugins in AUX channels, then the record offset will be delayed also to match what you hear. This is an inconsistency in LPX that probably Apple should address, but I suspect they won't. The best work around for this record offset problem when using AUX channels with latency is to use hardware monitoring of the source and turn off software monitoring in LPX, then the record offset will be correct. Another solution for latent AUX monitoring without effecting PDC and record offset is to use a reverse FX loop using I/O plugin in combination with hardware monitoring as suggested by DrakePeter.
    
    
   
5. There are also known reported bugs and problems with PDC related to automation and side-chaining. I have not even begun to investigate that, but you've been warned

 

I'll let you know if I get time to make the PDF I want to make. I need it for my own notes...so... there will be something...

[robinloops]

So a question for confirmation: When hardware monitoring (software monitoring off), leave PDC set to ALL, make sure there are no latency inducing plugins in the master, and Logic will compensate for the latency, right?

[Dewdman42]

Pdc pretty much always works but the record offset is inconsistent with software monitoring on. For inst and audio tracks with latent plugins on them it will register the record time at the time you play it even if you hear it lagged due to latency. But if you have latent plugins on an aux or master, then it will register the record time based on when you hear it lagged. Something like that. Actually inst tracks might be registering always lagged I can’t remeber now ( why I need to make pdf) If you turn off software monitoring on audio recording, then the record offset is always based on when you play it

 

Remember though that if you have latent fx and hardware monitoring you may hear some sonic anomalies in your monitor mix which may not be desirable because the fx are delayed beyond the source dry sound. In general if you track without latent plugins you’ll have a better experience. If you use hardware monitoring then you will have even less latency in your monitors while tracking. But if you want to use software fx while tracking there really isn’t much point in talking about hardware monitoring because the latency will cause those anomolies, even without latent plugins. So then all you can do is lower your audio buffer size and try to keep plugins to minimal latency so that you can play the part and it won’t feel too terrible.

 

If you set pdc to audioinstonly, then aux channels with latency won’t lag your inst tracks while trying to record but if you’re using latent aux fx then again the source will be some ms in front of the effected sound and may not sound great.

 

The best course of action is eliminate latent plugins while tracking, at least in the signal path of the track you are recording. And if you want to use hardware monitoring then don’t use any software fx on the tracks you are recording, even zero latency fx because they will still be substantially delayed compared to the direct hardware source. Enough to cause combing, doubling, phasing and even out right echo effects

 

If you take that philosophy then it simplifies your options, keeps everything simple and avoids a lot of pdc headaches

Edited February 13, 2019 by Dewdman42