Rack v2 still has midi clock jitter issue from other Daws?

Just tested with Impromptu clock, ableton, loopbe windows loopback driver. Display at Impromptu still shows behavior like in previous version although I thought it was been fixed at least according to the changelog (smth about better midi timestamps). Is anybody experiencing the same?

P. S. And thanks to Andrew for implementing recent additions to Rack including things I wrote under in my first impression video! :wink: (knob sens, duplicating without cables command and favorites hot key in browser)

1 Like

  • 120 BPM Clock from VCV Rack 2.git.5c47e6e0 to max through loopmidi ~ 6.85 ms jitter

  • 120 BPM Clock from Max to max through loopmidi ~ 0.6 ms jitter

  • (8k sysex buffer size in loopmidi)

I’m not an expert, and don’t know if this is the way to measure midi jitter.

Max patch

1 Like

I think MIDI jitter comes from the OS.

so you don’t gett mess at Clocked module display right? Just switching to loopmidi and still getting same result. Maybe I need to switch from ableton to smth else to test it correctly…

the BPM in clocked is not constant, that’s why i tried to measure the jitter in max.

If i raise the block size to 1024 in the audio module, the midi clock jitter is a bit better (~4.4 ms) at 120BPM. I use 48kHz sample rate.

  • at block size 1024 the jitter is ~4 ms
  • at block size 512, the jitter is ~2 ms
  • at block size 256, the jitter is ~6 ms
  • at block size 128, the jitter is ~6.7 ms
  • at block size 64, the jitter is ~6.7 ms
  • at block size 32, the jitter is ~6.7 ms

Found potential issue - ableton and Rack should be both ASIO and the less latency I set in Komplete 6 driver the less at least visual jitter Clocked received. But the display is still far from perfect view (118-121 bpm is showing but in a way faster manner then when WASAPI was been set)

I’m a novice in C++ programming - But it seems to me that the midi send granularity has to be finer than 1/200 sec to have accurate 24 PPQ midi timing. As far as i can read, the midi tick message is 10 bytes - and not a 30 (3x(8+2)) CC message, that is used to calculate the maximum rate here

Seperate queue needed for realtime midi messages (31250/10) Hz ?

  • clock (decimal 248, hex 0xF8)
  • start (decimal 250, hex 0xFA)
  • continue (decimal 251, hex 0xFB)
  • stop (decimal 252, hex 0xFC)
1 Like

I dont see difference between versions, but why second clkd around 129 bpm instead of 120, is this drift?

  • max to v1 ~ 1.4 ms
  • max to v2 ~ 0.9 ms
  • max to max 0.7ms

Strange - I don’t know how Clocked does it calculations. But I can see the jitter is lower on a Mac / with the MAX CoreMIDI virtual cables.

Here’s a test of MIDI clock jitter on windows 10

  • Reason → loopmidi → Max ~ 0.4ms at 120 BPM 24 PPQ.
  • Ableton → loopmidi → Max ~ 1 ms at 120 BPM 24 PPQ.
  • Cubase AI 11 → loopmidi → Max ~ 0.8 ms at 120 BPM 24 PPQ.

I hope the VCVRack team can match those midi clock latencies. 6 ms is seems a bit high.

Clocked and Clkd do not perform any clock averaging, and simply determine the clock speed from the last seen pulse interval. This has the advantage of reacting quickly to BPM changes, but unfortunately makes them more sensitive to clock jitter. So for this reason it might be best to use low PPQN values if jitter is a problem.

1 Like

“System Real Time Message” Page 7

Removed due to copyright.

"Copyright © 1995-2006 and 2014 MIDI Manufacturers Association Portions Copyright © 1985, 1989 MIDI Manufacturers Association, Japan MIDI Standards Committee Portions Copyright © 1995 Jim Heckroth, Crystal Semiconductor Corporation, Used with Permission ALL RIGHTS RESERVED. NO PART OF THIS DOCUMENT MAY BE REPRODUCED IN ANY FORM OR BY ANY MEANS, ELECTRONIC OR MECHANICAL, INCLUDING INFORMATION STORAGE AND RETRIEVAL SYSTEMS, WITHOUT PERMISSION IN WRITING FROM THE MIDI MANUFACTURERS ASSOCIATION. "

