I ran across this recently on page 285 of the Sonar Platinum Reference Guide.  Something I never really paid attention to before.
 

 
So I ended up going through my list of installed plugins to see if any of them had this ability.
 
After checking a fair number of them it turns out that I have about an equal number that do and don't.  The newest Cakewalk plugins, such as the LP plugins have this.  Even the old Sonitus FX have it.  But the Overloud Breverb and TH3 do not.  The freeware Blue Cat and Melda do not.
 
At this point I am left with this question.  Does it really matter?
 
If you chain together multiple effects, does it matter if you mix these two types in the same signal path?  Would you lose anything, or possibly create issues?
 
Inquiring minds just have to know, LOL!  FYI, I do have the 64-bit Double Precision Engine enabled here in audio driver settings.

Good question.... I have no idea and am interested too.

M@
Good question.... I have no idea and am interested too.

Thanks, Mat!  I had hoped there might be a few more folks interested in this topic.  I cannot seem to find much Cakewalk documentation on this subject.

Well, it stands to reason that if you can't pass 64-bit data to a plugin and/or it can't output 64-bit data, then the necessary truncation is going to negate some of the benefit you might have derived from doing all your calculations with 64-bit precision.
 
The pertinent question is: does this loss of precision have audible consequences? I do not believe it does.
 
The benefits of higher-precision calculations are small. So small that they only become potentially significant cumulatively, over the entire end-to-end process. Even then, it's unlikely you'd hear the difference except in extreme and unusual circumstances.
 
Other mitigating factors...
 
Many plugins that are unable to accept 64-bit input still perform their internal calculations with 64-bit precision, independent of the resolution of the audio engine.
 
Audio clips are ultimately stored as 32-bit data regardless of how that data was derived. It's as if you'd inserted a 64-bit-incapable plugin at the end of every fx bin on every track.
 
Even if you don't enable the 64-bit engine and do all calculations with 32-bit precision, cumulative rounding errors are still going to be sunk when the data is ultimately converted to integer data, whether a 24-bit wave, a 16-bit wave, or AAC/MP3/FLAC compressed file. All of these formats require discarding the fractional portion of every sample, and inserting random noise to mask the resultant quantization noise.
 
I would suggest an objective test, not to determine if 32-bit plugins are a problem, but rather whether the 64-bit engine is worth the CPU and RAM overhead it incurs. Simply export your project twice, once with the 64-bit engine enabled and again without it. Then do a controlled A/B/X test and see if the frequency with which you can discern them is greater than chance.
 
Whether you are able to distinguish them or not, ask yourself which would have the greater impact on the song's quality: high-precision calculations or raising your limiter threshold 1 dB.
 
 
 
 

Hey bit, thanks for the analysis.  Which brings up another question...
 
If the leading DAWs have all implemented 64-bit audio engines, why did they go to all that trouble if it really doesn't matter?

abacab
Hey bit, thanks for the analysis.  Which brings up another question...
 
If the leading DAWs have all implemented 64-bit audio engines, why did they go to all that trouble if it really doesn't matter?

 
The DAW arms race. There's nothing wrong with 32-bit floating point, 64-bit double precision, or 48 bit fixed for that matter. However, it's a short leap from "64-bit operation offers theoretically better performance" to "we better have a 64-bit audio engine because most musicians will think 64 is better and other people have it." There are circumstances where the difference is audible, but with today's ambient noise floor, you're not going to hear it 99.9999999999999% of the time.

Ah!  Marketing fluff!
 
I have noticed a number of posts in various threads from other forum members that indicate they switched off double precision during troubleshooting, and left it off. 
 
Are there any documented cases of double precision causing a problem?

Although it's since been fixed, I do recall the Adaptive Limiter having an issue when the 64 bit DPE was turned on. And I'm almost certain I've read other posts in this forum about quirks that disappear once it's turned off. I've never had it turned on, myself.

bitflipper
...Many plugins that are unable to accept 64-bit input still perform their internal calculations with 64-bit precision, independent of the resolution of the audio engine....

Being a total bit-noob this makes me think that there are two "conversion" steps potentially altering the original file.
On the other hand; if you are applying an FX you are deliberately wanting to alter the original file in any case.

Another thought:
What if FX are set to bypass..... do they pass the data through raw or up/down sample nonetheless?

M@

bitflipper
...Many plugins that are unable to accept 64-bit input still perform their internal calculations with 64-bit precision, independent of the resolution of the audio engine....

Being a total bit-noob this makes me think that there are two "conversion" steps potentially altering the original file.
On the other hand; if you are applying an FX you are deliberately wanting to alter the original file in any case.

Another thought:
What if FX are set to bypass..... do they pass the data through raw or up/down sample nonetheless?

Just a point to keep in mind.  The 64-bit double precision mixing engine has nothing at all to do with the bit level of audio files or sampling rates.
 
It refers to the floating point math used by the code internally.  With 64-bit floating point math you have more digits to work with in memory, thus in theory, less rounding error is involved in the calculations.
 
Your audio is still processed at the sample rate that you set in your project.  No re-sampling involved.
 
Here is the geek-out 101 on Double-precision floating point math...
https://en.wikipedia.org/wiki/Double-precision_floating-point_format