Avid Pro Audio Community

Avid Pro Audio Community

How to Join & Post  •  Community Terms of Use  •  Help Us Help You

Knowledge Base Search  •  Community Search  •  Learn & Support


Avid Home Page

Go Back   Avid Pro Audio Community > Pro Tools Software > Pro Tools 2020

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 06-26-2020, 10:21 AM
RTGraham RTGraham is offline
Member
 
Join Date: Dec 2017
Location: New York
Posts: 29
Default Timing Problems in Plugins that Synchronize to Measure Boundaries

I'm editing this first post in this thread, to more concisely describe the issue. The original post will follow below this new edit.

PROBLEM:
Audio plugins that provide tempo-synced processing, and also require synchronization to measure boundaries, exhibit timing problems when a delay-compensated plugin is present before them in the signal path.

EXAMPLES:
Pro Tools comes bundled with the A.I.R. Creative Collection. Within that collection are the Filter Gate plugin, which "slices" or gates the audio (while also offering the option to filter it) on a rhythmic basis, with a variety of parameters for controlling that behavior. When operating properly, it can provide rhythmic effects that stay in time with the music - i.e. "on the grid"; and also the Pumper plugin, which mimics the effect of a typical EDM sidechain operation whereby the kick ducks the other instruments - which also, when operating properly, provides a rhythmic effect whose relationship to "the grid" is predictable.
Third-party plugins like xfer's LFOTool and SoundToys' Tremolator similarly depend on knowing where the downbeat occurs.

VERY QUICK SERIES OF STEPS TO DEMONSTRATE THE PROBLEM:
(1) Create a new session.
(2) Create two mono audio tracks. Name the first one "CLICK" and the second one "Signal Pulse."
(3) Insert the Click II plugin on the CLICK track. The default settings are fine, and most likely will be Click 1 at a quarter note with the "Classic Click Acc" sound and Click 2 also at a quarter note with the "Classic Click" sound, with "Follow Meter" enabled. Make sure the click is enabled in the session settings.
(4) Insert a Signal Generator plugin on the THIRD insert (Insert C) of the Signal Pulse track. Its settings can really be anything, but it makes it easy to hear what's going on if you set it to a square wave, 120 Hz, -15.0 dB.
(5) Insert a Filter Gate plugin on the FIFTH insert (Insert E) of the Signal Pulse track. Set Pattern to Straight, Attack to 0%, Hold to 15%, Release to 5%, Filter Mode to Off, Rate to 1/4 note, Swing to 50%, and Mix to 100%. Leave Env and LFO both at 0%.
You will now hear the square wave pulsing like a click, even though the transport is not running.
(6) Engage the transport (press play). The Filter Gate plugin will "jump" to match the timing of the engaged transport, and you will hear the click and the square wave pulse in perfect synchronization.
(7) Stop the transport and insert a Maxim plugin in the FOURTH insert (Insert D) of the Signal Pulse track. Set its Mix to 0% (fully dry). We are forcing delay compensation because Maxim is a plugin that induces latency.
(8) Start playback again. You will hear that the click and the square pulse are no longer perfectly synchronized. They should be, however, as the Filter Gate plugin is designed to know where in the measure it is. This is the problematic behavior.
(9) Insert another Maxim plugin in the FIRST insert (Insert A) of the Signal Pulse track, also with its Mix set to 0%. You can leave the transport running while you do this, or stop and restart it. The problem will become more pronounced now that there is longer delay compensation.

THINGS THAT DO NOT FIX THIS:
• Buffer size
• Any of the "Delay Compensation for External Devices" options in Preferences
• Routing the track to an Aux before it reaches a hardware output
• Using, or not using, Low Latency Monitoring
• Using, or not using, a Master Fader

The one thing that DOES fix this is turning off Delay Compensation.
But in a mix session, that completely throws off the music's timing and synchronization and precision, and introduces phase issues.

Is this a Delay Compensation bug? Or is this a flaw in the way Pro Tools reports its timecode to timing-dependent plugins when delay compensation is present in a session?

