As mentioned earlier, MIDI driven soft synth output is buffered up in advance and handled like audio. It will be delayed along with all the other audio content on playback. Only 'real' MIDI messages going in and out of physical MIDI ports (or a virtual ports with drivers operating at the O//S level like LoopBE) are affected by the offset of the MBT grid.

Maybe an example of what the setting is designed to do might help.
 
I have a Waldorf microQ rack, which for anyone not familiar with it is a digital hardware synth designed quite a few years ago.
 
Let's say I sequence a MIDI part for it, with each note lying dead on the beat. I then send the MIDI out through a Motu USB MIDI interface which hands the MIDI on to the synth via 5-pin MIDI cables. I have an audio track that records the audio the synth produces.
 
Now, the process of sending the MIDI out through the interface takes a millisecond or two. The synth itself takes a few milliseconds to process the data and convert it to audio. Which means that Sonar receives the incoming audio at some time after the MIDI was placed in the timeline. The overall audio latency as adjusted by the ASIO buffer setting is irrelevant here, what matters is just the time it takes that MIDI signal to get converted to audio, which in the case of the synth in question is usually around 4-5 milliseconds.
 
That means that the audio in the track recording it will be delayed by 4-5 milliseconds compared to the MIDI. The preferences setting allows me to tell Sonar to automatically compensate for that by adjusting the relative timeline location of the MIDI and audio. Which is more convenient than shifting the audio to where it should be by hand.
 
The catch is that the preferences setting is a global one, and will therefore affect all audio resulting from MIDI in the same way. So if I also have my MS20mini hooked up, or a soft-synth running they too will have their audio tracks adjusted by the preference settings. Only they take a different amount of time to respond to MIDI, so the automated correction is wrong for them. So in that case I end up correcting any noticeable discrepancy by hand anyway.
 
The setting really dates from the time people often had a single synth, often a multi-timbral one, which they used for all synth-related purposes so a single automated correction factor made sense. And it is still useful if for some reason all MIDI and resulting audio is "out" by a fixed amount. Experimenting with it a bit is the best way to understand what it does.
 
I suggest running the experimental testing using MIDI drawn in the PRV or step sequencer or otherwise strictly quantified, because otherwise any timing discrepancies in the playing will mask the MIDI timing issue. We are talking about tiny amounts of time here, generally less than a human's level of accuracy especially if playing other than like a robot with perfect timing.
 
Personally I nudge audio if I feel it needs it, otherwise I generally leave it alone. A slight time difference can be useful to make quantified sequenced parts sound a bit less sequenced, and can help getting separation between different instruments at the mixing stage.

 
Hey tlw, thanks for your answer. There's also another step that you didn't mention that also adds a delay to the signal- when the output of your Hardware synth gets converted by your interface's A/D converters to bring it back into SONAR.  I understand all these concepts pretty well (I think ). What I am confused about is Cakewalk's explanation of these settings as I was telling Brundlefly.
 
Brundlefly, when you say, "The documentation is correct. A positive value delays audio (including the audio metronome) relative to the MBT grid. That means you'll hear the metronome click after the Now time crosses the grid beat, causing you to play late relative the grid so your MIDI lands later than it otherwise would." That is incorrect. This setting has no effect as to when the metronome is heard. I just tested it by changing the setting dramatically 3 times and recording the audio output of the metronome onto a track. The metronome plays in synch with the pre-recorded metronome audio tracks and lands perfectly in synch after recording so the audio isn't being shifted in any way by this setting. I also recorded 3 different MIDI drum takes using the same procedure and the MIDI landed on the timeline according to the settings I set in the timing offset box. In other words, the drum tracks were out of synch with the metronome and each other, landing early or late depending on which offset I set.
So when you say, "Only 'real' MIDI messages going in and out of physical MIDI ports (or a virtual ports with drivers operating at the O//S level like LoopBE) are affected by the offset of the MBT grid." that is not accurate. What is being affected is where the MIDI information lands on the timeline which also affects when soft synths play. 
 
I still think that according to what Cakewalk is saying, one would have to enter a negative value in that box in order to delay where the actual MIDI information lands in SONAR, but it's the opposite. A positive value delays the MIDI and makes it land later in the timeline and a negative value "accelerates the MIDI and makes it land early.  
 
Anyhow, I thank you both for your explanations and your time, and also the OP, rogeriodec and Base 57 who suggested adjusting this setting. It solved my issue.
 

No, I'm not wrong. Trust me, I know this functionality inside and out. Positive values delay the audio relative to the MBT grid. 'Audio' includes .WAV files, pre-buffered soft synths rendered in real time from existing MIDI, and the audio metronome.
 
You can confirm this by setting  a large offset (e.g. 200ms) in a project with no content, and just listening to the playback metronome while watching the Now time. Disable 'Stop at Project End' to allow playback with no content. You'll see and hear that the click is late vs. the Now time.
 
Now add identical MIDI tracks, one driving a hardware synth (either direct-monitored or input monitored with the lowest RTL your system allows), and one driving a soft synth.
 
Start playback, and note that the soft synth syncs with the metronome and both are late vs. the timeline while the hardware synth is in sync with the timeline, unaffected by the offset.
 
As an aside, you'll also note that the timing of the hardware synth is wonky for the first beat or so of the first measure, this is another reason to avoid large Timing Offsets.
 
 

I trust you. I know you're one of the most knowledgeable members of this forum, but when was the last time that you tried this? Could it be that it used to work in the manner you describe in previous versions and now it works differently? Like I said, I just tried this this morning 6 times (3 recording the metronome's audio output and 3 recording MIDI drums via VDrums/Addictive drums with the metronome on on record and playback and the only thing that changes is where the MIDI notes land on my timeline. I could see all 3 MIDI clips landing according to my offset. The metronome's audio always landed on the same spot regardless of the offset. BTW, 200ms is exactly the offset I used (-200, 0, +200) to run my tests.

pinguinotuerto
Like I said, I just tried this this morning 6 times (3 recording the metronome's audio output and 3 recording MIDI drums via VDrums/Addictive drums with the metronome on on record and playback and the only thing that changes is where the MIDI notes land on my timeline. I could see all 3 MIDI clips landing according to my offset.

Yes, that's right. Only Hardware MIDI input and and output are shifted. Metronome playback and re-recording are against the audio clock not the MIDI clock so the timing of the recorded metronome is not affected. Only hardware MIDI in and out will shift vs. the audio clock.
 
Just do the test I described; you'll see. I did verify nothing had changed before I posted just to be sure; it works the same as it did a decade or more ago when I first checked it out.
 
 

A quick note on the latency introduced by the ADC in the interface - this doesn't affect the MIDI/audio timing relationship (as in put the recorded audio behind the MIDI) because Sonar can correct for audoi inpit latency as it usually does based on the latency the ASIO driver is reporting (and anunadjustment to that made in preferences).

What Sonar can't so easily detect is latency between a MIDI track and a hardware synth because Sonar can't be sure that what comes back isn't a result of the synth's patch - e.g. the MIDI note might trigger a VCA envelope that deliberately includes a delay before the attack phase of the envelope.

In fact, Sonar doesn't even know that the hardware synth the audio is coming from is the one a particular MIDI track is controlling.

Hence the need for a manual adjustment.

Been experiencing this problem for the last few versions of Sonar. I believe they changed the Metronome engine at some point and that's when the problem started to occur.
My work-around has been to either NUDGE to the right after recording a midi track or lay down an old-fashioned click track to follow while recording.
Using Cakewalk's metronome seems to screw things up. My midi always Plants too early on the track.
Hoping Bandlab will be able to finally fix this issue.
 

There's nothing inherently wrong with CbB that affects all installations. My MIDI-Audio timing remains spot-on in recent releases as it has always been. This happens with some combinations of hardware/firmware/drivers, or may be project-specific or due to misconfiguration  I suggest you see my post #4 in this thread from a few days ago for steps to determine exactly what's going on in your particular case:
 
http://forum.cakewalk.com/FindPost/3794091
 
And if you want to continue discussion, you should start a new thread.