While I was working on the final set-up of the new DAW, testing all sorts of things related to monitoring, latency, MIDI routing etc. I came across a very strange phenomenon with MIDI tracks and an external drum module today. Here's what I observed:
 

1. I play on the e-drums and record 8 audio tracks from the audio output of the drum module plus 1 MIDI track.
2. Now when looking at the audio recorded while playing, it lines up nicely with the metronome (i.e. auto-latency compensation appears to be spot on at various ASIO buffer settings)
3. MIDI notes, however, appear to be delayed somewhat. Am I right in the assumption that there is no auto-latency compensation for MIDI, meaning I would have to shift that manually forward by a few ticks?
4. When I use the recorded MIDI track, send it to the drum module and record the audio, it is delayed compared to the original recording (probably by what recorded MIDI was late, but I haven't done the math due to the following problem)
5. Now it gets weird. Everytime I play back MIDI and record the audio of the drum module, it ends up being lined up differently i.e. sometimes it's a bit earlier, sometimes later, but without changing any settings, just pushing stop & record & stop & record ... the difference is about 4 MIDI ticks (but converted to samples that's a lot already, enough to change the feel of the groove)

I did try a lot ot things (IgnoreMidiInTimeStamps=1, change playback and record timing master from the VS-700 to the Octa-Capture, ...) but to be honest I have no clue where this random drift could originate from.
 
Any ideas what could be causing this?
 
Thanks a lot.
 
Rob
 
 
 

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

Thanks Bob, but I'm aware of that and I have that option checked (which I tried to say at pt #2 auto-latency compensation for audio appears to be spot on at various ASIO buffer settings).

BTW, I did a forum search and read about MIDI being off, but none of the threads I found talked about the randomness that I encouter (sometimes early, sometimes a bit later)

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.

brundlefly

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.

Thanks, mate, for the explanation.  I reckon I might have gotten super-sensitive when trying to sort out various problems lately. However, I will give the Timing Offset a try. Since the default is at 0.000 it's easy to set back in case it doesn't improve the situation with the delayed MIDI recording.

 

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

Yeah, that's all stuff to setting the "Manual Offset", which is used to dial in your audio recording latency compensation. But syncing MIDI to audio with the "Timing Offset" is different deal.

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.