2:43AM
Turning off 64-bit engine? Seems contradictory to the many posts that say to turn it on, or leave it on.
 
After all, it's probably a setting that doesn't even really matter.
 
I believe that for most situations, and possibly for 50% of the Sonar population, nVidia graphics cards are to blame for most, if not all, audio crackles and pops caused by latencies. It would be interesting to set up a poll (is that even possible?). I know that I am biased, and a little negative towards the topic, because I am one of the "50%" that's experiencing problems.

Cakewalk disagree with you, but what do they know?

There is an issue with X1c that can cause problems with 64bit DPE turned on (with the ProChannel Console Emulator).  Cake have said to turn it off, and they are working on addressing the issue..
 
I've turned it off and am finding X3c a blast.

JB is 100% right. 

I've broached this subject before and gotten a couple different answers that I think I understood but they were in relation to specific things. IIRC by engaging the 64 bit option Sonar processes everything internally at 64 bit float as opposed to 32 bit float (correct?) thus giving double the amount of accuracy when making calculations (correct?).
 
So I guess what I'd like to know is what exactly does this mean for my mixes and what it means for my computer resource consumption?
 
Does it make things sound better? Does it help FX do their jobs better? How much extra burden does it put on my computer? What computer components does it effect most (CPU, RAM, HDD, etc)?
 
Perhaps this should be a new thread but because of all the back and forth here on the subject it has me curious. Especially considering some of the weird issues I've had. I keep it enable because I've always been told that it's "better" and my system should be able to handle it but if I can make informed judgment calls on when to use it and when not to and what the benefits/disadvantages of both options are perhaps I can toss it onto my troubleshooting list.
 
Cheers.

Beepster
I've broached this subject before and gotten a couple different answers that I think I understood but they were in relation to specific things. IIRC by engaging the 64 bit option Sonar processes everything internally at 64 bit float as opposed to 32 bit float (correct?) thus giving double the amount of accuracy when making calculations (correct?).
 
So I guess what I'd like to know is what exactly does this mean for my mixes and what it means for my computer resource consumption?
 
Does it make things sound better? Does it help FX do their jobs better? How much extra burden does it put on my computer? What computer components does it effect most (CPU, RAM, HDD, etc)?
 
Perhaps this should be a new thread but because of all the back and forth here on the subject it has me curious. Especially considering some of the weird issues I've had. I keep it enable because I've always been told that it's "better" and my system should be able to handle it but if I can make informed judgment calls on when to use it and when not to and what the benefits/disadvantages of both options are perhaps I can toss it onto my troubleshooting list.
 
Cheers.

That's a question many of us would like to know.  The 64 bit DP engine was advertised for years as the reason why CW was ahead of Pro Tools and several other DAWs.  Yet, now CW tells us to disregard it until they get it fixed.  I've seen so many conflicting opinions on this over the last several days that I have no idea what to believe.  I'm still staying with X3b until the dust settles.

CW will tel you it make things sound better. I'm not so sure it makes much difference. I sure can't tell if its on or not by how it sounds. The thing is that plugins may process at 64 bits internally or 32 bits. Ozone is one that uses 64 bits. What happens when Sonar is processing at 64 bits and the plugins is processing at 32 bits. Sonar will need to drop the bit depth to accommodate the 32 bit processing plugin. This has nothing to do with its native bit depth BTW.
 
It just seems to me that until all plugins process at 64 bit and Sonar is not required to adjust its bit depth to match, the overall processing on a computer will be greater and thus use more CPU usage on a given task. Turning off 64 bit processing will stop the need for Sonar to constantly adjust bit depth and give one a smoother overall operation. 
 
Some say it really matters I'm not so sure that it does. 
 
 

@Lynn... Howdy. Hope you've been well (I haven't been perusing the songs forum much lately which will hopefully change soon). I've been watching posts on this release closely. The impression I'm getting is that disabling the 64 bit thingie is mostly to resolve the Console Emulator hum issue. If you don't use the CE it probably wouldn't even come into play but if you do it's definitely something to watch out for. I don't think it is affecting everyone (not sure about that but I think some people have tested it and weren't getting the problem). It does seem a wise move to perhaps at least have a rollback/restore point to X3b considering some of the reported issues with the C patch but again those problems only seem to be affecting certain people and from the fix list it did solve a bunch of other potential problems. Personally I'd look at it from this perspective...
 
Is X3c causing me a problem running with the 64 bit double precision engine enabled? If not no problem. If so am I willing to continue the project without it through to completion (at 32 bit float which from what I was told years ago is overkill as it is but I don't know because I'm n00b)? Seems like a bad idea to turn it on and off willy nilly throughout a project (but again I do not know). Am I willing to open old projects that had 64 bit enabled and switch them to 32 bit (again only if the problem is manifesting itself)?
 
Basically if I were neck deep in the X3 world already (which I currently am not) I'd look at whether the fixes in X3c are fixes I need (but from most reports it was solid) and whether the new issues with X3c are affecting me personally (list of fixes here... http://www.cakewalk.com/support/kb/reader.aspx/2007013331). If the C patch were affecting things negatively AND the 64 bit disable fix was the solution AND I wasn't willing to disable it for the entirety of my projects I would probably just stick with the B patch because at the pace the Bakers are going you know the D patch is likely gonna come pretty soon.
 
Sticky issue for sure but when it comes right down to it if B is working for you then I'd say let it work for you and wait for D. 
 
tl;dr... If it ain't broke don't fix it. ;-)
 

