Waveform - All Things Latency (PDC) Related

Discussion about: tracktion.com
RELATED
PRODUCTS

Post

Greetings Fellow Tracktion / Waveformeers,

There's a lot of discussion on the topic of Waveform and it's various issues with PDC (Plugin Delay Compensation) on this forum. This is my attempt to bring forth the discoveries I've made along the way, and hopefully encourage a healthy conversation and exchange regarding our various experiences. Let's focus on bug observations, peculiar behaviors and above all, fixes and work arounds for these various issues. I hope this can be a useful thread for all of us, which includes offering helpful insights to our beloved Waveform dev team.

Cheers!

P


Here's a link to a recent post of mine in the thread - How To Apply Parallel Compression Mix Trick of Andrew Scheps called Rear Bus Technique. It's a ways down the page and offers an 8 track x 8 shared parallel buses matrix that is latency compensated.

* Disclaimer / Clarification: What I've created is a bus matrix that is latency compensated between the buses. IOW, the buses will route audio in parallel to the main W audio path with no delays or offsets between the bus tracks, although plugs added to these bus tracks will not be latency compensated, thus it only works in perfect sync when using zero latency plugs on the bus tracks. I was fooled into thinking that PDC was happening on these buses by inadvertently testing with only very low or zero latency plugs. Luckily there are many great plugs that happen to be zero latency, thus I'm still loving this tool!

viewtopic.php?f=22&t=504145&start=15

* I've added the 8 track x 8 shared parallel buses matrix files to this post.


PDC Issues in racks:

HansP's comments in the above thread led me to exploring the technique he describes of using parallel wired plugs in racks when there's a PDC issue present in the configuration. One of the pair of like plugs is set to no affect, which has it merely present in the circuit to resolve the PDC issue.

This method worked to resolve an issue with one of the built in rack settings - Guitar - Stutter Pitch. What's confusing is that this is a standard rack preset and it does not function properly if not tweaked with the HansP method just mentioned.

Here's the default preset:

Image

Here's the tweaked resolution:

Image


Before the tweak, the amount of delay is quit serious (many MSs). After the tweak PDC is perfectly achieved.

Now here's something that drove me crazy for quite a while, which is that there's also a second form of latency, which is much smaller, and it's introduced whenever you do any of the following to the Pitch Shifter plugs:

- Disable, then re-enable any of them.

- Make any changes to the pitch parameters in any of the instances.

The resolution for this form of latency is to go to the Settings tab, then the Audio Devices section and select any different Audio Buffer Size, then return it to what you started with, or not, in that the 1st change of this setting will correct the latency that was introduced by any of the above actions.

As for other plug latency issues in racks, I have no other examples to share at the moment.
You do not have the required permissions to view the files attached to this post.
Last edited by PierreG on Thu May 17, 2018 11:29 pm, edited 4 times in total.

Post

parallel wiring in the rack was clear from the beginning.
all parallel routes must have the same latency, therefor an example was provided that showed, that instead of a plain wire we must insert the same plugin once more, but with neutral parameter settings.

the other tactic was new to me, it means to reset all delay computations by changing the audio buffer settings.
very useful.

thanks for your in-depth contributions!

Post

Thanks for checking in HansP.

Not surprised that the parallel technique is ancient, in that I've pretty much avoided racks up till now out of frustration with these kinds of issues. My edits have been very simple acoustic recordings with little VST processing, thus the need was not there to inspire the deeper learnings. My recent super immersion has brought me somewhat coherent and confident in using racks, especially after finding the multi-bus solution I linked to.

I still find it strange that Waveform would be shipped with rack presets that are not correctly compensated via the parallel method. It's great to have this fix, yet what a waste of CPU to have to use extra plugs. I know that they're basically doing nothing but latency compensation, yet some still hog CPU cycles in this state. Also, new users who are not aware of this major quirk of T / W racks would be super confused like I was.

