VCV Rack 2.02 Pro clock syncing in Cubase 11

Have you tried routing CLK out on MIDI-CV into BPM on Clocked and setting clocked to use P24 mode?

That works perfectly with Ableton Live. Getting the sequencers to start in sync is trickier, but I connect START on MIDI-CV to Reset and Run on Clocked and it works well enough.

Yep, that’s how I set it up, but in Cubase, even though it’s it’s synced, there’s always an offset, unless you start playback from the project start.

This is how I do it now. Using the Trigger Buffer to send a pulse to the Clocked Reset on the first beat of a bar. It starts in a mess and then ties together as the Trigger Buffer sends its pulse.

When running as a plugin, wouldn’t it be best to get timing information from the host and expose it directly as CV signals? VST2 plugins are given “pulses per quarter” position as part of the time information, along side a few other values.

VST2 documentation says:

VstTimeInfo::ppqPos : At tempo 120, 1 quarter makes 1/2 second, so 2.0 ppq translates to 48000 samples at 48kHz sample rate.

.25 ppq is one sixteenth note then. if you need something like 480ppq, you simply multiply ppq by that scaler.

And there are fields related to MIDI clock sync too:

VstTimeInfo::samplesToNextClock : MIDI Clock Resolution (24 per Quarter Note), can be negative the distance to the next midi clock (24 ppq, pulses per quarter) in samples. unless samplePos falls precicely on a midi clock, this will either be negative such that the previous MIDI clock is addressed, or positive when referencing the following (future) MIDI clock.

Sounds doable to take these values and use them to generate host-perfect-sync signals, it is what sequence-type plugins use for syncing.

1 Like

Rack 2 Pro is closed source, including the midi>cv and cv>midi modules.

They may allready use this method. Who knows - we run a different core in VCV free.

Or just plain good-enough midi - if the “midi system realtime messages” had priority that is.

From my limited knowledge of C++ and the rack codebase in general, I think this is a problem - the midi messages have to be split in a normal and a priority queue (for clock, start, stop and cont), or we get problems. Resulting in a not-best-in-class midi jitter.

Higher priority tasks - not a goal ? - I don’t know.

unless it is different on the pro/closed version, core MIDI modules do not run at the ends of the processing chain. on Rack2 APIs there can only be 1 master module, which is typically an audio one.

I mention this because host sync based modules would need to run first before all others, alike the master module concept, for the sync to actually be correct. If a regular module was added before a core MIDI one, typically as Rack engine runs modules one by one in order, there can be the case of time-based modules running before the MIDI one has a chance to fetch info from the host.

I dont think this is different between Rack Pro vs Free, otherwise the APIs and SDK would have something to accommodate for this and currently it does not.

One idea I had to deal with this particular issue is to introduce the concept of “Terminal Modules”. Special modules that always run at both start and end of the process chain. Instead of having a single process function, they could have 2 - one for inputs, one for outputs. That would allow to fetch info from the host before giving it to other modules. (aka, process the inputs) And the same applies to the end of chain too, if a module is allowed to run last we can ensure the data it has will be as sync-perfect as it can possibly be. (taking into account constraints of the API, not having latency compensated cables)