Beep you're putting too much importance on a feature that may not be all that important. 

John
CW will tel you it make things sound better. I'm not so sure it makes much difference. I sure can't tell if its on or not by how it sounds. The thing is that plugins may process at 64 bits internally or 32 bits. Ozone is one that uses 64 bits. What happens when Sonar is processing at 64 bits and the plugins is processing at 32 bits. Sonar will need to drop the bit depth to accommodate the 32 bit processing plugin. This has nothing to do with its native bit depth BTW.
 
It just seems to me that until all plugins process at 64 bit and Sonar is not required to adjust its bit depth to match, the overall processing on a computer will be greater and thus use more CPU usage on a given task. Turning off 64 bit processing will stop the need for Sonar to constantly adjust bit depth and give one a smoother overall operation. 
 
Some say it really matters I'm not so sure that it does. 
 
 

Interesting. Still don't really get it but if having it engaged has things flopping around to different bit depths... well IDK. Most things I use are 64 bit but because of not knowing exactly whether that setting actually affects synths/effects or is just processing the audio or herding smurfs in another dimension it's difficult to approach that setting with any kind of confidence. All I can assume is if I'm giving my processor/computer the ability to make more accurate calculations then it would mean less rounding which would mean more accurate audio results.
 
It all makes me wonder though... with tape the little bits of metal getting scattered around were more accurate than digital for a while because it didn't have the rounding limitations. At 64 or 32 or even 24 how much more accurate could tape possibly be? Even if the tape were like a foot thick or a MILE thick and totally saturated with metal filings? How much can our puny human ears actually hear of that? Apparently I've got hyper sensitive ears and I hear crap that seemingly no one else does (which is surprisingly because of the abuse I've put them through). Like I can definitely hear the CE's effect on even an individual track where other can hardly hear it on an entire mix. If even I can't hear it what's the point? I mean I haven't done a/b's but maybe I will.
 
I mean I can hear a difference between 16 bit and 24 bit. I can hear a difference between 48khz and 96khz. But 32 bit and 64 bit? IDK... I doubt it.
 
However even if I can't hear it what does it mean for a professional mastering session? What does it mean for the gradual degradation of sound quality as it goes through the process of being converted to mp3's or some hipster kid recording to a cassette so they can walk around with their vintage boombox? What does it mean for stamping it on vinyl? What does it mean for future generations a hundred years from now listening to it like we listen old Robert Johnson records and say "Damn, dog! That sounds like shyote!"
 
All things the Beepster thinks about... but it is quite possible I am completely insane.
 
lol
 
 
 

John
Beep you're putting too much importance on a feature that may not be all that important. 

 
Ha!!!
 
You'll love my follow up post then.
 
lolololol
 
;-p
 
Edit: ...and I don't really worry about it too much. I've always just left it turned on as recommended. I don't THINK it causes me any problems but I would like to understand it more. Seems pretty sciency and stuff though. Perhaps beyond what I can absorb. This seems more the realm of the bitflippers and DrewFx's of the world. Not lowly Beepses.

FWIW, normally there's no harm in leaving it enabled, other than perhaps a slight bit of resource overhead.  The big question is, and always has been, does it make any kind of audible difference whatsoever?    Good luck getting a definitive answer on that one.      Which is why I think John is essentially saying "don't worry about it" - that extra precision isn't going to be as audible as a 60Hz hum!
 
One thing to keep in mind with this preference is that it applies to real-time playback.   When you export audio you also have the option to enable or disable 64bit double precision, regardless of how the preference is set.   I personally believe that if it has any relevance at all it'll be here and not during playback, since exports are what the rest of the world will hear.  So if the project I'm exporting is something that I think might benefit from that extra precision in any fashion, right or wrong, then I'll enable it during export.   Why not?