You can download the MIDI specification document for free after registering.

Free registration:


page 7. (fair use) my emphasis:

System Real Time Messages

The MIDI System Real Time messages are used to synchronize all of the MIDI clock-based equipment within a system, such as sequencers and drum machines. Most of the System Real Time messages are normally ignored by keyboard instruments and synthesizers. To help ensure accurate timing, System Real Time messages are given priority over other messages, and these single-byte messages may occur anywhere in the data stream (a Real Time message may appear between the status byte and data byte of some other MIDI message).

The System Real Time messages are the Timing Clock, Start, Continue, Stop, Active Sensing, and the System Reset message. The Timing Clock message is the master clock which sets the tempo for playback of a sequence. The Timing Clock message is sent 24 times per quarter note. The Start, Continue, and Stop messages are used to control playback of the sequence.

The Active Sensing signal is used to help eliminate “stuck notes” which may occur if a MIDI cable is disconnected during playback of a MIDI sequence. Without Active Sensing, if a cable is disconnected during playback, then some notes may be left playing indefinitely because they have been activated by a Note On message, but the corresponding Note Off message will never be received.

The System Reset message, as the name implies, is used to reset and initialize any equipment which receives the message. This message is generally not sent automatically by transmitting devices, and must be initiated manually by a user.

There is Fair use legal thingy, I might be wrong, but in some contexts this might allow posting snippets like you did. How we suppose to have conversations about something without mentioning details about this thing? All I know about “Fair use” is from this podcast episode - We ask a lawyer about GitHub Copilot with Luis Villa, co-founder and General Counsel at Tidelift (The Changelog #458) |> Changelog

Considering the document is free of charge, and available on the internet. I guess it’s ok to quite it. I have pasted the text back in my post.

I’m a novice regarding C++ and programming in general, but it seems to me that the midi clock message output is not prioritized in VCVRack and is limited to one message every 1/200’th second.

Output is L115

I have mailed support@vcvrack.com, linking this thread.


I haven’t checked though the code, but I was wondering if the clock stability was attempted to be improved by using Midi Time Code (MTC) in combination with the traditional 24ppqn midi clock we all know and love. While I’m mostly talking from in-experiance, I was under the impression that using MTC, while requring absolute time stamps which is a tad meaningless in rack, would be more stable?

  • Use MIDI timestamps in MIDI-CV, MIDI-CC, MIDI-Gate, and MIDI-Map to improve overall timing and drastically reduce clock jitter.

from Rack/CHANGELOG.md at v2 · VCVRack/Rack · GitHub

Though this might only apply in the VST?

I’m also not sure how having the faster-than-realtime audio rendering would work if clocking isn’t made dependent on MTC?

I’ll poke around the source later if I get the chance, but having The Word™ from Andrew himself on how Midi clocking, time code, and engine clocking are working together at a high level would be appreciated.

As an aside, if MTC is being used now, I feel for Andrew in development, as it hurts my brain a little.


MTC is not relevant, VCV Rack doesn’t have a timeline.

But MIDI realtime messages should be put in front of the midi message queue.

The Rack For Daws (studio edtion? IDK, I’m very mixed up on terminology now) implementation will almost certainly be able to get MTC from the host DAW. Plus, even the community edition will be able to render at faster-than-realtime now, so I could see whenever that render is initated counting as the ‘0:00’ of a timeline.

Could be, we will probably never know, as that part is closed source.

MTC refers only to a timeline, which has no meaning inside Rack itself.

Even if you were running Rack as a plugin inside a host (DAW or otherwise), it would still be meaningless almost all the time to know “where we are on the timeline” in MTC terms.

Moreover, MTC is a video timestandard, and has no particular relationship to musical time (beats) or audio time (samples).

VST/LV2/AU/AAX plugins can ask the host for timeline position, but almost never in terms of MTC (video frames).

1 Like

That’s not quite true. most “pro” midi sequencers in the 80’s could sync to MTC. They would apply their own temp map and start time to the MTC. This let a sequencer start up in the middle of a song in sync. It’s true that has less application in rack, but it’s still a clock source that one can derive stable timing from.

1 Like