[SOLVED] MIDI Recording Latency Compensation

Your computer should handle this task without too much latency.
If you are using the ASIO-drivers of your scarlett solo, what buffersize (ms) have you set?

Why not use quantize? Maybe not 100% to keep some natural feel.

I always use nudge and quantize, but both are manual actions, which I have to constantly repeat them each recording.
The correct is that every hit on keyboard controller must be always correctly aligned in all bars, neither before nor after.
I think that if there is an obvious latency between the metronome and the keyboard response time, there should be some parameters that make this adjustment automatically.


 

   I am glad to help. Just be aware that the offset is applied to midi out ports also. So if you have any hardware synths you can end up chasing your tail.
  I eventually reset the offset to 0.00 and went back to using nudge.

pinguinotuerto
My understanding is that this setting deals only with audio not midi. So I believe that this is not the correct answer. It seems there is no answer to prevent this from happening. It has to be corrected after the fact.

It worked for me. See the help: http://www.cakewalk.com/Documentation?product=SONAR&language=3&help=0x22B1A
 
Timing Offset (msec). With this option, used for making very fine adjustments to the audio/MIDI synchronization of your project, you can offset the audio in your project by a number of milliseconds. A positive value delays audio by that amount. A negative value delays MIDI by that amount.
 

Didn't do anything for me.

brundlefly
Timing Offset may look like it's only applicable to the Chase Lock setting, but it's active regardless of whether Trigger and Freewheel or Chase Lock is selected. Its original intent was to allow syncing audio to MIDI-driven hardware synths on playback. But since it works by shifting the M:B:T grid against the audio clock, it will alter where MIDI lands on the grid when recording to the audio metronome.
 
If you only ever use soft synths, it might makes sense to solve a MIDI record timing problem with this setting because soft synths are handled like audio. But if you use hardware synths, having a large positive offset to make MIDI land later on the grid while recording will conversely cause it to be sent early vs. audio on playback. The bigger the offset, the more it will work against you on playback. But, again, this will only be a problem if you use hardware synths.

Then I need to experiment with it more to see if I can resolve this issue. I'll try again and post my results. Thanks for clarifying that. Perhaps Cakewalk should separate or differentiate that setting visually from the Chase and Lock setting so that users can be aware that it isn't only active when Sonar is in slave mode.

brundlefly
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.

I'm still a little confused. If that were the case, wouldn't the pre-existing audio tracks be delayed also causing them to fall behind the newly delayed MIDI anyway, therefore leaving everything out of synch still?
What seems to be happening is that the MIDI is now landing where the audio was landing originally and they are in synch. The original audio was recorded to the metronome before the change was made to the settings, so if the metronome were now playing later than it did before, things wouldn't line up like they are. The metronome seems to be playing just like it did before, but the MIDI lands now where it is supposed to in relation to the audio.  My head is spinning. Although I'm glad the problem is solved.

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.

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.
 
 

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.
 
 

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.