=====
ORIGINAL POST
=====

(Was previously "Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat")

Hi DUC -

I'm experiencing several timing issues in Pro Tools when using plugins in certain ways. These issues have persisted through several versions (going back at least as far as PT 12), and as you'll see in the list below, they affect not only VI's but also regular audio plugins - and while I'm going to list multiple issues, it seems like they might be interrelated.

I've always figured that these problems are simply limitations or bugs in PT's implementation, as I've already taken several steps to try to troubleshoot them (also listed below), but since I really don't see anyone else complaining about these problems maybe there's something that I'm doing incorrectly that I just haven't pinned down yet.

And - please pardon the length of this post but I want to include as much detail initially as I can and in my mind these are potentially related issues.

1) Audio Plugins don't know where a measure's downbeat is.
There are many plugins available on the market, for quite some time now, that perform tempo-sync'd operations like rhythmic tremolo, audio slicing, rhythmic gating, side chain emulation, etc.
For these to correctly affect the audio that they're processing, they need to know where a measure's downbeat is, otherwise their effects in relation to the song's timing are unpredictable.
I've had MANY instances where I've tried to use something like xfer's LFOTool to emulate sidechain behavior but with more features and more control, and how it's going to speak is completely unpredictable. It doesn't line up with the downbeat, and the degree to which I have to compensate its "phase" seems to vary, possibly dependent (once again) on how much bus routing is present in the session.
I had a mix session for a major commercial release, where I was using two LFOTools to separately process different frequency ranges, and we had to do a recall to make a minor adjustment.
The new mix reprint had major phase issues resulting in a disappearing low end, because even though all we did was reopen the session and make clip edits, the LFOTool instances had shifted their timing, and we had to do our best to manually compensate by ear once again.
This is not unique to LFOTool - I'm just using that as an example, but things like SoundToys Tremolator will exhibit similar behavior.
And as with some of the other scenarios I'm describing here, an offline print does *not* match the realtime playback, but is also not completely correct - but by a different, unpredictable amount. So prints *have* to be done in realtime by busing.
Shouldn't PT be telling tempo-sync'd plugins where the downbeat is?

2) Virtual Instruments don't know where a measure's downbeat is.
If I instantiate a virtual instrument that can do certain things based on knowing where a measure's downbeat is - let's say a synth with a built-in arpeggiator - the resulting output's timing is correct as long as I'm not using any downbeat-dependent features (like said arpeggiator). The MIDI playback is generally correct.
But if I engage something downbeat-dependent like an arpeggiator, the timing skews. Usually it will mean that playback is late. The incorrect timing does not seem to affect what the plugin thinks the incoming MIDI's timing is - that is to say, the entire arpeggiated output is correct within itself, but all late.
The degree to which the timing is wrong seems to vary depending on how much bus routing is present in the session, but is generally unpredictable and does not seem to be related to buffer size, and if it's related to delay compensation sample counts I haven't been able to figure out what the multiplier is.
In these instances, committing the audio generally *does* result in equally delayed audio; the commit process does not magically remove the delay (as it does in some of the other scenarios that I'm listing here).

3) Audio Plugins that accept MIDI input cause incorrect audio timing.
For example: Antares Harmony Engine, Auto-Tune set to accept MIDI as its tuning trigger, or Stutter Edit (first version) set to accept MIDI as its effect trigger.
This is not quite the same issue as the first two, but seems like it might be somehow related.
If I put Harmony Engine on a stereo Aux track and route audio to it via a bus, then direct a MIDI track's output to the Harmony Engine plugin, the audio passing through that Aux track will play *early* compared to where it otherwise would have occurred.
The amount by which the audio is early seems to be completely unpredictable and not related to buffer size.
I can compensate with delay or time adjustment plugins, BUT - if I commit the Aux track, *sometimes* the incorrect timing is printed and sometimes the timing is *correct* instead (meaning that the compensation is then wrong and unnecessary).
So this seems to be a realtime playback issue related to audio being routed through buses.
Shouldn't the delay compensation architecture be able to tell what the timing should be?

