Lies, none of you handbag swinging ladies have any shlongs.

Pics or it didn't happen.

(2 much wine)

Lies.

well, according to the OPs article, this whole thread is filled with um! gonna get back to my templates... they're fun, Vab... make a few... you'll never go back...
I can load up 3 instances of Kontakt now, each fully configured for multiple instruments with 8 stereo/midi tracks... in 30 seconds.... so make some track templates... NOW!

Unlike the sample rate article, I think the link quoted below misses the point of higher bit depths a completely different topic. Bit depths have to do with dynamic range and noise floor and a floating point formats eliminate or greatly reduce errors introduced by multiple mixing stages and dsp processing unlike integer formats that cause truncation and data loss. That's pretty proven despite what the article claims. Even 24 bit audio as an integer format is widely known to be more forgiving while recording (dynamic) music. 
BTW I didn't post that article because I agreed with everything in it. It however covered a lot of good info about sample rate theory. I particularly found the section interesting on how high sample rates can mask errors in converter design and therefore sound better. That's probably a large reason why *some* interfaces sound better at high sample rates. And also why a well designed interface with high quality converters can sound as good or better even at 44.1.
 

Goddard
Sigh... wotta buncha hooey. Facetious scientist indeed.
 
Surprise! ADCs actually sample at frequencies in the MHz even if they only output PCM streams at 44.1/48kHz. And DACs oversample 44.1kHz audio streams (in MHz) too! That's not ultrasonic, it's radio frequency (and relates to why the use of a CD player is prohibited at times on airliners). Not to worry though, decimation and lowpass (and often highpass) filtering fortunately keeps the out-of-band nasties from getting through (at least, its supposed to if things are designed and working properly).
 
Another surprise: the cheapo onboard 'high definition audio" codec chip inside the typical PC/Mac can handle 192kHz digital audio (such as one might find as a primary audio stream on a Bluray disc) just fine (by design).
 
Here ya go Noel, he's written all about bit-depth too:
 
http://www.sonicscoop.com/2013/08/29/why-almost-everything-you-thought-you-knew-about-bit-depth-is-probably-wrong/
 

Goddard
Perhaps Noel (if he's still around) would care to confirm whether/when Sonar converts to integer format for disk storage (as WAV files iirc).

SONAR converts to integer (using dithering rules set  up) at the end of the signal chain just before the buffers are delivered to the audio driver. This is only done if the driver itself doesn't support floating point format. Some newer audio devices (that contain mixers) handle floating point formats directly in which case we simply pass on the floating point data.

I muddied the waters and contributed to the forum rubber-necking by asking that bit depth question, and re-triggered the 64-bit DPE thread! Now both topics are being analyzed ad infinitum.
 
I guess I at least have the comfort of the 44.1/48 sample rates, 24-bit files, and 32-bit processing being sufficient for... ever. Regardless of technology improvements, the point everyone fails to point out is that no one's hearing capacity improves... in fact, it gets worse. (I hope that doesn't trigger a hearing-aid technology discussion!)

Vastman
Goddard, one point interests me in particular, as it relates to increasing RECORD BIT DEPTH  to 32, which I am going to try after reading this: 
 

Although bit depth is a completely different topic from this thread about sample rate I'd like to clarify this. 
Changing the record bit depth has zero effect on audio quality. The option to specify a record bit depth in SONAR only exists as a convenience for cases when you want all data in a project to be a certain bit depth. It is also a potential optimization - all integer wave files from tracks must be converted to floating point before they hit any effects processing or mixers. Having the track data itself in floating point bypasses this bit depth conversion process which can save a bit of cpu (at the expense of more disk throughput of course).
In most cases today however there is no need to do this, since bit depth conversions are a relatively small percentage of the overall cpu load and we already optimize the hell out of these conversions using AVX, SSE2 etc. There is a white paper co authored with Intel on AVX optimization in SONAR.

Noel Borthwick [Cakewalk]
There is a white paper co authored with Intel on AVX optimization in SONAR.

Holy cow... this is a slam-dunk for the threads saying to use Intel over AMD with SONAR!

Noel Borthwick [Cakewalk]

Goddard
Perhaps Noel (if he's still around) would care to confirm whether/when Sonar converts to integer format for disk storage (as WAV files iirc).

SONAR converts to integer (using dithering rules set  up) at the end of the signal chain just before the buffers are delivered to the audio driver. This is only done if the driver itself doesn't support floating point format. Some newer audio devices (that contain mixers) handle floating point formats directly in which case we simply pass on the floating point data.

Sorry if I wasn't clear enough there, Noel. I was referring to the interim storage format on disk (i.e., what format gets written into the disk buffers for a project's audio files), not the output format sent to interface driver buffers.
 
Namely, whether floating-point or integer data is passed to/from disk i/o buffers.