Dewdman42 Posted April 28, 2021 Share Posted April 28, 2021 So in light of the recent release 10.6.2 which alleged to fix the long standing PDC problems, but didn't.... I'd like to try to get to the bottom of this a little deeper...perhaps we can identify more exactly and accurately the problem so that hopefully Apple will take another crack at fixing it, and if nothing else maybe we can learn some work arounds or very specific workflows to avoid in LogicPro. Side-chain PDC problem First Let's tackle the so called "side chain PDC bug". Given the following scenario, PDC sync is not acheived. create track “audio 1” create track “audio 2” route track “audio 1” over “bus 1” to “aux 1” insert latency inducing plugin “Linear Phase EQ” into “aux 1” route “aux 1” over “bus 2” to “aux 2” route track “audio 2” over “bus 3” to “aux 3” insert plugin “Compressor” to “aux 3” change side chain of the compressor to “bus 2” put a identical drum-loop on both tracks The above essentially sets up the following two parallel signal chains...and PDC does not work right, they are out of sync. The above parallel signal chains WILL play in sync if the side-chain is removed.. So the first data point is: Point #1 - two parallel aux signal chains, will play in PDC sync, unless side-chain is used, then apparently the reported latency from the signal feeding into the side chain bus gets forgotten for some reason But interestingly this appears to be related to more complex AUX routing as much as anything, which may be the actual bug in some way.. PDC handles AUX channel latency by delaying all other channels, but I think perhaps Logic Pro can get confused if and when a side-chain is combined with AUX channels like above...or there could be other scenarios not having anything to do with Side-chain, where the various different AUX signal paths might confuse the PDC engine of LogicPro. For example, if we move the latent EQ plugin from the above scenario to the first audio track and basically skip routing through AUX1 for that, the problem goes away entirely..side-chain works perfectly..: This leads us to second important point: Point #2 - Side-chained scenarios with latency on the channel feeding the side chain, will play in PDC sync if the channel hosting that latent plugin is not an AUX. Another work-around I found was to use Expert Sleeper's Latency Fixer plugin on AUX-2 of this scenario, set to a value of 53ms like this: In this solution, LatencyFixer causes LogicPro to bring everything back in sync again. Its a partially working work-around. I say partially because while this trick does line up the resulting two signal paths, the actual side chain input will be wrong...it would be receiving the side chain data late...and pumping the compressor out of sync. Harder to hear, but that is what would be happening. (note, Latency Fixer does not itself impose any delay, it simply reports latency to LogicPro so that the PDC engine will cause a correction). What we learn from this workaround: Point #3 - Putting another plugin on AUX-2 later in that same chain, then brings signal-path-one back in sync with the AudioCH2 chain.. So.. my guess is that specifically when an AUX with latency is used to feed a side chain, then PDC doesn't do what its supposed to do on that particular AUX in terms of PDC. Logic somehow ignores the PDC correction. So I think this is related to side chaining, yes, but it's also related specifically to when AUX channels are used to host latent plugins, feeding into the side chain. The LatencyFixer work-around is really not acceptable since it would pump the compressor at the wrong timing, though this would at least avoid phasing problems between signal paths 1 and 2 of this scenario. The only work around solution for now would be to avoid putting the latent plugin on an AUX channel feeding into the side chain. Some of these observations might apply to the automation PDC issues as well..not sure yet, I need to dig deeper. I hope this thread may generate some useful discussion in order that we can get to the exact and accurate problem... hopefully Apple could address it. If not, at least we might be able to identify specific taboo work flows, along with work arounds. Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted April 28, 2021 Author Share Posted April 28, 2021 here is another work around solution for the above scenario that I just thought of..this does solve the issue completely...both the pumping in the side-chain and the mixing of the two signals back together will end up in sync again... Its more complicated and involves adding an extra AUX channel... The above works by aligning the audio manually on the second path...bringing it in sync with signal1 since the side chain is causing the PDC engine to ignore the EQ latency. This has to be done on a completely separate AUX channel other then the one the Compressor is on.. This was achieved by adding delay and also adding a delay-report with the LatencyFixer. Seems complicated I know, but it is a working solution in this case...seems to work and I think further substantiates the theory about LogicPro's PDC engine igorning the latency on an AUX channel when its being used to feed a sidechain Quote Link to comment Share on other sites More sharing options...
Eriksimon Posted April 28, 2021 Share Posted April 28, 2021 Impressive research. Thorough, concise, clear. Shall bookmark this for future reference (and questions about this). Thanks. Quote Link to comment Share on other sites More sharing options...
stormy Posted April 29, 2021 Share Posted April 29, 2021 Thanks a lot! I hope you submit your findings to Apple. I’m following this issue with great interest although I’m not sure if it has bit me yet. I don’t use side chain inputs but I have some complex routings, especially with the I/O plugin for my hardware chains. I need to come up with a plan to test for this. I usually will have I/O plugins on kick and snare, overheads and then it all goes into a track stack (which is a bus, of course) with another I/O for the drum bus processing. So there’s multiple ways for PDC to go wrong. Quote Link to comment Share on other sites More sharing options...
root_sashok Posted April 29, 2021 Share Posted April 29, 2021 Thank you for research, this must be submitted to Apple 100% Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted April 30, 2021 Author Share Posted April 30, 2021 anyone know what the broken automation PDC scenario is? So far Its working correctly in various things I have tried, but someone else said it still is broken? I need exact instructions to replicate automation PDC problem. Quote Link to comment Share on other sites More sharing options...
jnchristp Posted April 30, 2021 Share Posted April 30, 2021 As far as I'm concerned the new version fixed the automation-bug. I tried some automation on a track, simple volume-automation and plugin-parameter-automation. Bounced everything out. After that I inserted some big latency-plugins on that channel and bounced it again. It aligned with the first bounces. I also automated on an aux, same way. It worked. So, well done, Logic-Team. Or am I missing something? Quote Link to comment Share on other sites More sharing options...
cwnchkcn Posted April 30, 2021 Share Posted April 30, 2021 I've created an account only to ask this: what is the Sample Accurate Automation option (Preferences->Audio->General) set to? I wonder if that is different between people who have reported success with PDC versus those who have reported the opposite. Quote Link to comment Share on other sites More sharing options...
rfpm Posted April 30, 2021 Share Posted April 30, 2021 Users putting in more work researching this for free vs Apples well paid devs. Good job with this! Quote Link to comment Share on other sites More sharing options...
forestkelley Posted July 8, 2021 Share Posted July 8, 2021 I’m dealing with the automation latency bug. It doesn’t happen with a track’s volume, but does with a gain plugin (both stereo and dual mono). I’m using a lot of Izotope plugins including the Rx de-click which adds a lot of latency. The automation delay seems to correlate precisely with the latency duration (about 3 seconds). I am also using summing stacks for groups of tracks with plugins on both the individual tracks and the sum track. I’m not sure if that makes a difference with the issue (I may test tomorrow). Quote Link to comment Share on other sites More sharing options...
forestkelley Posted July 8, 2021 Share Posted July 8, 2021 I’m dealing with the automation latency bug. It doesn’t happen with a track’s volume, but does with a gain plugin (both stereo and dual mono). I’m using a lot of Izotope plugins including the Rx de-click which adds a lot of latency. The automation delay seems to correlate precisely with the latency duration (about 3 seconds). I am also using summing stacks for groups of tracks with plugins on both the individual tracks and the sum track. I’m not sure if that makes a difference with the issue (I may test tomorrow). Quote Link to comment Share on other sites More sharing options...
forestkelley Posted July 8, 2021 Share Posted July 8, 2021 I’ve done some testing and have arrived at some specifics. The synopsis is that parameter automation in Logic (such as automating the gain on a plugin) is off when another plugin that requires latency (such as iZotope’s de-click) is on that track. However, it is not off when that same latency plugin is on a summing track (i.e., if a track has gain automation on it, and its summing track has a latency plugin on it, the track’s automation will be accurate). An important caveat is that this doesn’t affect a track’s volume fader automation at all. Track volume automation is accurate and isn’t negatively affected in any case. For cases where there is latency in the program, when I bounce, the region designated to be bounced, the “cycle range,” is offset, moved forward in time (to the left, presumably by the latency duration). The bounce starts with silence for this area which is to the left of the cycle range (i.e., when Logic compensates for latency, it starts playing not at the cycle start but by x milliseconds prior, and this prior region is included in the bounce and is silent. However, the bounce is still the same duration as the cycle range. Therefore, the end of the cycle range is missing/cut off by the same latency duration. Gain automation seems to be accurate when there are no plugins that require latency on that specific track (though the bounce is still offset by the latency created by other tracks as described above), but as soon as a plugin using latency is added to the track (such as iZotope’s de-click), the automation is off, set right by the latency amount. Again, an important-seeming note: this issue doesn’t happen with regular track fader volume automation. Fader volume automation is accurate whether their is a latency plug-in on the track or not. However, if the de-click plugin is placed on the summing stack (instead of the specific track), the gain automation is accurate. Meaning, that Logic is probably handling latency properly when these plugins are on the summing track but not on an individual track. Interestingly, iZotope seems to be aware of this issue as this (https://support.izotope.com/hc/en-us/articles/360033886113-Latency-and-Delay-Compensation) page seems to suggest that some “hosts” may not be properly set up to handle their latency. Further, the issue seems to be squarely in Logic’s camp and not on the iZotope side since you can see the suggested latency offset for each of their plugins by opening the plug-in preferences. Of course, keeping all latency plug-ins on the summing track may work in some cases, but it isn’t a great solution for a number of reasons. I for one, need to use the de-click on my individual track so that these clicks won’t affect the compressors on that track. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.