For all of these issues, I have already attempted the following troubleshooting steps:

• Changing buffer size
• Toggling (individually) the "MIDI Beat Clock," "MIDI Timecode," and "MIDI Notes and Controllers" checkboxes in the "Delay Compensation for External Devices" section of the "MIDI" tab of Preferences
• Recording MIDI into, or placing MIDI on, a virtual instrument's Instrument track instead of using a MIDI track to feed that Instrument track

So - what am I doing wrong? What am I missing here? Shouldn't the delay compensation architecture account for whatever a session's bus routing might do to plugin behavior, and still correctly inform a plugin of where it is in relation to the beginning of a measure?
Is this in fact just a bug? And are these scenarios all related?


I'm really hoping someone can shed some light on this, as it's all fairly inconvenient especially when working with colleagues on certain types of projects.

Last edited by RTGraham; 06-29-2020 at 09:18 AM. Reason: Typo fix
Reply With Quote
  #2  
Old 06-26-2020, 09:37 PM
RTGraham RTGraham is offline
Member
 
Join Date: Dec 2017
Location: New York
Posts: 29
Default Re: Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat

I've created a test session that illustrates at least some of this.
It can be downloaded here (it's a very small session):

https://www.dropbox.com/s/3iabnwvet5...ation.zip?dl=0

The first three tracks, currently inactive, are "drum generators" - each has a Signal Generator instantiated, with an A.I.R. Filter Gate set to create quarter notes (for kick), half notes (for snare), or sixteenth notes (for hit).
Since the A.I.R. Filter Gate apparently thinks it knows where the downbeat is - as evidenced by the fact that it re-triggers if you start the transport - it's a good example of what I'm trying to describe in the original post here.

The next three tracks are the committed audio from those first three tracks.
They're bussed to an Aux, with the "snare" also sending to a reverb.
Both the drum submix Aux and the reverb Aux have Maxim instantiated on them, but with the "Mix" set fully dry, just to force delay compensation since Maxim induces substantial latency.

Everything is then routed to a "SubMaster" operating on Bus 1-2, with another A.I.R. Filter Gate instantiated on a Master track that affects that bus.

With the Maxim instances active, the Filter Gate's timing is skewed off the grid, which is easily audible and is also evident in the committed and realtime-recorded tracks at the bottom of the session.
With the Maxim instances completely inactive, the Filter Gate's timing is on the grid.

Adding extra latency-inducing plugins to the path (even just extra Maxim instances), to force additional delay compensation, changes how much the timing is skewed.

There really shouldn't be any reason why a tempo-based effect, which relies on knowing where the measure's downbeat is, shouldn't still know what the correct timing is supposed to be just because there is a latency-inducing plugin upstream.
Pro Tools should still be reporting the correct timing location to all plugins at all times.

Is there some setting or configuration detail that I need to be setting differently?
Or is this in fact a bug?
Reply With Quote
  #3  
Old 06-27-2020, 10:08 AM
RTGraham RTGraham is offline
Member
 
Join Date: Dec 2017
Location: New York
Posts: 29
Default Re: Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat

UPDATE: I've created a test session that illustrates at least some of this.
It can be downloaded here (it's a very small session):

https://www.dropbox.com/s/3iabnwvet5...gizk_2h94ZaR2E

The first three tracks, currently inactive, are "drum generators" - each has a Signal Generator instantiated, with an A.I.R. Filter Gate set to create quarter notes (for kick), half notes (for snare), or sixteenth notes (for hihat).
Since the A.I.R. Filter Gate apparently thinks it knows where the downbeat is - as evidenced by the fact that it re-triggers if you start the transport - it's a good example of what I'm trying to describe in the original post here.

The next three tracks are the committed audio from those first three tracks.
They're bussed to an Aux, with the "snare" also sending to a reverb.
Both the drum submix Aux and the reverb Aux have Maxim instantiated on them, but with the "Mix" set fully dry, just to force delay compensation since Maxim induces substantial latency.

Everything is then routed to a "SubMaster" operating on Bus 1-2, with another A.I.R. Filter Gate instantiated on a Master track that affects that bus.

With the Maxim instances active, the Filter Gate's timing is skewed off the grid, which is easily audible and is also evident in the committed and realtime-recorded tracks at the bottom of the session.
With the Maxim instances completely inactive, the Filter Gate's timing is on the grid.

Adding extra latency-inducing plugins to the path (even just extra Maxim instances), to force additional delay compensation, changes how much the timing is skewed.

There really shouldn't be any reason why a tempo-based effect, which relies on knowing where the measure's downbeat is, shouldn't still know what the correct timing is supposed to be just because there is a latency-inducing plugin upstream.
Pro Tools should still be reporting the correct timing location to all plugins at all times.

Is there some setting or configuration detail that I need to be setting differently?
Or is this in fact a bug?
Reply With Quote
  #4  
Old 06-27-2020, 10:13 AM
RTGraham RTGraham is offline
Member
 
Join Date: Dec 2017
Location: New York
Posts: 29
Default Re: Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat

Here are steps to follow to create a test session that demonstrates this.
(I had attempted to reply to this post with a Dropbox link to a ZIP of a session folder, along with a description of that test session, but after two attempts over a 24-hour period that reply still has not shown up, and may be waiting for moderator approval.)

So - the steps to follow:

1) Create a new session. For my test, I set the bit rate to 24 and the sample rate to 48k.

2) Create three new mono audio tracks. For my purposes, I named them “KickGen,” “SnareGen,” and “HatGen.”

