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

----------begin_max5_patcher----------
1958.3oc6a08aaaCD+4Tf9+ffdpCvIPjRTRdu0tNrErk0BTTrG5JBjsoSTgD
oAEUR5J1+6ieH4Oknncocx55CwxllRGue2c+3cGc9xye1Y9SnOfq789QuO3c
1YeQLxYpwjibV6.m4Wl8vzhrJ0D8I36oS9j+nluiiefqFuDyYzkCSpKo07BL
WcSf1g0iw+7BrVn9SxH2368w1uOel5YIDv4oiW9vVjwmdaN4lqY3ob8MFEgt
.MxKJEdQvHuvwxWgh2u5QIVA4j1E.TM3+77mIuJtLxZ0cJsrDS36puhm+DLy
iN2aJslHDS6LJxIX0PJAuTGX3JwyIimSIW28T1DyB5BSRMgIgIARLAk.jnAR
gIgQ8hIfCFSlWPEOo0VJrLg0GytFSxlTf2X0uoRA60QvejQmgDSJNJPoqwIo
JEOXWmg4TVYlZ1wNFK50+H6NLK6Fr2L7c4Jqt2bFszqDmQ9KxKJyKJxqDNAj
YU+P2tNgC65DtGtNHiHXbhFAijW.ZHLJ8H36ThqpDvxt30zBbFau4O5wcIxX
bBP4tfRT5bH5nwcnoHNowIgVPPDC.8Em3Hib+6QjQ72WMVv1HBcEpctzouSs
FXg4tQqGbqB2q0m6Ebwd6Xq05tU2.SpKLT4ViPZ+5wRK9ww6tG0MaRkiU3jw
1nviU12HvQy95pTAFlrNw797wwJMMAdj2m+jvUmDaQvajdq8uo3pSrgqFAPe
awUmXCWciVeD4pO8ovFGYQJrHjhKCDCNk4v1mK.OuDyNbefdvAit8v.MKdX3
QNduWx72RYqFciTuWsJS0VonvUdofsSVtKJ94TBmHbzTB5kr7rhNkzFznqAc
Hi4vCfPMZkz2pRJ9p7+VIdfjQ4z3FI7GlohKFXCicQGuWQKl4e.MO.YbSkXn
FaZRTRgZAOA.px7Y44j4TmCT8.RICCRPfBjhFeffzgGfVKBOqGJPTSS.z4.A
BA6tJ2Cl8PKBSy43xlFl4eU9TFshNm68Kuy6OE06ykBv6celvuUx+MR9xucN
b46eYMmVlsv6sL5BbQAlcKNal2U4OHYYalC5bu2e0OARgAdWc4quz6M0by2+
Neq71VN3Uu40+7u685ke9x6vrJJ47bxNCQWSRET5Bk30rgMiJ8OuOmgA6LxJ
c7Ov0bFk7BvOryB6We+kq4HlUTPueFK6lMrH8RCtiOsLCiQ5Mc6w8N0B2aj1
AJHXWOGYX4TZAkougfK.QiGs0Ev9yZzN5ja13gONB.RhG0461PJStYddQg5d
utEN70Optlh5UPqTBC.iiAi57cftkg5UX6C.NZsWLcGVqWGLAwjZNmRNjT3N
j1QiLl1RTpt9jTUkYvn1WcddqmXkFZgR2jq1QTo6sNzJNcgiJCEYttD8FfgM
G2.3nkVpAUMas7R+J00.aJ4Fp6WF7zmBdaqyk0e3MAyuGiIhOLsxtFmuGMZI
x7dDZyMBAVqq3GkNszWFgU3BwpQDUkJ1pJP7GrGWfHyQ2i18Z2tFfXyUmEqg
.0E.XntRD4b.gwyIdS163fdaGAzF0UWS5fEiBdbJFU2FP.L8zVLpQGETRiqw
3GoZQ6EQe0auZH.MVgjIvSKdBhrfJB.QOR.ZQ9c3KjMIULskovSHzUJk+xwu
KisDH5595C2UYPzjIklgAMTobfA5Nk80SH4DMbFDfPaLOMoIzwhu6h.pDa0M
65LNmkKxrCu5cUM1hVigDTKpwz4siu7KVGWxI4boeWS+fVI9tlUGn3FSqfRt
wjYbiIWJbVT.eJZoq2VSHWY.BC596qtUP0Ys3ZsactvqE5WE+yMYC2LgFe9U
u4HrMMvKv+vasvf6b6uYv97ro3dISLtuVBReL+580PwGXucB+5HSTn2dSkHu
qO.+ncbI5jWiBrqsPtkKoGZDiodGiZNp59V1RsuAhX0jNROpdiyr43y3fkmh
hVoESW0XHwUne2LO6Rork4rSNEfk7EldVsFG3ofNfiKWPU7u.uww6e2b8sLO
1gXALdr4wZuLPpxkSu+0APB39T7Uk673AZlqHbi1F1z3imBGc.WVe3iGnEYd
6FzSWPC93AZFynLM3Ipm1ivo4EZLaFjtMDMDY++837BCs.kfMM26I544AR0k
QE88yy66mm216w.rw+VG++8Cz6+fGnmIdTky7A2+sAKW1bNeMaAGo+kH5n8W
z2t5jK19+.G0hP9EagVUzZ1z13k1e3ydqsPlgq34jkAaeX0+7DdFMLVKP4Od
KKDXvlyhxlgYCrGq0KgDf0KAvQZIrs908RP9qV1Qvd6iZ.cF3LAJ+Gn3zJPv
l1qdDXn6fzXqrgtSCSrRCSBcq.GTCii5IVM3jQWr8B0oKAfU1Y0BE73uDNVj
lxeKTC67AcluGJwFUVspbj.sBiQtamPjUQWH2ENirZSGj6rgJ2V3fBD3VANn
SZKN3.ABsAQaidcgBZEc3XMJ3B4AsAPcmKJvJ.MxcxypPhsWUtkaOvVS5whZ
2tTCcWhZVA4NSbgmVwEchEmU4D5Pzzp.zP2wHDZk8KpaMroB4rEKjczp4Vzx
xuL6S5VRjNR+4bh9y5x68Y36xauEPyXYLQo8bQc80LcSBdn8+IK+RpHhjTm2
FTJUWorUMmP1TgpEMsOP0Dim+LwD9WnoOpLE
-----------end_max5_patcher-----------
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:

https://www.midi.org/specifications-old/item/the-midi-1-0-specification

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.

3 Likes

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.

2 Likes

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