Random MIDI drift

Check Preferences>Audio>Sync and Caching and look at the settings for Record Latency Adjustment - this may have something to do with it.

By default, Sonar will automatically adjust based on a query of the ASIO driver's reported latency - make sure that the box for that is checked.  There are other threads that go into this, you would have to search for them.  I use Google to search for forum threads because the forum's search feature is worthless.


Bob Bone

Dang it. Forum dumped another post. Here goes again...

There is a setting in Audio Sync and Caching called Timing Offset. This will let you adjust the relationship between MIDI and Audio, but I wouldn't mess with it unless the discrepancy is extreme, because the results can vary depending on whether you are using hardware or software synths, how you are monitoring, and how you have MIDI routed.

A 4-tick error (2ms at 125 BPM) is pretty much par for the course, and shouldn't be audible in most instances, unless you've got a recorded track and a MIDI-driven synth playing the exact same pattern with the same sound in parallel, in which case you'll hear the phasing/flamming.

The random variability is a function of USB/Windows MIDI port performance limitations, and response time of hardware controllers and sound modules. Again, so long as it's on the order of ±2ms, I wouldn't worry about it. That's pretty much as good as it gets, even if you're using a PCI-based MIDI interface, which is generally superior to USB.

It also helps if all your hardware is connecting to the same MIDI interface, and that interface is built in to your audio interface.

I think Noel or someone had explained a bit about that timing offset.  It is, if I recall, what you would need to use if the auto-calculated compensation isn't doing it for you.

I haven't yet found his post, but here is something from another thread talking about fixing that issue:

brundlefly 



For those who just have to have everything as perfect as can be, they can do this analog loopback recording, zoom the waveforms, nudge the recording back one sample at a time until it aligns perfectly with the original, and add this number of samples as a manual offset. 

Actually, just Zoom in real far until you can see each sample (obviously you want to set the Time Ruler to show samples) and then count the offset between the two waveforms.  Enter that value in the offset box and you're done :-)  Sonar is great though, and like Brundle said, this is really not a big issue anymore.  Keep up the good work Cakewalk! 
  
  

And from the Sonar doc:

Record Latency Adjustment (samples)
If you loop an audio output back into an audio input, and re-record a track this way, the audio doesn’t line up. For some sound cards, it is off quite significantly. This record latency adjustment is a compensation for that delay.
You can do an approximate measurement of the delay by turning on samples as the resolution unit in the Time Ruler, and comparing the original track with the re-recorded track. Then you can enter a value in the Manual Offset field to compensate.
If you use ASIO mode, enter 0 in the Manual Offset field and leave the Reported Input Latency check box checked (this check box only appears in ASIO mode). This will line up audio in most cases. If you think you can tweak it closer, use the Manual Offset field.
In ASIO mode, the current active ASIO device (remember ASIO can only have one active at a time) reports its “Input Latency.” You can't edit this value. This supposedly accounts for buffer size, A/D Conversion latency, etc. The check box allows you to use this reported value. It is checked by default. In any case, the amount entered into the Manual Offsetfield will be combined (added to) the reported value if you have it checked.



And lastly from the web:


Count the distance in samples by putting the Sonar time ruler in sample measurements instead of h:mm or bars and zoom way in so you can see the individual sample steps. Locate the beginning of each ping and make a note of hte sample address for each. Subtract the sample address of the original reference ping from the new overdub's sample address. If the overdubs are behind, the difference should be a positive number. That's the value that overdubs are misaligned behind pre-existing tracks.


I hope some of that helps, 


Bob Bone

How are the MIDI I/O drivers identified in Sonar? As "WDM MIDI"?

MIDI drift/offset wrt audio can also occur when audio and MIDI streams use different timebases, and can occur even when using the MIDI ports integrated into the audio interface. ASIO uses a different timebase for timestamping than does MIDI which uses whatever system timer routine the MIDI drivers/applications are coded to call (ASIO does audio only, not MIDI).
Roland's USB MIDI is pretty solid (Roland collaborated on the MIDI over USB spec), so one thing you might try is enabling HPET in your system BIOS (and resetting Sonar's "Ignore MIDI timestamping=0", to see if that helps. However, some people see higher system DPC latency when HPET is enabled, so ymmv. Easily enough reverted, so at least worth a try.