VCV CV>MIDI Hardware Jitter

Hi, long time listener first time caller.

I took a look through a number of resources here and on the wider web, but I haven’t really seen the topic explicitly addressed.

I’m having problems getting a hardware monosynth to play in time with MIDI it’s receiving from VCV Rack.

I made a sequencer in VCV out of a bunch of discrete components. It works fine for sequencing synthesis modules in VCV–audio is all on time and tight as I need it to be.

I haven’t even bothered trying to get VCV to sync to any kind of external or DAW clock. I’m just sending MIDI from CV>MIDI to the DIN port on my interface to the DIN port on the synth. But still no joy. Timing is total slop.

Has anyone had similar issues? Can someone help me diagnose where I’m making a mistake?

My setup for the experiment was this:

Lenovo T470 (yeah I know, it’s old) 16GB RAM, Intel(R) Core™ i7-7600U CPU @ 2.80GHz 2.90 GHz Windows 10 Home 22H2

VCV Free 2.3.0

Sequencer gate and pitch CV

VCV CV>MIDI module Gate in and CV in

MOTU Ultralite Mk3 Hybrid DIN MIDI port

Vermona Mono Lancet monosynth

Audio input of MOTU (have tried all buffer sizes from 64s to 1024s)

The result is that even with a steady sequencer clock from within VCV (Improptu Clocked), the timing of the audio coming back from the monosynth is extremely jittery. This wasn’t even me trying to get it to play in time with drums, we’re talking fluctuations of probably dozens of milliseconds at a time and from note-to-note.

I don’t have another hardware MIDI synth at home to try this with another way, unfortunately.

Can anyone suggest why this might be happening? The internet doesn’t seem to suggest this is a known VCV issue happening to everyone all the time.

The sad truth is: MIDI jitter is a b*tch and it usually get’s even worse over USB.

The MIDI jitter might be connected to your buffer size, so maybe it gets a bit better with smaller buffer sizes, but unfortunately there seems to be no way to get rid of it completely.

The only solution to get truly stable sync is to use audio signals. If you have a soundcard that allows DC on it’s outputs, you can use those outputs for CV and gate signals and use those to control your synths (if possible).

If your soundcard doesn’t allow DC output (most don’t, including mine) you should still be able to send trigger pulses in and out, but you might have to adjust them with attenuation and offset to make them work. The best way for me to use Rack standalone with my hardware synths is to clock Rack from an external audio pulse and sequence the hardware synths externally.

This also has the advantage of reducing the difference in latency between Rack and external synths, since Rack is effectively compensating for the input latency by syncing to a clock that arrives on the input.

1 Like

In principle, MIDI 2.0 has a “jitter reduction” feature. Remains to be seen who adopts it, and what the results will be. Hopefully we’ll see more progress on MIDI 2.0 adoption once Windows, the last MIDI 2 holdout OS, delivers MIDI 2.0, supposedly towards the end of this year. AFAIK, the Windows stack is not currently planning on doing anything with jitter reduction in the initial release, but that doesn’t mean that it can’t be used by applications/hardware.


Here’s an extract from the manual of the hardware Eurorack module Pamela’s New Workout. It reinforces the practice of syncing via audio rather than midi.

It is not recommended you sync Pam to computer sourced MIDI clocks. Modern computers tend to give MIDI hardware (particularly over USB) a low priority compared to other system events. This notoriously leads to timing errors in generating the midi clock and thus any slave devices will not sync correctly. For syncing to a computer it is recommend an audio track based clock is used or you use Pamela as the master with MIDI clock from the expander to DAW. Always use as higher PPQN value as possible (24 recommended) for best sync accuracy. Use of a Run signal is preferred as there is less guesswork involved as to what speed to start the clock at and when to stop it.

1 Like

Thanks, but this isn’t a sync issue, at least not in the way Pam’s is warning about.

