I've been running into this problem a few times now. At some point some plugin gets added that introduced a lot of delay and it's hard to track down which one it was. Unfortunately AFAICT, SONAR doesn't give us a way to see PDC info per-plugin like other DAWs do (am I just missing something...?).
 
So I quickly banged together a VST3 plugin that will display the Plugin Delay Compensation that the host reports to the plugin. So the idea is that you insert this PDC Info plugin in-between your other plugins, and it displays the PDC value at that point in the signal chain.
 
So then if you insert 2 of these plugins, one before and one after some other plugin for which you want to see its PDC value, you can calculate that sandwiched plugin's PDC value by looking at the difference in two PDC values.
 
Usage:

1. Download the plugin from here.
2. Put the file where your 64-bit VST3 plugins are located.
3. Open SONAR (or initiate a plugin scan) and insert the plugin into your FX chain from: Insert Audio FX -> VST3 -> Tools ->PDC Info.
4. Press Play

 
Notes:

1. You need to Stop/Start the transport to show the correct PDC info in the PDC Info plugin UI.
2. You can insert multiple instances of the PDC Info plugin at different points in the signal chain.
3. You can easily drag existing instances of the plugin to different FX chain locations, or to different tracks etc. So you only need to insert two plugins, then just drag drop them around different plugins to see that plugin's PDC info (remember to Stop/Start the transport each time!).
4. There is a bug in SONAR where it doesn't tell the plugin the input latency, only the output latency. AFAICT, the VST3 spec requires the host to tell the plugin both input and output latency, but unfortunately it looks like SONAR isn't implementing this correctly. Because of the missing input PDC value, things will look a bit backwards. So a PDC Info plugin at the start of an FX chain will show a higher PDC value than the instance at the end of the FX chain. This "output" PDC value is the time remaining until you will actually hear the signal (including the output driver's delay).

 
 
 

Awesome! Thanks. There's a Sonar Resources and utilities sticky in the software forum: http://forum.cakewalk.com/Sonar-Resources-and-Utilities-m3392713.aspx that would give this the exposure it deserves.
 
Rocky

Very nice, thank you. I am on my cell now but definitely want to try this out.

Nice! It works great!
 
I was wondering why Sonar is not showing that information on its own.
 
That is a good way to explain why some plug-in is not "live capable". And for those who know that such effect exist, really see the difference (which can be rather small to hear).

Thanks, Steven. Downloaded, and will try it tonight.
All the best.

thanks for this!

Awesome Steven. Many thanks for filling a void once again. (You're the originator of the Sonar Aux track concept as far as I am concerned - glad you're still around though if you went to work for Cakewalk that'd be ok- bring Azslow with you)

Would be a good feature request for Sonar to do like in ProTools which I like a lot.
 
You can make a module visible in mixer console that shows the current applied pdc to each strip, as well as modify if you need to - really good thinking to make you feel in control. So you see both how much loaded plugins delay, and how much compensation is applied to that track, and give your own offset from that.
 
Then there is a system dialog that show how much delay is applied total.
 

 
This plugin combined with mixrecall can be very useful to insert little everywhere you want info.
Wasn't it Silktone that extended routing abilities with a plugin before Cakewalk made patchpoints - so I gather this is another one for Cakewalk to follow up on.
 
So thanks to Silktone for being the forerunner....

Just installed and tested this, very nice. I have been toying around "straddling" plugins (i.e. an insert before and after), just to look at numbers.
 
A couple quick questions/comments:

1. For a specific plugin being straddled, the PDC of that plugin would be the difference of the "Output" values, correct? Reason I ask this is the example below - better stated, the "output" number is the difference of the PDCInfo to what?
2. Realizing how different the guts' processing would affect the PDC, I am wondering if SONAR users could contribute to a listing of these "offenders."

Specific chain I am looking at:
   1. PDCInfo
   2. iZotope Nectar 2 Breath Control
   3. PDCInfo
   4. iZotope Nectar 2
   5. PDCInfo
 
Values with all 5 online -
   1. Output = 626.9ms
   3. Output = 2.7ms
   5. Output = 23.2ms
 
Now, I toggle off #2 in the SONAR Track FX bin (only Breath control), new values are -
   1. Output = 626.9ms (same)
   3. Output = 606.4ms (spiked dramatically, but still lower than #1?)
   5. Output = 626.9ms  (also spiked, now identical to #1?)
 
Basically, I am confused "why" and possibly not using this properly (nothing new there).
 
Quick Edit: I realized I had installed the new Saffire MixControl the other day, which defaulted to 512 sample buffer on me. I dropped it down to 96 and the above numbers are very similar (pretty much 2ms less across the board for both tests). Another interesting point is that PDC is identical for 32, 48, and 96 sample buffers, but spikes up .7ms at the 64 sample setting.... this may also have use to tweak buffer settings, since I found that odd, but consistent.

excellent stuff