3) Insert a Signal Generator plugin on the first track. Leave the waveform on Sine and set the frequency to 50Hz.

4) Insert a Signal Generator plugin on the second track. Set the waveform to Pink Noise.

5) Insert a Signal Generator plugin on the third track. Set the waveform to White Noise.

6) Insert an A.I.R. Filter Gate plugin on the first track. Set the Rate to 1/4 note. Leave the pattern set to Straight. Set Attack to 0%, Hold to 25%, and Release to 50%. Set the Filter Mode to LP, with a Cutoff of -5% and a Res of +5%.
This will cause only quarter-note pulses to come through, resembling a kick drum.
NOTE THAT while A.I.R. Filter Gate will perform this operation even when the transport is not running, the synchronization of the quarter notes will jump once the transport is engaged (in other words, when you press play).
This indicates that A.I.R. Filter Gate is designed to synchronize its timing to the downbeat of a measure, in order to be rhythmically accurate to a session’s grid.

7) Insert an A.I.R. Filter Gate plugin on the second track with the same Gate settings, but set the Rate to 1/2 note, the Filter Mode to BP, the Cutoff to -3%, and the Res to -85%. This will resemble a snare.

8) Insert an A.I.R. Filter Gate plugin on the second track with the same Gate settings, but set the Rate to 1/16 note, the Filter Mode to HP, the Cutoff to +50%, and the Res to -50%. This will resemble a hihat.

9) Start playback to force the filter gate plugins to all synchronize with each other, then stop playback again.

10) Highlight the first four measures of all three tracks, and Commit them. For my test session I chose to consolidate clips and make the source tracks inactive. My track volumes were all at 0.0 so the option to include volume and mute automation was irrelevant.

11) Delete the first and last measure of the resulting audio, as the filter gate plugin sometimes takes a moment to catch up with its own synchronization at the start of audio processing, even on a Commit operation. This will leave two measures of audio on all three tracks, starting at the beginning of Measure 2 and ending at the beginning of Measure 4.

12) Create a stereo Master Fader track. I named mine “SubMaster.” Set its routing to Bus 1-2.

13) Set all three printed audio tracks’ outputs to Bus 1-2.

14) Create a stereo Aux track. I named mine “SubMaster Monitor.” Set its input to Bus 1-2 and its output to your main monitoring hardware outputs. Solo-safe (command-click the Solo button) this track.