I’m not trying to sync a separate MIDI sequencer to a clock provided by VCV–ppqn values don’t even enter into it–I’m trying to send MIDI data out the DIN port of my audio interface to a hardware synthesizer.

I have used this process dozens, if not hundreds, of times with Ableton, Reaper, Bitwig, and other DAWs as the source of the MIDI. It’s not perfect, there’s a little bit of jitter sometimes. But it works. I’ve tracked plenty of music at release quality like this.

This is a wholly other story. With MIDI events generated by VCV Rack, the synth sounds drunk. It’s a cool effect, but not what I want all of the time. I’m wondering if other people have had similar experiences with this particular use case, before I start tearing apart my signal chain cable by cable to look for the problem.

How are you taking audio out of the synth? Is it:

A) Synth → MOTU → Monitors, or
B) Synth → MOTU → VCV Rack → Monitors

If it’s (A) I don’t know what to say, still plenty of ways your computer can screw up MIDI on the way to the synth.

If it’s (B), have you tried (A) and is it the same? What’s your block size in the Rack audio module when the problem happens? Does lowering the blocksize reduce the problem? Are there ways to read out and/or adjust the blocksize of the MOTU?

One thing to try: Before playing from Rack, close ALL other programs on the computer, look at the Windows task manager and if there’s anything left using CPU try and kill that too, and also try and pause/stop all anti-virus as well. Make any difference?

1 Like

It’s A’:

Synth > MOTU > Direct input monitoring.

The audio never touches the buffer. I can set up the sequencer patch with no audio modules used in Rack. I’ve still tried running the buffer at a few different sizes just to see how it affects the errors.

OK, this was really weird but it worked.

I thought by removing audio modules from the patch and just using VCV as a MIDI sequencer, that the CPU load would go down and it would be more stable. This is mostly true, except for one thing.

VCV really wants you to connect an audio output module.

I figured I would try and see how far off the midi was from the clock by laying down a little 4/4 kick. As soon as I dropped an audio output module into VCV and made the subscription to my interface headphone outputs over ASIO the MIDI started playing in time. I didn’t even bother patching up the kick, it just worked.

Can anyone suggest why this happened? Synchronization between the sample clocks of the audio interface and Reaper? Why would that matter for MIDI (I don’t pretend to be a wizard with the stuff)?

Thanks to all who have responded.


My guess is that the size of the sample buffer changes when you select another interface.

Ableton wrote something about it.

Anyways - expect changes - Microsoft Windows MIDI Services 1.0 is coming.

My understanding is that in Rack 2.x you have to have an Audio module present for a number of things to work. It doesn’t have to be connected to anything, just present.


Yes. It was changed I believe at the introduction of Rack v2, so that the Audio module drives everything in Rack in a kind of “pull” fashion, which is different from v1 and earlier. So yes, even if you think you don’t need it always have an audio module in a patch, even if it’s unconnected. It doesn’t really use any CPU.

What surprises me in this case is that anything worked at all without an audio module. In thinking about this case I suspect what might happen is this: The audio module actually drives the audio interface, with respect to samplerate but also with respect to clock and sync of the interface. Since the MIDI out being used is sitting in the MOTU it might make sense that the audio module should be connected up to the MOTU, so that everything (MIDI out from Rack) is synced up and clocked uniformly. However, it really baffles me to hear that what worked is connecting the audio module to another interface than the MOTU.

@timnordberg - what happens if you connect the audio module to the MOTU instead?

Hang on @timnordberg , why did you suddenly drag Reaper into this? You didn’t mention that originally. Do you have Reaper open at the same time, connected to your MOTU? Because then it is controlling and clocking/syncing the MOTU where your MIDI is sitting. Can you see the problem? At worst it might have been fighting with Rack for control of the MOTU (and hence MIDI) and that would make things wonky, and then it would make sense that changing to another interface in Rack would solve the problem.

I’m a bit confused about all the pieces at play in your setup here, and maybe you’re not telling the whole story… anyway, if you’ve got it working that’s what matters.