Just to throw in my experiences with this. I have had this happen numerous times and I have always tracked it down to either the console emulator in the prochannel or another prochannel module. Usually, deleting and replacing it has fixed it for a time.
 
It just happened to me last week and I have everything updated.

I've had this happen, and I always blame it on my audio interface drivers. When it happens, I change the buffer size (to something bigger), reload the project, and it always goes away.

I've always assumed this was a symtom of a driver problem. Hmm...

double post

bitflipper
I never use the 64-bit option, either.

I'm surprised at the number of posts here and in various threads from Sonar users that have shut off the 64-bit option.
 
That can't be a good sign ...

Keith Albright [Cakewalk
Let me clear up some of the confusion...
Firstly it's a NaN issue. 
 

Couldn't it also be an Inf issue? SPAN shows -Inf for crest factor and peak (see here). I don't know what the "1.$" means for RMS and correlation.
 
This project only contains Sonitus plugins (plus SPAN). They are up-to-date AFAIK (e.g. Sonitus Reverb shows file version 3.13.5.32, product version 3.3.5.00, modified date 15 Feb 2016).
 
Is it possible to put a line of code before and after each plugin instance to check for good numbers going in and bad ones coming out? I'd be happy to install such a version to help track this down.
 
Cheers, Peter.

PeterMc

Keith Albright [Cakewalk
Let me clear up some of the confusion...
Firstly it's a NaN issue. 
 

Couldn't it also be an Inf issue? SPAN shows -Inf for crest factor and peak (see here). I don't know what the "1.$" means for RMS and correlation.
 
This project only contains Sonitus plugins (plus SPAN). They are up-to-date AFAIK (e.g. Sonitus Reverb shows file version 3.13.5.32, product version 3.3.5.00, modified date 15 Feb 2016).
 
Is it possible to put a line of code before and after each plugin instance to check for good numbers going in and bad ones coming out? I'd be happy to install such a version to help track this down.
 
Cheers, Peter.

 
This problem has been around for years and Cakewalk should be looking at this issue with a lot more concern then passing it off as a driver or a plugin or a denormal , because as a everyday user  i can tell you its definitely not getting better ! and although i wont say its getting worse it sure seems like it some days !
 
If anyone can try and track down this ! well hats of to them !

I have also had this issue a few times in the Past when working with different versions of Sonar - pre platinum. I don't think I have ever had it at all on this current computer/Platinum combo which I have been using since January. When it's happened I have assumed it was a glitch with the audio driver - but that was just an assumption. The thing is though, for me at least, it happened so rarely it would be near impossible to track down the cause.

Thank you for the NaN explanation. It does make me curious as to why these cannot be intercepted by the audio engine (even in a "troubleshoot" mode) so that a NaN is replaced with its last known good value and fed back into the calculation. I realize that this "gatekeeper" function would add CPU overhead, so would most likely be best limited to a troubleshooting mode (but would also negate the need to load projects in safe mode as well). If a plugin repeats itself, I would much prefer that the audio engine keep going and have SONAR pop up a message saying "So-and-so plugin has been removed from [whatever] FX chain because it is passing bogus audio information." Many users try/test plugins that end up being problematic and troubleshoot accordingly, but the audio engine is the ultimate authority of good/bad.
 
Every time I open S1Pro I see the message "RMixSONAR_64 ignored, because it has crashed before." This is the only one listed like this; apparently it is the only one that passed a VST scan but will not operate (it is actually bound to SONAR but S1Pro sees it as available, when it should not). Adobe Audition has always been quick to blacklist plugins that pass bogus data to the audio engine.
 
Having an "audio engine troubleshooting" feature to hunt/kill bogus plugins would save some folks (literally) hours of troubleshooting time, alleviate the need to use "safe mode" when opening a project, and also supply a definitive answer from the right source (the audio engine itself) instead of trial and error or tribal knowledge from the end user(s). Such a feature has been hinted at before, and it is definitely one end users would find immense value in.

mettelus
Thank you for the NaN explanation. It does make me curious as to why these cannot be intercepted by the audio engine (even in a "troubleshoot" mode) so that a NaN is replaced with its last known good value and fed back into the calculation. I realize that this "gatekeeper" function would add CPU overhead, so would most likely be best limited to a troubleshooting mode (but would also negate the need to load projects in safe mode as well). If a plugin repeats itself, I would much prefer that the audio engine keep going and have SONAR pop up a message saying "So-and-so plugin has been removed from [whatever] FX chain because it is passing bogus audio information." Many users try/test plugins that end up being problematic and troubleshoot accordingly, but the audio engine is the ultimate authority of good/bad.
 
Every time I open S1Pro I see the message "RMixSONAR_64 ignored, because it has crashed before." This is the only one listed like this; apparently it is the only one that passed a VST scan but will not operate (it is actually bound to SONAR but S1Pro sees it as available, when it should not). Adobe Audition has always been quick to blacklist plugins that pass bogus data to the audio engine.
 
Having an "audio engine troubleshooting" feature to hunt/kill bogus plugins would save some folks (literally) hours of troubleshooting time, alleviate the need to use "safe mode" when opening a project, and also supply a definitive answer from the right source (the audio engine itself) instead of trial and error or tribal knowledge from the end user(s). Such a feature has been hinted at before, and it is definitely one end users would find immense value in.

Really good suggestion and I believe this should be right up the top of the user based updates !

None of us have the same exact PC or in combination with the exact same audio interface , so it is not these causing this.
platinum audio engine is the front line and plugins is what are responsible so why wait ?
Why not make platinum solid with this NaN monitor idea from mettellus ! Or potential ideas that flow relating to mettellus suggestions !

Please Cakewalk listen to us !

Keith Albright [Cakewalk]
Let me clear up some of the confusion...
Firstly it's a NaN issue.  These are basically float representations of what can't be represented, in other words, not-a-number.  The thing about these is once you get one in a series of calculations, everything that comes after that is also a NaN.  So yes, if a plugin does the wrong thing on a math operation, everything after that will likely first pop and then go silent.  Things like square root of a negative number, 0/0, arcsin with values outside the range -1,1, etc.
 
Denormals are just really tiny numbers that are close to 0 but smaller than what a float can normally represent. Those do not cause a pop and do not cause silence.  instead, they can cause unusually high cpu as the microcode could be assisting.  Classic symptom was seeing high cpu with plugins when silence passed through them.
 
In terms of tracking NaNs down, yes you can bypass the fx bin on a bus or track and then further disable individual plugins to find the culprit.  We had some historically in our plugins that were subsequently fixed, so be sure you have the most recent versions of the in box plugins.
 
As far as SONAR by itself causing NaNs?  It's extremely unlikely.  
Nor would we leave such a thing in our engine unsolved for years.  We use SONAR as well.
Also, we regularly do checks for invalid float operations by unmasking exceptions and looking for issues.
 
If you are using non-commercial 3rd party plugins it's possible they aren't handling 64-bit very well.  
 
Keith
 
 

zeroFillDB=(Default:300)  determines the level of the fill data !
 
The above is all the information we have !
 
Can u provide more information on this please ?
 
Should this be increased on larger projects ? or when De-normalization occurs with suspect plugins ?