FR:have the plugin display it's time delay for PDC...

[steve2KVR]

I know it's a stretch, but I would find it useful when trying to figure out "timing issues" that come up. I have to be very conscious of the PDC that the DAW may or may not be applying "correctly"...tia.../s~

[vectorwarrior]

Hmm, yeah, actually that would be quite useful. Reaper can show the PDC in the track manager view, so I often have to get out the calculator and subtract the before/after of bypassing the plugin in question to figure out the latency. This FR would remove the need to do that.

Space is limited in the plugins, I'd be happy for it to be in the 'settings' window, so it didn't eat up space on the main window.

[steve2KVR]

In logic when the mouse hovers over the "button" for a plugin, the PDC/delay that is present/reported is displayed in a popup as samples or ms. I am looking to verify that is what the plugin thinks as well. There are circumstances where I'm not sure the two are in agreement all the time.../s~

[DarkStar]

As far as I know, all the DAW host does is receive the latency value published by the plug-in and use that to calculate the required PDC (rounding up to the number of samples in an integral number of audio buffers in some DAWs). The DAW does not test the plug-in to ascertain the latency value.

So, all the plug-in can do is publish its latency to the host AND display it (on Settings). But it would be the same figure.

If the latency published by the plug-in does not result in the host doing the PDC correctly, then it is likely that the plug-in is publishing the wrong figure. Check out the "Panic" button at the top of each MeldaProduction plug-in - it can resend the latency.

[MeldaProduction]

I suppose we could add it to Settings indeed. Though for most people this will be irrelevant and reasonable hosts should compensate properly. Though I think Steve is unfortunately using Logic, which is, well, from Apple, so... Though I'm not sure how knowing the value would help.

[steve2KVR]

...mmmmmm well, over on the lpx forums there is near certainty the issue/s are all from 3rd party plugins, despite well documented/replicable configurations that demonstrate otherwise...( I hesitate to sigh )...sooooo, knowing the delay gives me the tool/s I need to compensate...hth.../s~

[vectorwarrior]

Votech, here's an example of where I recently needed to do this. I like the sound of the Waves L316 limiter with certain settings but I wanted to bring back the dynamics removed by the limiting process...

- so I used MUtility to send the pre-L316 signal to channels 3-4

- then have the L316 work it's magic on channels 1-2 (which adds latency as it's linear phase)

- then use an MPhatik after the L316, using the side chain from channel 3-4 to bring the signal's dynamics back.

Unfortunately PDC does not resolve this, so the MPhatik receives the sidechain signal a few thousand samples before the L316 arrives. So in the MUtility I use the sample delay to delay the pre-L316 side-chain signal so it arrives at MPhatik at the same time as the post-L316 signal.

I presume the above scenario would be the same if the L316 was replaced with a Melda plugin that has latency. The point being, if you're routing signals around the chain, PDC doesn't automatically compensate for latency in this way.

[steve2KVR]

...yaaaaaa, that's the ticket...@vectorwarrior...what he said!.../s~

[DarkStar]

... and if you put them on separate tracks, using Sends?

[steve2KVR]

...that will depend on the DAW reliably applying PDC on the send->bus->aux path....../s~