The OP posted because in a substantial project (10+ minutes) when I mixed some slow bounce and some fast bounce I felt there were some mis-matches that bothered my ear.

I've also posted before about a sonar bug that essentially eliminates midi controllers that have not changed out past a certain time frame .. this could be the source of the difference.
 

Just a thought about the terms "slow" and "fast" bounce. I believe these are misnomers. Better to call them real-time and non-real-time.
 
The non-real-time bounce is said to be fast because it doesn't wait for audio output to be delivered. However, it also means that it does not have to keep up with real time audio, hence can use signal processing algorithms that emphasize quality over efficiency. So theoretically, this could be the slower bounce, if the CPU is marginal for the project. But since projects might have significantly varying density or complexity in the timeline, the overall render time might indeed be shorter than real-time, even if the CPU would not be able to play the whole project in real time using "quality" algorithms.
 
Real-time bounce means it is probably producing essentially what you hear when you play the project. Since it is required to "keep up" with audio, it may be using a signal processing algorithm that emphasizes efficiency over quality.
 
Recall the oversampling that was added in Sonar. When first offered, oversampling would only be engaged during non-real-time export. If oversampling improves quality for a given track, then there should be a visible difference (esp. in the "null") compared with real-time bounce, and one would hope it sounds better.
 
In another thread it was also mentioned that some synths internally use different algorithms for real-time vs non-real-time (sometimes known as "render", here meaning the intention to place output in a file rather than sending it to audio).
 
So there are legitimate reasons for real-time audio to differ from non-real-time, not only bugs. Whether it sounds better, just different, or the same is not entirely predictable. And this discussion does not take into account the deliberate randomness mentioned above for some synths and effects, since that is seemingly unrelated to real-time vs non-real-time.

Very interesting point of view, bvideo.   I did note that the fast bounce in my OP image appeared to be more defined (more jagged edges anyway).    If that's right, how are we supposed to use sonar to build a mix?    Constantly bounce and listen?    Will end up being even more time consuming than 'slow bounce' ...  I'll look for more input on this.

If there is any kind of chorusing, detuning, or reverb (which usually includes some randomizing elements to give a more "realistic" effect), the results will be different. Also real-time bounces are subject to latency issues, but not fast bounces, which are all done as calculations inside the computer. I'd be more surprised if there was no difference between real-time and fast bounce.
 
Create a project with 10 tracks, each with a periodic waveform of a varying frequency (not a virtual instrument, e.g., a test tone generated in Sound Forge or whatever). Do not add any effects. Run the same test and see what happens.
 
 
 

bitflipper
It'd be an interesting test to clone the track and then bounce/freeze it twice in a row using the same settings and see if the waveforms still appear to be different. If they are, then that suggests there is some randomness in the patch, such as a chorus effect.

This.
Did OP try to do two fast bounces and two real-time bounces and compare all four files?

Anderton
Also real-time bounces are subject to latency issues, but not fast bounces, which are all done as calculations inside the computer. I'd be more surprised if there was no difference between real-time and fast bounce.
 

 
If you do an audible bounce, the output will be subject to latency, but the write to disk of the file is not.
 

Anderton
Create a project with 10 tracks, each with a periodic waveform of a varying frequency (not a virtual instrument, e.g., a test tone generated in Sound Forge or whatever). Do not add any effects. Run the same test and see what happens.
 
 

I've done this many times over the years with various projects. If every track is pure audio with all FX and automation bypassed or frozen into the individual tracks, real-time and fast bounces of the entire mix will null to perfect digital silence with one of them inverted. And many active synths and FX will, too - just not all.

williamcopper
I've also posted before about a sonar bug that essentially eliminates midi controllers that have not changed out past a certain time frame .. this could be the source of the difference.
 

 
I'm pretty sure that's just a display issue with controller shadowing. The synth only has to respond to the controller once, and whatever state is set will persist indefinitely until a different controller value is sent. Unless SONAR is actually sending another controller message with a value of zero at the point that the shadow disappears, there should be no change in the synth output.
 

The only option not checked on my bounce dialog is "64-bit Engine" ... because I've never known what that means.  Working now on some of the suggestions above:   doing the same bounce twice to eliminate any unintended randomness.     The fact that an audio track may bounce perfectly (or not) does not help and is not really relevant ... what I use is midi and vst instruments. 
 
One bug/feature I've noticed before is that sometimes the reverb tail of one bounce can be put at the very beginning of the next bounce ... kind of a wild effect. 

Here is very nearly the same passage, bounced twice:  once with fast bounce and once with fast bounce, 64 bit engine ... as you can see, they are very close to exactly the same.    So this eliminates all the comments about 'random changes in the midi or the synth'.