Glad my observations regarding audio engine settings working to correct certain latency issues is helpful.

:)

Post

HansP wrote:parallel wiring in the rack was clear from the beginning.
all parallel routes must have the same latency, therefor an example was provided that showed, that instead of a plain wire we must insert the same plugin once more, but with neutral parameter settings.

the other tactic was new to me, it means to reset all delay computations by changing the audio buffer settings.
very useful.

thanks for your in-depth contributions!
I don´t know, if this is still valid, as I can remember a test I did with either W8 or 9 on this topic and it compensated different parallel latency just fine...

I think it´s now related to a quite new bug in the racks:

Don´t know, when this happened but lately Racks can only compensate for one latency plugin in the Rack...
No matter if serial or parallel routing, if you got more than one plugin with latency in the chain the Rack compensates just for one... (I think it was the one with the higher latency ...made a bug report here)...

This problem was confirmed by Dave, but still no fix for that...

I admit to this whole thread, that PDC should be higher on the to-do list, than working on something like faceplates or if the clip data move down or not if you select the clip as PDC problems can ruin the workflow completely...

Don´t get me wrong... the additions in the updates are welcome, but if I would have the choice I would prefer working features over cosmetic ones...

Post

Trancit wrote: I don´t know, if this is still valid, as I can remember a test I did with either W8 or 9 on this topic and it compensated different parallel latency just fine...

I think it´s now related to a quite new bug in the racks:

Don´t know, when this happened but lately Racks can only compensate for one latency plugin in the Rack... No matter if serial or parallel routing, if you got more than one plugin with latency in the chain the Rack compensates just for one... (I think it was the one with the higher latency ...made a bug report here)...

This problem was confirmed by Dave, but still no fix for that...

I admit to this whole thread, that PDC should be higher on the to-do list, than working on something like faceplates or if the clip data move down or not if you select the clip as PDC problems can ruin the workflow completely...

Don´t get me wrong... the additions in the updates are welcome, but if I would have the choice I would prefer working features over cosmetic ones...
Trancit, thanks for adding to the growing chorus of PDC concerned Waveformites. I wholeheartedly concur with your priorities suggestion. Dave is fully aware of the PDC issues and has this on his radar at a deep level, yet as he' pointed out, fixing all of this will be a very deep dive into core level coding, which will not be quick, and will likely require a seriously intense amount of debugging.

This factor acknowledged, not resolving this ASAP is a sad and frustrating situation. It's incredibly limiting and workflow crushing to be spending so much time and energy on tweaking things in an attempt to work around these serious issues. As others have pointed out, and beyond the more known PDC limitations, several odd behaviors related to PDC will come and go, often requiring some sort of reboot of the edit, or changing an audio buffer setting that may well clear up the issue.

What's really stressful is knowing that these things can and will creep into your edit and very possibly go undetected for a while because the effect may be very subtle, especially when what's temporarily lost is PDC of a low latency plug. All of this can, and frequently does, lead to cognitive dissonance and mix fatigue.

