Latency During Fader Rides

I'm at the end of a big project that has a lot of tracks and is using considerable cpu. I go to do the vocal rides and all my moves are off. I'm using the regular volume control automation and not a gain plugin for this. The latency is making fader rides pointless. Are there fader riding settings that can be adjusted? I'm using the Touch setting on the vocal bus and controlling it with a behringer x-touch. Let me know if there's user error on my part. I'm not sure why my edits don't line up with the audio unless it's a latency issue. How do other people troubleshoot this? Thanks.

Choose Logic Pro X > Preferences > Audio :: General and make sure you have Sample Accurate Automation set to Volume, Pan, Sends, Plug-In Parameters. Also check that Plug-In Latency Compensation is set to All.

Thanks David, I just double checked and I already have the preferences set the way you described. Is it correct to attribute the issue I'm describing to latency? I'm doing my fader moves based on what I'm hearing and by watching the playhead. I'm way off using this method. I've also noticed that when I move the physical fader that the volume adjusted in the automation is slightly ahead of the playhead by a few beats. This seems odd.. I would have assumed that the volume adjustment would happen exactly at the playhead.

 

Let me know if I'm doing it wrong or if I just have too many plugins engaged to have accurate fader rides

 

Thanks for the help!

David, I just tested my fader rides on a session that isn't using a lot of cpu. I think how far I zoom in while riding the fader was throwing me off in the other session. I've always drawn detailed automation moves but I'm trying my hand at real-time rides with this new x-touch one I have.

 

I'm still struggling with my fader moves causing the automation to change a few beats ahead of the playhead. This seems a little unintuitive.. I'd like the part of the track I'm listening to (at the playhead) to go up/down in volume. Instead it seems I have to make the moves a couple beats in advance which is causing me to use my eyes to watch the waveforms more than use my ears.

 

Any tips or suggestions?

If you draw in automation with the mouse pointer, and make it obvious (like from no volume to full volume instantaneously), are the results accurate?

David you are spot on! When I use my touch pad on a track with Touch mode engaged I can automate the track in realtime right at the playhead. When I switch over to using the behringer x-touch controller I can visibly see all the changes happening in advance of the playhead!! It's crazy, the issue is quite apparent.

 

I'm comfortable using the trackpad to do fader rides but what did I buy this external controller for LOL! Ha, at least the transport functions are helpful. Is this user error on my part or is there a way to better utilize the fader on the x-touch?

 

Thanks for your insight!

David, hey I just wanted to check back in. Is this a known issue with some external controllers and is there a way to fix it?

Maybe this would be a better question for me to ask Behringer.. I assume that other controllers don't have this issue.

The X-Touch is on my wish list. Um... after reading you post I'm not sure anymore.

Any news from Behringer?

Sorry for my slow reply. I haven't figured out a work around on my end. I'm using the touch pad for fader rides and the x-touch is mainly for the transport controls at this point. I'll let you know what I hear back from Behringer.

Thanks for the follow up!

Have you tried using the xtouch on a different USB port? Is it on a hub? When you go into midi studio (Mac utility) and test the device, does there seem to be latency when you perform the test? What I mean is, does the little green arrow that shows it is receiving information from the controller, immediately light up when pressing something on the controller or does it seem laggy? You could also check in garage band and see if it has lag there. It might help to know if it’s an issue with the controller and system in general or just controller plus logic.

Did you ever find a solution? Besides ditching the controller? I'm in the same boat here. So far the mouse is the way to go in terms of accurate touch or latch automation at the end of a mix.

I think I'm having the exact opposite problem that you're having. Instead of my automation moves showing up early, mine are showing up about 0.5sec late. I'm moving my fader with the points in the song that I want to automate, and the automation curve shows up exactly 0.5sec late every time. I've done this several time to verify.

 

I'm using the Faderport 2.0 for volume automation in real time, and this is a huge problem for me, as I justified buying the faderport solely for the time it should save me with automation. All of the above mentioned preferences are as they should be.

 

If anyone has any help with this, I'd really appreciate it.

So if the automation is recording consistently 5 ms late, you can still record it. Then select all and move five ms forward. Problem solved. It’s a hassle but maybe less hassle than using a mouse. Worth a try anyway. But, unless you’re doing techno where automation is everything, does five ms really matter?

Wondering if anyone has found any solutions here?

 

Some context for the thread: settings all setup as per above (sample accurate w/ delay compensation set to all). I have a Presonus Faderport (same DThunder), bought it solely so I could do volume rides by hand rather than mouse (just feels more natural) - but when I write automation to Logic its delayed by a considerable amount - i.e. if I wiggle the fader on all the downbeats, the actual automation is written halfway between beats 1 and 2 of the bar.

 

@robinloops - yep one could definitely manually move the automation back as the delay is consistent; but as I bought the Faderport as an ergonomic / velocity improvement it kinda defeats the purpose.

when I write automation to Logic its delayed by a considerable amount - i.e. if I wiggle the fader on all the downbeats, the actual automation is written halfway between beats 1 and 2 of the bar.

