Page 239 of the CUBASE PRO 8.5 Operation Manual says:
If you perform a live recording on a VST instrument, you usually compensate the
latency of the audio card by playing earlier. In consequence, the timestamps are
recorded too early. If you activate the ASIO Latency Compensation button on the
track list, all recorded events are moved by the current latency setting.”
Cubase 8.5 and 9.0.10 really do the following: They delay MIDI note inputs from keyboards/controllers by the reported input latency of the audio interface [for both recording and internal virtual instrument (VSTi) triggering]. The monitored audio outputs of those VSTis are further delayed by the output latency of the audio interface. So, assuming the performer is monitoring with headphones, the perceived delay between pressing the key/pad is equal to the sum of the audio interface’s reported input latency and its actual output latency. The state of the ASIO Latency Compensation (ALC) control does not affect this.
When ALC is active on an instrument track (it has no effect on other MIDI tracks), Cubase will delay the recording of the MIDI note on that track by the reported output latency of the audio interface. The performer will be trying to “compensate” for his/her perceived latency (the sum of the audio interface’s reported input latency and its actual output latency). If he/she manages to do that, audio from subsequent playback of that VSTi will precede the audio from other playback tracks by the input latency of the audio interface (assuming the interface reported input and output latencies are correct). For ALC to do what the manual says it should, MIDI note recording on VSTi tracks should be delayed by an additional amount equal to the reported input latency of the audio interface.
IMHO changing ALC to perform as follows would be far more useful than just fixing it to reflect what is alluded to in the manual. When ALC is active, MIDI inputs should be delayed by the reported input latency of the audio interface. This would help keep them synchronized with the monitoring and recording of other inputs. This would help keep the monitoring and recording of external instruments triggered by those outputs synchronized with other inputs. Everything would remain synchronized on subsequent playback as well.
Cubase now always adds monitoring latency to MIDI inputs from keyboards/controllers to help keep everything synchronized for recording and monitoring. Performers wishing to minimize their monitoring latency from the instruments which those inputs trigger might like to have the option of preventing Cubase from adding that latency. De-activating ALC on selected MIDI/VSTi tracks could (should?) do that! Less monitoring latency would make it easier for performers that wish to “compensate” for it themselves to do so (as suggested by Novikthewise as well as the Reason and Ableton operator manuals). With VSTi’s they would still be “compensating” for the MIDI input latency and the output latency of the audio interface, so Cubase should still delay MIDI recording on those tracks by the interface’s reported output latency.
It should be noted that the efficacy of all of Cubase’s latency compensation schemes/activities rely on the accurate reporting of both input and output latencies by the audio interface. Some, like the 1st generation Focusrite Scarlett 6i6, report the sum of input and output latencies correctly, but not the individual latencies. Since, unlike Reaper, Cubase does not allow the setting of separate input and output latencies for those that don’t, this causes MIDI timing problems.
Here’s a more concise description of what I did in this thread and why I did it. Hopefully it will help those who wishing to achieve a better understand of these issues do so.
The test setup can provide relative timing information with sample period accuracy. It was used in this thread to help me (and hopefully some others) understand what MIDI ASIO Latency Compensation really does in Cubase. It can also be used to measure/compare the delay of tracks. With a slight modification (playing back tracks while recording the associated loopbacks), it can be used to determine the accuracy of the compensation that Cubase applies to adjust record timings to accommodate those delays. (https://www.steinberg.net/forums/viewtopic.php?f=253&t=111022 shows that procedure. (Note that this forum rather annoyingly opens URLs onto the source’s web page – so it’s best to right click on the link and open it in a new browser tab or window.)
The following assumes that Novikthewise, other than using a different version of Cubase (9 vs. 8.5), a different VSTi, and a different audio interface, followed the same procedures that I did for testing/demonstration.
My results with ALC OFF are here: https://www.steinberg.net/forums/download/file.php?id=19479
My results with ALC ON are here: https://www.steinberg.net/forums/download/file.php?id=19478
Novikthewise’s with ALC OFF and on are here: https://www.steinberg.net/forums/download/file.php?id=20640
Tracks 1 & 7 are recordings of waveforms produced by microphones tapping keys on MIDI keyboard/controllers. Those waveforms were monitored while they were being recorded onto the tracks. The input latency of the audio interface delayed Cubase’s acquisition (and hence recording) of the waveforms. The monitoring of the waveforms (via the track 1 & 7 interface outputs) was further delayed by the output latency of the audio interface. So, assuming headphones were used, the monitored sounds of the tapping (on tracks 1 & 7) would be delayed by the sum of the audio interface’s input and output latencies (its Round-Trip Latency or RTL) from the tapping. They would also be delayed by the interface’s output latency from their recordings.
The Track 1 & 7 interface outputs were externally connected to interface inputs for recording on tracks 2 & 8. The interface’s input latency delayed Cubase’s acquisition (and hence recording) of those monitored waveforms.
The interface’s output latency delayed the monitored outputs with respect to their recordings (on tracks 1 & 7). The external output to input connections at the interface added no latency. The input latency of the interface delayed the recording of the monitored waveforms. So, the delay from the microphone recordings (tracks 1 & 7) to their monitored (looped back) recordings (tracks 2 & 8) is the interface’s RTL (just like the latency of the monitored tapping sounds).
As stated previously, Cubase’s acquisition of MIDI notes caused by the microphone taps on the MIDI keyboard/controller keys were delayed by the keyboard/controller latencies. Since these delays are typically about several milliseconds (ms), they’re much shorter than the audio interface’s input latency in these tests. If Cubase didn’t delay the recording of these notes, their recordings (tracks 3 and 9) would precede the microphone recordings (tracks 1 & 7) by the difference in those two latencies. Cubase doesn’t know the MIDI latency so it can’t automatically adjust MIDI note recordings for that. But, since the audio interface reports its input latency, it can adjust for that (to the accuracy of the report). The delay between the microphone recordings (tracks 1 & 7) and the MIDI note recordings (tracks 3 & 9 respectively) was several ms (the MIDI latency) - showing that Cubase did indeed delay the MIDI input by the reported input latency of the interface. A simple way to demonstrate/prove this is to use a microphone to tap a key on a keyboard/controller and record the resulting microphone (track 1) and MIDI (track 2) outputs at two different interface buffer sizes. The differences in the delays shown in the recordings of tracks 1 & 2 will be equal to the difference in the reported interface input latencies shown for the two buffer sizes (shown by Cubase in the VST Audio Device setup window).
In addition to recording the MIDI notes on tracks 3 & 9, Cubase used the notes to trigger internal virtual instruments (VSTis) on tracks 5 & 11. The monitored VSTi audio outputs (tracks 5 & 11) were externally connected to interface inputs for recording on tracks 6 & 12. The monitored VSTi audio outputs (tracks 5 & 11) were delayed by the output latency of the audio interface. Their looped back recordings (tracks 6 & 12) were further delayed by the input latency of the audio interface.
My test results show that the looped back microphone recordings (track 2) and the looped back VSTi recordings (track6) were only offset several ms from each other. Both tracks were delayed by the audio interface’s RTL. With respect to the tap events, the audio interface’s input latency further delayed the recorded loop back microphone waveforms (track 2). So, Cubase apparently delayed the VSTi triggering by the reported input latency of the interface (as it did with the MIDI note recording).
The only notable difference in my two test results is that when MIDI ASIO Latency Compensation (ALC) was active, the recording of the MIDI note on the VSTi track experienced an additional delay equal to the reported output latency of the audio interface.
Novikthewise showed significantly different results with respect to the looped back VSTi audio recording on both tracks 6 (ALC “inactive”) and track 12 (ALC “active”). In his “inactive” case the looped back VSTi recording preceded the looped back microphone recording by approximately 18.4 ms. In the “active” case the VSTi loopback preceded the microphone loopback by approximately 48.4 ms (half the interface’s RTL). Yesterday I installed the trial version of Cubase 9.0.10 to determine why. That version of Cubase apparently has serious problems with delay instability in its triggering of VSTi’s form keyboard/controllers. I’ll look into that further and post another bug report to hopefully get that fixed too.