I have couple projects that end up with an insane latency - something about 2-3 seconds between the time I press a key and you hear the sound. My interface has 9.3ms latency. There is something really wrong in Cakewalk's code, a similar project with same plugins in Studio One has 500ms latency, I do suspect it is something with Console 1 on every track which makes the PDC go crazy. Any way to diagnose this?
 
Erik.

If you toggle the Bypass FX button in the Mix Module (or use the shortcut "e"), you'll get what your actual hardware base latency is without the plugins enabled in the project.

Jon Sasor [Cakewalk]
If you toggle the Bypass FX button in the Mix Module (or use the shortcut "e"), you'll get what your actual hardware base latency is without the plugins enabled in the project.

Yes thanks - I know this one but is this something you might be able to have a look and optimize?

The actual latency you're going to experience is either inherent to the hardware latency, or whatever additional plugin latency is being introduced. Your audio device latency can be set from either the Driver Settings tab of the Preferences (using Windows audio drivers) or via the ASIO (driver configuration) Panel for your particular device. Plugins can then introduce more latency on top of that. If you're in a new project and you're experiencing latency, then it's a device configuration issue. ASIO will give you the lowest possible latency.

CadErik I do suspect it is something with Console 1 on every track which makes the PDC go crazy. Any way to diagnose this?

this seems to be the take-away here, maybe other console 1 users could chip in if bandlab won't address it?

I'm experiencing the same when recording comping mode, and a track has a lot of take lanes (+10). If I record in overwrite mode, everything is ok.

If there is no delay with FXes turned off, so the delay comes from plug-ins, that is normal. Each plug-in is free to declare any desired delay, f.e. Cakewalk LP plug-ins can add more then 0.5sec in LP mode. That is by the algorithm design, not related to the system performance.
 
All these delays are added when used with live input (or live tweaking parameters before the plug-in(s) in question). Turning off PDC tries to route live signal without these delays (which is only possible till plug-in is not used in the live chain).
 
Do not compare the result with Studio One or REAPER. They use "calculate in advance" logic when possible, so always like with "PDC" button engages but with proper result alignment. Effectively, in case the plug-in is not in the chain of signal you currently working with its delay is eliminated. Sonar/CbB up to now can not do this.

If you want to get into surgery, the very last Utility in this post ("PDC INFO (the delay that each plugin introduces)") will give you the ability to span plugins (one on each side), to see the delta across them. Internally to SONAR/CbB, this cannot be determined otherwise, but can show the delay happening through suspect plugins. It would be nice to have this embedded into CbB, so that a toggle could be used to disable "high latency" offenders, without disabling everything.

Unfortunately, Cakewalk does not offer a per-plugin delay compensation display. It would be a nice feature, I think. Some other DAWs do have this. That's mainly due to historical reasons going back to when certain DAW vendors once refused to provide automatic delay compensation in their entry-level products, requiring users to make manual adjustments. SONAR/Cakewalk users, because we've had PDC all along (since 2003, iirc), have never had to give it much thought.
 
Still, it would be nice to be able to quickly identify which plugins are causing the greatest latency. When tracking down the culprits, all you can do is delete them one by one. They have to be deleted, not just bypassed.
 
We can guess which ones are adding the greatest latency, based on how they work. They are the ones with large internal buffers, such as linear-phase EQs, convolution processors, reverbs and delays. But sometimes a plugin can have built-in latency that you wouldn't suspect.
 
Keep in mind that overall latency is determined by whichever plugin chain has the longest latency. Latency is not cumulative for parallel plugins, e.g. 40 EQs on 40 tracks will not have more latency than 1 EQ on 1 track. So having many plugins will not necessarily increase latency. You have to look at what hardware engineers refer to as "the gozintas", as in this goes-inta that, which goes-inta that. IOW, the serial chain of processors.

bitflipper
Unfortunately, Cakewalk does not offer a per-plugin delay compensation display. It would be a nice feature, I think. Some other DAWs do have this. That's mainly due to historical reasons going back to when certain DAW vendors once refused to provide automatic delay compensation in their entry-level products, requiring users to make manual adjustments. SONAR/Cakewalk users, because we've had PDC all along (since 2003, iirc), have never had to give it much thought.
 
Still, it would be nice to be able to quickly identify which plugins are causing the greatest latency. When tracking down the culprits, all you can do is delete them one by one. They have to be deleted, not just bypassed.
 
We can guess which ones are adding the greatest latency, based on how they work. They are the ones with large internal buffers, such as linear-phase EQs, convolution processors, reverbs and delays. But sometimes a plugin can have built-in latency that you wouldn't suspect.
 
Keep in mind that overall latency is determined by whichever plugin chain has the longest latency. Latency is not cumulative for parallel plugins, e.g. 40 EQs on 40 tracks will not have more latency than 1 EQ on 1 track. So having many plugins will not necessarily increase latency. You have to look at what hardware engineers refer to as "the gozintas", as in this goes-inta that, which goes-inta that. IOW, the serial chain of processors.

Thanks for the hint on deleting vs bypassing - I wasn't sure about it. However I am certain that there are no chains in the whole project with such an insane latency. In certain configurations, Sonar seems to cumulate some latency outside the bounds of the chains. I don't want to be devil's advocate but I suspect this is a known issue buried in legacy code and explains which is why there is no display of per track/plugin latency (and this gets worse when you use the loop mode). Something like this just prevents you from playing any live VST, I haven't been able to figure out how this never made a top priority, because once you have the taste of other DAWs that have this implemented perfectly, you just can't go back to Cakewalk, no matter of the price+other features...