15) On the MASTER FADER track (not the Aux track), insert a new A.I.R Filter Gate plugin in the FIFTH insert (Insert E), so as to leave room for additional plugins before it. Leave the Pattern on Straight, set the Attack to 0%, the Hold to 50%, and the Release to 50%, and set the Rate to 1/4 note. Set the Filter Mode to Off.
Make sure looping playback is enabled.
Start the transport, or if the transport was already running, stop and restart it.
You should now hear a rhythmic pattern where the beginning of each quarter note is accurately a full transient. This is the correct behavior.

16) Insert a Maxim plugin on the first insert (Insert A) of the Master Fader track. Leave all settings at the default, but set the Mix to 0 (fully Dry). We are using Maxim simply to force delay compensation, since it is a plugin that induces substantial delay.
Start the transport. The filter gate’s affect on the audio will no longer be properly synchronized to the measure’s downbeat, and instead of hearing clean chopping you will instead hear something resembling flamming because the audio transients no longer line up with the timing of the filter gate’s envelope.
Note that the problematic behavior will still occur even if the plugins are inserted on the Aux track instead of on the Master Fader track.

17) Insert additional Maxim plugins in the other Master Fader inserts before the filter gate, to hear the problem become more evident.

18) If you would like to complicate the behavior, create another Aux track to use for reverb. Insert a Maxim plugin before an A.I.R. Reverb plugin, or else insert any reverb of your choice that requires delay compensation. Create a send from the “snare” audio track to the reverb aux, and set the send’s level to about -12.0dB.

19) If you would like to test how this prints or commits, you can create an audio track with its input also set to Bus 1-2, and record into it in real time. You can also Commit the “SubMaster Monitor” Aux track, and you can create another Master Fader controlling the hardware outs to test how a Bounce behaves.

I'm aware that the timing of A.I.R. Filter Gate has been discussed elsewhere in this forum, but what I'm demonstrating here is not limited to that plugin. I can create the same timing problem with, for example, Sound Toys' Tremolator or xfer's LFOTool. Pretty much anything tempo-sync'd that depends on knowing where in the measure it is. I'm just using the filter gate for demonstration purposes because it should be easily accessible to other users as well.
Reply With Quote
  #5  
Old 06-27-2020, 03:06 PM
chrismeraz chrismeraz is offline
Member
 
Join Date: Jun 2006
Posts: 354
Default Re: Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat

If you have LLM turned on, that will cause problems for the timing of any track that is rec-enabled and has plugins (such as a VI or any plugin at all).
__________________
Windows 10
Apollo 8
Pro Tools Native
i7 8700K, 32GB RAM
Reply With Quote
  #6  
Old 06-27-2020, 03:09 PM
JFreak's Avatar
JFreak JFreak is offline
Moderator
 
Join Date: Jan 2003
Location: Tampere, Finland
Posts: 20,196
Default Re: Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat

forget LLM, low buffer settings are low enough and less problems
__________________
Janne
What we do in life, echoes in eternity.
Reply With Quote
  #7  
Old 06-27-2020, 03:20 PM
albee1952 albee1952 is offline
Member
 
Join Date: May 2004
Location: Norwich, CT
Posts: 35,842
Default Re: Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat

Quote:
Originally Posted by JFreak View Post
forget LLM, low buffer settings are low enough and less problems
Amen to that^^^ I quit using LLM years ago and set the buffer to 64 for tracking.
__________________
Gigabyte X79/intel i7 3930K, 32GB RAM, DIGI003 Rack
https://www.facebook.com/search/top/...0sound%20works


The better I drink...the more I mix.....

BTW, my name is Dave, but most people call me.........................Dave
Reply With Quote
  #8  
Old 06-27-2020, 03:50 PM
RTGraham RTGraham is offline
Member
 
Join Date: Dec 2017
Location: New York
Posts: 29
Default Re: Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat

Quote:
Originally Posted by chrismeraz View Post
If you have LLM turned on, that will cause problems for the timing of any track that is rec-enabled and has plugins (such as a VI or any plugin at all).
Thanks for the suggestion. This is without LLM though (on my laptop I don't generally use an Avid interface, and our studio interfaces are not any of the ones that have that option, so I don't ever have LLM enabled), and is not a recording issue.
It's a playback issue, affecting the timing of audio that passes through plugins where those plugins depend on knowing where in the measure they are (i.e. where the downbeat is), and also affecting the timing of audio that passes through plugins that are receiving MIDI information from a MIDI track (but even if that MIDI track is not record-enabled).
Reply With Quote
  #9  
Old 06-27-2020, 04:27 PM
JFreak's Avatar
JFreak JFreak is offline
Moderator
 
Join Date: Jan 2003
Location: Tampere, Finland
Posts: 20,196
Default Re: Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat

Which plugins and if you move those to unused folder, is everything else okay?
__________________
Janne
What we do in life, echoes in eternity.
Reply With Quote
  #10  
Old 06-27-2020, 05:07 PM
RTGraham RTGraham is offline
Member
 
Join Date: Dec 2017
Location: New York
Posts: 29
Default Re: Can Anyone Verify / Advise? - Plugins / Delay Compensation / Timing / Downbeat

Quote:
Originally Posted by JFreak View Post
Which plugins and if you move those to unused folder, is everything else okay?
Plugins that I know for certain are affected are A.I.R. Filter Gate, SoundToys' Tremolator, and xfer's LFOTool. But I'm pretty sure I've seen it affect other plugins as well (like CableGuys' ShaperBox), and I suspect it affects anything that depends on accurately knowing the current timestamp (like any virtual synth with an arpeggiator).

The erroneous behavior has to do with an audio plugin, which modifies the audio in a way that is supposed to be rhythmic and not only synced to the session's tempo but also occurring "on grid" (like audio being sliced or rhythmically modulated) not knowing where the downbeat is - or in other words, not knowing where in the measure it is time-wise.
With no latency-inducing plugins in the session, the audio is processed correctly.
If there are latency-inducing plugins prior to the signal reaching the "problematic" plugins, thereby requiring delay compensation, then the rhythmic audio-processing plugins spit out their audio off-grid instead of on-grid.
Pro Tools should be informing the plugins of the current time accurately, but apparently it is not; it looks and sounds as if the program does not take delay compensation into account when it reports the current timestamp to a plugin.

If I move the "problem" plugins to the unused folder, then there's nothing to test, as the issue is very specifically with regard to the timing of audio that is being processed in a rhythmic way, and whether that properly lines up with the session's grid.

In the process of making the test session, whose steps I outlined in my own reply above, I was able to see how introducing delay compensation into the session "broke" the timing of A.I.R. Filter Gate, which is a bundled plugin as part of the Creative Collection that a Pro Tools installation includes.
So I'm perhaps a step closer to figuring this out - but I don't know why Pro Tools is incorrectly reporting the current timestamp to the plugins without accounting for delay compensation. I don't know if there's some sort of setting that can be changed to make it work correctly, or if it's just coded wrong in the program itself.

I've also tested this now, from scratch, on a separate studio machine with an Avid 192 interface, with the same results.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
MIDI timing / recording delays with Delay Compensation DAWgEAR Pro Tools 10 23 03-08-2020 06:12 AM
Delay Compensation screws up VI timing kirkbross Pro Tools 2019 13 07-16-2019 03:07 PM
Delay Compensation red with or without plugins donvision Pro Tools HDX & HD Native Systems (Win) 3 09-08-2013 08:34 PM
Delay Compensation Timing problems with RTAS plugs Kourquie Pro Tools TDM Systems (Mac) 2 07-22-2007 03:50 AM
delay compensation for rtas plugins...?? lukeyy Pro Tools TDM Systems (Mac) 0 11-14-2006 11:23 AM


All times are GMT -7. The time now is 04:49 AM.


Powered by: vBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Limited. Forum Hosted By: URLJet.com