The triggering of internal virtual instruments (VSTis) from MIDI keyboards/controllers is very unstable on Cubase 9.0.10 with Windows 10 Home. Here’s a demonstration of the problem. Hopefully the description provides sufficient detail for it to be reproduced. If not, please ask for further details.
As shown below, a MIDI note produced by a Roland TD-15 virtual drum was initially recorded on Track 1. Cubase routed that recorded note (from Track 1) to the MIDI output of a 1st generation Focusrite Scarlett 6i6 interface for “monitoring” during subsequent loop playback/recording. The 6i6’s MIDI output was externally connected to its MIDI input for recording on Track 2. That MIDI input (Track 2) was used to trigger a VSTi on Track 3. The audio output of the VSTi was recorded on Track 4. ASIO4ALL was used with the computer’s internal Realtek-HD sound “card” as the audio interface and the 6i6 was used for MIDI. Additional details of the configuration are available for the asking.
The markers show that the minimum VSTi audio delay (the 48ms delay between Track 1 & Track 4 lanes 2&10) was quite close to the correctly reported ~45ms output latency of the audio interface. Track 4 lane 9 was delayed by an additional 37ms! Other testing that I’ve done suggests that the problem is likely the result of faulty application of the VSTi triggering delay intended to compensate for audio interface input latency.
Any audio and MIDI interfaces and keyboard/controllers would likely produce similar results. In fact, this problem was first brought to my attention by Novikthewise at https://www.steinberg.net/forums/viewtopic.php?f=229&t=111073#p626490. I hadn’t noticed it in my testing with Cubase 8.5 (also reported there). Unfortunately, I can’t try/look harder because my Cubase 8.5 trial period has expired. My son is using the 8.5 & 9 licenses that I bought for him to make music (which I don’t do). Maybe someone else would be willing to do similar testing with Cubase 8.5 (and/or older versions) since Novikthewise apparently isn’t!
The test that has been conducted here is outside normal use parameters and applies routing that is not indended or Cubase (and i quess any other DAW) was designed for. These findings are interessting but will not arise from the intended use of Cubase. If the problems that Amack exposes here would also show up in normal use of Cubase it would pretty much be unusable wich i can say its not. Unfortunately Amack fails to understand that his test is meaningless for people who actually work with Cubase because the routing he applies would never been used by someone who actually knows how to work with Cubase. But he is relentless and persistent in his claim. Its also not understandable why the onboard sound was used instead of the 6i6 for the audio routing.
Its like driving a car into the river and than complain it doesn’t swim
The maximum timing error is equal to the reported input latency of the interface. Smaller buffer sizes might make it even harder to notice. But it is there and shouldn’t be.
The only thing different about the routing was the MIDI loopback to provide a highly repeatable VSTi trigger. The playback of the pre-recorded MIDI note on Track 1 was the source of that trigger. Track 1’s output was routed to the 6i6’s MIDI output. The 6i6’s MIDI output was connected via a standard MIDI cable to the 6i6’s MIDI input. That MIDI input was recorded on Track 2 and triggered the VSTi on Track 3. So, when doing the 2 second looped playback/recordings shown in the 1st post, the VSTi was triggered at a very accurate repetition rate (less than 3ms of jitter as shown) https://www.steinberg.net/forums/download/file.php?id=20852. This was done to make it easy to see the time shift in the audio recording “takes” https://www.steinberg.net/forums/download/file.php?id=20851
Are you saying that you think it’s irrelevant that Cubase adds jitter to VSTi triggering because the magnitude of that jitter is equal to the audio interface’s reported input latency and you can’t hear/sense it?
Steinberg apparently doesn’t share your impressions of ASIO4ALL (nor do I). In fact, it’s performance with my Realtek-HD “sound card” significantly exceeds that of my 6i6. But, that really didn’t matter anyway because the only thing ASIO4ALL should have been doing in my demonstration was report its input and output latencies. From https://www.steinberg.net/forums/viewtopic.php?t=10051:
Well, Steinberg support (now?) says not to use ASIO4ALL. So, I did another demonstration using a 1st Generation Focusrite Scarlett 6i6 as the audio interface – with nothing “looped back”! I used a Roland TD-15K Virtual drum (V-drum) as a synchronized audio (via its audio out) and MIDI (via its USB connection) source. As shown in the following pictures, everything was recorded live as I repeatedly hit one of the V-drum pads. I then selected two recorded samples to compare the timing of the VSTi MIDI note recording and the VSTi audio output. Consistent with all previous findings, there was far more “jitter” in the delay of the VSTi audio output (18 ms) than in the VSTi note recording (1ms). This again supports my claim that there is a Cubase software problem with the timing of triggering of the VSTi rather than a MIDI timing problem.
The ~13ms delay in the MIDI recording from the TD15 audio recording suggests that the 6i6 over-reported its input latency by ~13ms at its “20ms” buffer size at 48k Samples/second. I’ll verify that if/when I get around to it.
Indeed this happens. I have to admit that i don’t understand why. But:
This becomes significantly less problematic when playing at low latencies what you usually would do anyways and the jitter will also get much smaller. (i never noticed anything like this when i played my drums or other instruments. But i then tested with my highest possible buffer and i noticed that also by playing). Repeat the test with you lowest possible buffer setting and measure the variance there.
Secondly i found that this only happens with the monitoring signal of the instrument. Once the midi is recorded and you than directly connect the midi track to the instrument and play it back this doesn’t happen. Or if you render in place your instrument or even loopback record the instrument with the allready recorded midi notes everything is right in time. at least in my tests. So this problem only exists during mornitoring of the instrument but becomes insignificant at very low latencies what is mandatory for playing VSTi instruments.
It sounds like you were already aware of this problem, right? Do you think its caused by MIDI timing jitter (like Chris)?
As I’ve said, the magnitude of the variance is approximately equal to the reported input latency of the audio interface. But you should consider that tolerance to that jitter likely varies greatly among performers. In fact, what started me on this long and needlessly tortuous path was my son’s claim that the ~2ms added delay between a keyboard/controller’s pads with respect to its keys was bothersome. Not many interfaces have less than 2ms of reported input latency - especially at the lower sample rates.
So, you’ve effectively demonstrated that the source of the problem isn’t MIDI jitter after all - thanks
IMO and experience suggesting workarounds, ignoring, and/or obfuscating problems in products is counter productive and not a viable business practice. That’s particularly true with software because there is no way of knowing the real impact of those problems unless/until they are properly investigated/addressed.
So you had a jitter of 18 ms at an input latency of 41ms. Lets scale that down a bit shall we?
so at 4ms input we would have a monitoring jitter of 1.8 ms
i usually work ad 3.2 ms input/output and my monitoring jitter would be around 1.5 ms than right?
that must have an earth shaking impact i just wasn’t aware of
The 18ms was for 2 instances close to each other that I happened to randomly catch. That’s why I did the original MIDI loopback test to conveniently exercise and compare more test recordings. Everything so far (including your posted results) suggest that the magnitude of the jitter is approximately the reported input latency of the audio interface - but who really knows.