This has been suggested many times, and always the cw defenders say, not it isn't so. 
 
But here's one (of possibly many ...) situation where the bounce does a different thing than the playback.   I was shocked to have finished work on a project, pretty well tuned, and to hear the final chord horribly out of tune.     Turns out my pitch bend command was just before a patch change command on one note: so on playback, the pitchbend was still accurate, but on bounce, the pitchbend was cancelled by the patch change.  
 
So, a shift of a few ticks, so that one event comes before another, is handled differently by playback and by fast bounce.  
 
But go ahead, say it ain't so.

Here's the rendition with the bad final chord ...  the very last violin note.    
 
https://vimeo.com/227962686
 
I miss some things in audio, but that mistune is pretty shocking, so it wasn't, and isn't, present in the playback.

williamcopper
and always the cw defenders say, not it isn't so. 

I've never heard of this and I don't know anyone who has


Im sure what your saying is true. wish I had some insight Bill.
Thanks for the info though. this is good to know.
 
My best,
Chuck

Slow bounce it.

Yes, there are ways to fix it.  It's just so frustrating to find this kind of surprise.   Link above now corrected, so the offending chord is no longer present.   Seems like the patch change nulls out any pitch bend (and maybe controller?) settings, when done with fast bounce, while pitch bend and controller settings carry through patch change with playback and probably with slow bounce.

The question that immediately comes to mind is whether this is an issue with Sonar, or with the specific virtual instrument being used. In other words, whether this would happen with any virtual instrument, or just happens with this one.
 
 

CW defenders sounds like a cool kid's cartoon.
 
I tend to only fast bounce small clips rather than whole projects.
 

I don't recall anyone saying that there can be no audible difference between slow and fast bounces. What I do remember from last time this came up is lots of people suggesting reasons for why differences might exist.
 
In this case, it would seem that either a) the firehose blast of pitchwheel events overwhelmed the MIDI buffer, b) (more likely) the recipient synth took too long processing the patch change and missed some MIDI events (no mechanism for the synth to tell SONAR "Hold up, I gotta do this patch change first...OK, got it, please continue sending me data now"), or c) the synth flushes its input buffer when it changes patches.
 
Regardless of what happened, if this happened to me I'd chalk it up to user error and move on. Yes, I said user error and I'm not trying to be mean (I can't count how many dumb things I have done whose dumbness quotient only became apparent in retrospect). Programming a patch change in the middle of a sequence of pitchwheel events, and expecting the pitch to come out correct in the end, well that's just asking for trouble. You did exactly the right thing by moving the patch change out of the way.
 

My general rule of thumb is fast bounce [freeze] individual tracks (unless they are synths, then normal bounce).
And when bouncing down an entire song to be mixed as a wav or mp3 file, I always take the safe and secure route of bouncing down at normal speed.

williamcopperSo, a shift of a few ticks, so that one event comes before another, is handled differently by playback and by fast bounce.  
 
But go ahead, say it ain't so.

Well it can be so, but probably not due to your default "SONAR must be wrong" theory.
 

bitflipper
Programming a patch change in the middle of a sequence of pitchwheel events, and expecting the pitch to come out correct in the end, well that's just asking for trouble. You did exactly the right thing by moving the patch change out of the way.

+1. Remember that patch changes are not trivial. The target instrument may have to flush data before loading new data, load samples, whatever. Although MIDI data is sent out fairlypredictably, how a target device reacts to that data is not always equally predictable.