Problems with LLM / Allow sends to persist during LLM

[XJENSEN]

Hi everyone,

I filed a case with Avid, but was wondering whether anyone here encountered a similar problem.

- I am currently setting up a monitor mix on the physical Cue output of an HD OMNI.
- I have an Audio track that has an AIR Reverb plugin in the first slot (for this test) and a Send towards this physical Cue output. The idea is to control the monitor level with this Send.
- The LLM path is assigned to this Cue output in I/O setup.
- The 'Allow sends to persist during LLM' is enabled.
- When I put the Audio track in Input Monitoring, the audio passes, with reverb on it, to the Cue output. This is correct.
- When I enable LLM, a double signal is passed to the Cue output, and strangely, the Reverb can still be heard as well. This is unexpected.
- The same happens if I assign the Output of the Audio track directly to the Cue output (instead of using the Send).
- When I drag the Send to another slot, the signal gets cut. Closing and reopening the Session fixes this.
- If I disable 'Allow sends to persist during LLM' everything works as expected, but then I can no longer use the Send to feed a monitoring Reverb on an Aux channel. When enabling LLM, the Reverb insert is no longer processed, and no sends persist, except for the Send that is feeding the physical Cue output!

So, I have no idea how it is possible that with 'Allow sends to persist during LLM' enabled, the plugins also seem to persist towards the LLM path! Any ideas?

Cheers,
Xavier

[XJENSEN]

I'm adding a screenshot of the Session in case anyone would like to verify.

[XJENSEN]

Appears this was already broken in 2018.7 (or earlier) and AVID is doing nothing about it: http://duc.avid.com/showthread.php?t=400587.

[albee1952]

For me, LLM has always had issues, going back to PT9. I simply don't use it and would bet you may not need to either. Any modern computer should be fine tracking at a buffer setting of 64(44.1 or 48K) or 128(88.2 or 96K). My PT/Native rig records 6-piece bands at 64 buffer while providing 6 stereo headphone mixes from within the session(with up to 48 live inputs).

[XJENSEN]

For clean tracking, you're right. But this is a rerecording/overdubbing session with loads of plugins and VIs where some physical instrument parts and vocals need to added. Needs a high H/W buffer size to keep the session running and LLM enabled to allow for the player/singer to be in time.

Anyway, most likely Avid's implementation of the 'Allow sends to persist during LLM' is faulty. The case has been escalated and is now under investigation.

[JFreak]

You can also simply bounce the stuff and have overdubs over a 2-track

[XJENSEN]

Sadly, that's exactly what I have to revert to right now..

Folder tracks, yeah nice, but what good is it with a DAW that can't even maintain proper sync between MIDI and audio?
This has been going on for ages and they just won't fix these fundamental issues?

[JFreak]

Originally Posted by XJENSEN

maintain proper sync between MIDI and audio?

Maybe because MIDI sample is 320 microseconds and audio sample (at 48kHz) is 21 microseconds? So whatever you do you have 16 audio samples where your midi note might "sync". Within that 16 sample window, MIDI is totally random.

[XJENSEN]

No, I expressed all delays in 'audio' samples (measured with selector tool)...

[origringo]

I had a ticket open with Avid, number 03765121, where they finally admitted that there was a problem with LLM and that it had been "escalated to level 3" and was being worked on by development to be fixed. It's not exactly what you are describing, but I'll bet it's close. I'll paste in my notes.

The bug I describe still persists.

Hope this helps you.

Jeff

- -

Description Noticed something while recording in Pro Tools low latency mode with and a plugin inserted on the track last night. I have delay compensation engaged, and when I put the track in record and engaged low latency monitoring (which bypasses all plugins and sends), Pro Tools started reporting 2048 sample delay was compensating for it on playback. Since the plugin has no latency delay it was pushing the recorded track ahead by that amount. Disabling the plugin corrected the issue, which is fine because I wasn’t really using it for anything but listening on playback, but it seems like a bug? I tried multiple zero latency plugins.

08/20/2019
Hi Jeff,

We finally traced that this "bug" started with PT 2018.7; so I'm about to escalate this case to Level 2, this will be discussed in our meeting tomorrow. After I get the go signal (from L2) to file and report this as a bug, then it will be escalated to L3 (Engineering). I can't really give you an exact timetable when this will be fixed, it can take several months for this fix to be incorporated in the next version release. Your patience is very much appreciated.

Meanwhile, you could keep on doing that workaround (right click- disable plug-in delay in the track) or you can install and use Pro Tools 2018.4 instead. You can keep both versions installed at the same time by renaming Pro Tools (as Pro tools 2019.6) in the Applications folder before installing PT 2018.4.

Pro Tools 2018.4 can be downloaded from the Avid Download Center.
Create a Download Center Account as indicate din this KB article: http://avid.force.com/pkb/articles/e...Center-Account


Best regards,
Paul
Avid Global Customer Care | Audio Post & Pro

10/8/2019
Hi Jeff,

To update you, this is still under Engineering investigation.
Might be included in 2019.R3 release which is before this year ends.
On my level, like what I stated in my previous email cannot give an exact date for that.
But this is issue is being prioritized and hope the fix to be included in the next release.

As of now and until the next PT update, there's really nothing more we can do.
Let me know if I can help you with other issues (in case you run into some new ones) and if we can close this case now.


Best regards,
Paul
Avid Global Customer Care | Audio Post & Pro

11/6/2019
Hi Jeff,

I was also hoping that the fix was included in this release. But at least we've already reported it and it's on L3 level already.
From what I heard, they prioritizing fixes for bugs that are most reported and has the most number of cases attached. I think these are the ones that were addressed in the 2019.10 update. As to the details like what in particular are they prioritizing, ETA, time table and all that, I'm sorry to inform you that I don't have access those things.

I'm afraid at this point there's really nothing else we can do. Will keep you posted for new updates.


Best regards,
Paul
Avid Global Customer Care | Audio Post & Pro