Host Latency, PDC, the lining up and offset of Peak Meter

[kylen]

Hi Blue Cat...I wanted to take a minute to start a post for you to consider - that is the pros and cons of latency and plugin delay compensation as it relates to the envelope output by Digital Peak Meter (DPM). Here are 3 scenerios I want to point out:

1. In Sonar4 I can get a really tight DPM envelope by setting Sonar to 1.5ms latency (using WDM drivers). The envelope conforms to the actual signal as closely as I can get it to anyway. Having no other plugins on the track assures the tightest DPM envelope also. I can add the plugins later and make use of the envelope at that time.

2. When I have a track with a couple of plugins there may be a slight amount of DPM offset depending on which plugins they are. In other words the DPM envelope will begin just a little earlier than the peak and fall just a little early also. I can control the fall time with the Decay slider on DPM if desired. This is similiar to a very small look-ahead time (I think) that certain plugins use.

3. If I have plugins on a track that cause the host (like Sonar) to perform plugin delay compensation (PDC) then first of all I have to usually increase Sonar latency a bit. Now the DPM envelope is offset by the amount of Sonar latency which includes both my Sonar latency adjustment I've made along with the delay the plugin introduces. In the event of convolution plugins of noise reduction plugins the delay can be pretty large. Now the offset of the DPM envelope is even more.

What I'm making are observations that can be used to my advantage - once I realized they exist. In other words it's not a bug for DPM to write the envelope offset because of some host latency. In fact scenario #3 above led me into some cool compression techniques that I'm currently working on in dealing with transients. Since I can use the DPM automation envelope on any parameter on a compressor I want I can give a control like the compressor 'Knee' look-ahead, the ability to see into the future, and make adjustments prior to certain hi-level transients coming in.

Anyway, in case someone else noticed this I wouldn't want anyone to think offsets are evil and should be corrected. Offsets have their use as long as you know when and where to expect them!

Any comments or corrections to the thoughts in this post would be most appreciated since I'm new to some of this stuff concerning automation and delay compensation.

Thanks!

[Blue Cat Audio]

I'm impressed by how far you've been with the Digital Peak Meter!

That makes me think about adding a delay option on the plug-in...

Just a question: do you have directX plug-ins that cause DElay compensation? Or is it just a VST adapter option? I have never heard about PDC with directX plug-ins...

Thanks for these ideas!

[kylen]

I'm impressed by how far you've been with the Digital Peak Meter!

That makes me think about adding a delay option on the plug-in...

Just a question: do you have directX plug-ins that cause DElay compensation? Or is it just a VST adapter option? I have never heard about PDC with directX plug-ins...

Thanks for these ideas!

Hi Blue Cat - Yes it is the DX versions that allow me to take advantage of the latency. As you know I was a little confused using the VST version so I'll check this out again. I can tell you I noticed this behaviour in v1.0 - that tells you something I think.