Let's do a test. Start a new empty project, create one single track with no patch, no plug-ins whatsoever in your mixer, and try to write some automation, see if that is in time?

PS: David - just wanted to say I haven't forgotten this. Been absolutely slammed with work. Will report back once it's done.

PS: David - just wanted to say I haven't forgotten this. Been absolutely slammed with work. Will report back once it's done.

Thank you! Sounds good, no worries, just let us know when you have the time to get to it.

Hey all -

 

Apologies this took a minute to get back to.

 

So, after some investigation, here's what I've found:

- With a fresh project (i.e. vanilla new project, no plugins etc), the Faderport midi controller will indeed get automation signal recorded in time.

- However, once this track is routed through a bus that has a few plugins with latency on it, then your automation will be considerably out of sync.

- Disabling the plugins will not sidestep the delay they need to be deleted entirely.

- Low-latency mode will not sidestep the latency either.

- Different plugin setups will result in different amounts of delay in recording automation signals (i.e. so you can't do a one-and-done solution where you always shift the fader port automation by X samples).

 

And an observation: I have two other midi controllers that don't have this problem (i.e. M-Audio Keystation, Arturia MiniLab) and will modify the volume automation in sync with the project.

 

I am officially stumped.

On 10/14/2021 at 5:41 PM, robinloops said:

So if the automation is recording consistently 5 ms late, you can still record it. Then select all and move five ms forward. Problem solved. It’s a hassle but maybe less hassle than using a mouse. Worth a try anyway. But, unless you’re doing techno where automation is everything, does five ms really matter?

I'm experiencing the same issue with a faderport 2.0. Lookahead on tracks that sent to busses with considerable plugin latency.

The problem with recording automation and then moving it is that rides specifically meant to be instant feedback, adjusting to what you hear in real time. If your volume isn't current, your automation moves cannot be accurate. You'll always be chasing your tail, as it were.

Would love to know if anyone found a workaround for this.

I had this problem too. When I moved the fader on my X-Touch One, the automation would appear AFTER the playhead! I tried a bunch of stuff like changing settings and resetting everything. Like the previous poster said, the problem has to do with either too many plug ins, too many busses with plug ins on them, and/or certain plug ins. 

I've noticed that by removing one plug in (and yes, it needs to be removed, not disabled/bypassed), I can get normal results IF I have Low Latency on.

When I was testing this, Logic Remote on my iPad worked fine. 

When I was testing this in a different session, simply removing Waves DeBreath fixed the issue entirely. But the problem persists in sessions that don't use that plug in.

It's strange that there is so little information about this.

I don't have anything more conclusive but I did have some success by splitting my plug ins up onto serial aux tracks. Rather than having six plug ins on my sub master track (which goes to my main output), I create another aux track and call it pre master. I send my Sub's out  put to that and insert some of the plug ins that were causing this weird delay.

This way, I didn't actually sacrifice any plug ins. I just have to use LLM.

This was incredibly frustrating and I almost trashed my preferences and got a new OS, etc because of other suggestions. I also almost gave up on using my X-Touch. 

This isn't a perfect solution but it's definitely more helpful than anything I could find. So with that, I hope this finds its way to someone else who was going crazy with this bizarre issue.

 

 

On 1/23/2024 at 11:40 AM, David Ricard said:

I had this problem too. When I moved the fader on my X-Touch One, the automation would appear AFTER the playhead! I tried a bunch of stuff like changing settings and resetting everything. Like the previous poster said, the problem has to do with either too many plug ins, too many busses with plug ins on them, and/or certain plug ins. 

I've noticed that by removing one plug in (and yes, it needs to be removed, not disabled/bypassed), I can get normal results IF I have Low Latency on.

When I was testing this, Logic Remote on my iPad worked fine. 

When I was testing this in a different session, simply removing Waves DeBreath fixed the issue entirely. But the problem persists in sessions that don't use that plug in.

It's strange that there is so little information about this.

I don't have anything more conclusive but I did have some success by splitting my plug ins up onto serial aux tracks. Rather than having six plug ins on my sub master track (which goes to my main output), I create another aux track and call it pre master. I send my Sub's out  put to that and insert some of the plug ins that were causing this weird delay.

This way, I didn't actually sacrifice any plug ins. I just have to use LLM.

This was incredibly frustrating and I almost trashed my preferences and got a new OS, etc because of other suggestions. I also almost gave up on using my X-Touch. 

This isn't a perfect solution but it's definitely more helpful than anything I could find. So with that, I hope this finds its way to someone else who was going crazy with this bizarre issue.

 

 

Sounds to me it might be related to a latency thing as I'm fairly sure DeBreath requires a bit of "lookahead"

You could test this by offsetting the automation by the same amount of latency that Logic is reporting for the plugin.

Hey Simon,

Yes, it's definitely a latency issue but it's still tricky to find the source. On one song it was DeBreath but on another, it couldn't be fixed no matter which plug ins were removed. 

But your suggestion of offsetting the latency is a great work around.