As I've mentioned, I was inspired to finally have a multi-bus matrix that would be latency compensated, which I've partially achieved with the rack project I shared above (the files are now attached to that original post in this thread). If you're into watching and learning from the many Youtube mixing tutorials, you can't get around the fact that everyone uses latency compensated buses / plugs in all other DAWs (pretty sure this isn't hype). Most people seem to be using Logic or Pro Tools in these tutorials, which is in no way surprising, yet they typically say that you'll be able to do what they're showing you in any other DAW.

May this claim come to include Waveform ASAP!

Post

I'm working on T6, and even made it to a release :) :)
but I have a lot of hope that at least the racks in W9 will get to a best possible solution soon, as there were several attempts in fixing and improving already successful, and can hopefully be combined also.

in the meantime, for the doubled plugins, probably a tool plugin with low impact can be used, that can simulate any latency, entered in # samples. just one needs a correct latency report on the mix plugin in question. the solution would go into a user-made preset library, so it is a hassle only once. beware plugins that change latency, use a text plugin to document possible values, and to describe what to do about it.

Post

HansP wrote:I'm working on T6, and even made it to a release :) :)
but I have a lot of hope that at least the racks in W9 will get to a best possible solution soon, as there were several attempts in fixing and improving already successful, and can hopefully be combined also.

in the meantime, for the doubled plugins, probably a tool plugin with low impact can be used, that can simulate any latency, entered in # samples. just one needs a correct latency report on the mix plugin in question. the solution would go into a user-made preset library, so it is a hassle only once. beware plugins that change latency, use a text plugin to document possible values, and to describe what to do about it.
Trancit wrote: I don´t know, if this is still valid, as I can remember a test I did with either W8 or 9 on this topic and it compensated different parallel latency just fine...

I think it´s now related to a quite new bug in the racks:

Don´t know, when this happened but lately Racks can only compensate for one latency plugin in the Rack... No matter if serial or parallel routing, if you got more than one plugin with latency in the chain the Rack compensates just for one... (I think it was the one with the higher latency ...made a bug report here)...

This problem was confirmed by Dave, but still no fix for that...
HansP, is this compensation issue present in T6? I tried to find a simple latency delay plug for doing what you describe, yet I haven't found ones that can delay over 100 ms. The Waveform Pitch Shifter clocks in at 301 ms. If you find a good one, please share.

Trancit, it sounds like you had verified that earlier versions of Waveform did not have this issue. Be great to get clear on where / when this bug entered the stream and have it mitigated ASAP.

T Dev Dave, Please pardon any confusion we may be having over any of this. You've made it clear that you know about the latency issues, yet can't spend the time required to resolve them. If these issues are indeed long standing root level Waveform based, then I guess we're out of luck for any timely resolution, yet if there's a more recently introduced Waveform latency issue, can that be resolved any sooner?

* Note: The more I play with racks, the more I encounter latency de-syncing issues when making plug settings changes. The sure fire fail is to wrap one instance of the Pitch Shifter into a rack and make changes to the Pitch setting. For me, I always get a de-syncing that requires I tweak on the audio engine settings to resolve it. Could be resetting the device (only available on my ASIO device), changing sample rates, choosing a different audio buffer setting. Once you know this, it's easy to resolve, yet this is not proper behavior, and as I've mentioned, can really throw you when building racks.

Post

The guy who did the extensive review of Waveform at the AdmiralBumbleBee site did extensive testing of this issue and there was a great exchange between him and a Dave on it. The PDC issue exists in some form in other DAWs, but is particularly pernicious in Waveform because of its variability. Dave acknowledged the problem as noted earlier.

I realize this is a hard nut to crack, but it would be nice if TSC could let folks know if a fix is in the works for release soon, or whether or not this is something we just need to live with (and develop workarounds for) for awhile.
iMacPro 1,1 | 64gb | OSX 10.15.7
http://www.gesslr.com
http://www.storyaudio.com

Post

I would be already very happy, if the newer bug (that Racks compensate only one plugin in serial configuration and ignore everything else) would be fixed...

Everything parallel is a different story and perhaps more difficult to fix, but the first one is really a showstopper

Post

gesslr wrote:The guy who did the extensive review of Waveform at the AdmiralBumbleBee site did extensive testing of this issue and there was a great exchange between him and a Dave on it. The PDC issue exists in some form in other DAWs, but is particularly pernicious in Waveform because of its variability. Dave acknowledged the problem as noted earlier.

I realize this is a hard nut to crack, but it would be nice if TSC could let folks know if a fix is in the works for release soon, or whether or not this is something we just need to live with (and develop workarounds for) for awhile.
AdmiralBumbleBee = Robert Randolph. Once again, I thank him for the excellent work he did on his Waveform review, including his deep presence on this forum.
Trancit wrote:I would be already very happy, if the newer bug (that Racks compensate only one plugin in serial configuration and ignore everything else) would be fixed...

Everything parallel is a different story and perhaps more difficult to fix, but the first one is really a showstopper
I emphatically agree with y'all!

:help:

Post

@PierreG
Are you sure that the latency changes if you change any of the pitch settings?
This could just be an artefact of the settings you're using. Try enabling the "Syncronise Timestretch/Pitchshift" and see if these small delays go away.

Also, open the resource monitor, that will tell you the reported latency for plugin. Does this change as you make changes to the plugins?

Rather than resetting the audio device settings (which is probably just clearing and re-initialising the whole audio graph), does pressing the MIDI panic button also fix what you're seeing?

I am aware of a problem bypassing the Pitch Shift plugin, this doesn't add the latency reported by the plugin and is on the list of things to fix.

Post

dRowAudio wrote:@PierreG
Are you sure that the latency changes if you change any of the pitch settings?
This could just be an artefact of the settings you're using. Try enabling the "Syncronise Timestretch/Pitchshift" and see if these small delays go away.

Also, open the resource monitor, that will tell you the reported latency for plugin. Does this change as you make changes to the plugins?

Rather than resetting the audio device settings (which is probably just clearing and re-initialising the whole audio graph), does pressing the MIDI panic button also fix what you're seeing?

I am aware of a problem bypassing the Pitch Shift plugin, this doesn't add the latency reported by the plugin and is on the list of things to fix.
Thanks for the feedback Dave. Feeling silly for not enabling the Synchronize feature, which indeed helps a lot!

Before turning this on, what was happening was that playback of just one track would not reveal the fact that this audible track you just changed pitch parameters on was de-syncing with the other tracks. Un-muting another track exposed the de-syncing. This does indeed clear up with the panic button.

CPU Usage meter reported latency does not change during any of this.

After enabling Synchronize, making pitch setting changes tracks very nicely (does not de-sync with other tracks) until you reset it back to Original Pitch, which causes a de-sync, which the panic button resolves.

Update: The behavior I described above is not consistent. I just tried to re-replicate the de-sync and no matter what pitch setting I selected (including Original Pitch), it would not lose sync. I kept at it and eventually it faulted, so I'm not sure what's happening here. Curious if other users can replicate this behavior on their systems.

Post

Hey Dave, thanks again for the insight regarding the Pitch Shifter - Elastique Pro Synchronize Timestretch / Pitchshift setting tip.
Trancit wrote:I would be already very happy, if the newer bug (that Racks compensate only one plugin in serial configuration and ignore everything else) would be fixed...

Everything parallel is a different story and perhaps more difficult to fix, but the first one is really a showstopper
Please respond to the other more immediate issue raised here.

:pray:

Post

PierreG wrote:
Trancit wrote:I would be already very happy, if the newer bug (that Racks compensate only one plugin in serial configuration and ignore everything else) would be fixed...

Everything parallel is a different story and perhaps more difficult to fix, but the first one is really a showstopper
Please respond to the other more immediate issue raised here.

:pray:
Do you mean me or Dave??

If me: What do you mean???

Post

Trancit wrote:
PierreG wrote:
Trancit wrote:I would be already very happy, if the newer bug (that Racks compensate only one plugin in serial configuration and ignore everything else) would be fixed...

Everything parallel is a different story and perhaps more difficult to fix, but the first one is really a showstopper
Please respond to the other more immediate issue raised here.

:pray:
Do you mean me or Dave??

If me: What do you mean???
My apologies for the clear as mud post Dave (Trancit)! So many Dave's, so little alias name comprehension... :wink:

I thought my preamble Pitch Shifter enlightenment thank you post to dRowAudio Dave was an ample clue as to which Dave.

In short, it was most definitely meant for the honorable dRowAudio (Dave).

Post Reply

Return to “Tracktion”