I just bought VCV Rack Pro 2 today and I am interested in this topic because I am also unable to get start signals from Cubase to come through the MIDI-CV module. I can’t even get continue signals like @Jens.Peter.Nielsen seems to be able to. I’m pretty sure this is the cause of @user559’s issue since the clock will set the right BPM but that clock will not start in sync with the Cubase clock. What is interesting is that stop messages do come through correctly, so the transport is making it through to the plugin in some way. This is very concerning since it means that basically all sequencing is broken in the VST plugin. Is this a bug or are we not setting things up correctly?
It’s an issue with Cubase. The VCV plugin itself has no transport system, so it is relying on the host midi.
I tried midi syncing with Cubase 11 pro, result is sloppy and half a tick too late.
Other 3 daws i use don’t have this problem, with exact same basic midi settings.
Cause of this differences i generally prefer to use clock pulse sync instead of midi sync, that just works 100% reliable, every time the same.
Why are you using CLK/N which is a division of the clock (and some users report it’s not so reliable). Use the main CLK output from Midi > CV - it is the main 24ppqn pulse from the DAW.
Contrary to my initial expectations, I’ve found it’s better not to connect anything from Midi > CV out to Clocked’s Run input at all - Clocked will run automatically when it detects an active clock anyway.
START on Midi CV only outputs a trigger when you are starting from the very beginning of the timeline in the DAW. CONT outputs a trigger every time the DAW starts playing from anywhere on the timeline (including the start) which can be more useful.
Also experiment with Clocked’s reset options when Run turned on/off in its right click menu as this can make a big difference.
1 Like
This. Just use the CLOCKED mode buttons to set it to P 24 and should be a good lock with your DAW tempo.
1 Like
It doesn’t matter, neither START nor CONT outputs anything when running as a plugin within Cubase. STOP does output when stopping the Cubase transport, so some amount of transport information is making it through the plugin. When I tried running CLK to anything from Cubase, it was running WAY too fast. I had to use CLK/N. I connected to ML’s BPM Tools module and saw the clock running over 3000. Maybe because Cubase runs at a base PPQN of 1920?
It shouldn’t matter what Cubase’s base PPQN is - all DAWS internal clocks run at thousands of PPQN - the CLK port on Midi > CV outputs 24 PPQN.
Did you definitely set Cocked to P24 using the mode buttons? If you don’t do that then Clocked will display a BPM that is way too fast.
Weird that you are not seeing any triggers from START or CONT
Yeah, it was set to P24 for sure. You can’t really set it any higher. It wasn’t clocked that displayed it. First I was trying to drive a sequencer and it ran way too fast. Then I fed it to BPM Tools to see what it was doing. I also checked the signals for START and CONT with Scope. This has to be something with how the Rack Pro plugin is interfacing with Cubase, it works with other plugins. I messed around with it for hours, I don’t think it was user error.
I’ve got a workaround idea that I have been trying out and it seems very promising so far but has an issue that I’m sure someone can resolve. Assuming that CLOCKED is fed a clock signal from MIDI CV and is set to P24 mode you can then use VCV’s MIDI GATE module to send a gate to CLOCKED’s Run input. Now, in Cubase, create a midi track that sends a single midi note on (beat one) to trigger the Run function on CLOCKED via the MIDI CV module. To do this, set one of the MIDI CV module’s midi note number outputs to reflect the note number of your triggering midi note in Cubase. For example C0 in Cubase will be C1 in the MIDI CV module. You can also take a feed from this to the reset in CLOCKED. Pressing play in Cubase now starts CLOCKED (and for example a connected SEQ3) in sync! The only problem is that sometimes pressing play will play the sequencer’s pattern and sometimes it only seems to repeat the first note (I think) of the pattern.
I did manage to figure out that I’m just dumb and didn’t realize how MIDI continue messages work. If I start playback from anywhere other than the beginning of the timeline, I do get a continue message through the MIDI-CV module. So it seems that only the start messages are being missed by the plugin. That has to be a bug since all of the other transport messages come through.
I’ve wired this up several different ways now, triggering run with continue, triggering reset with continue, clock from standard clock output, clock/n set to P24 and feeding Clocked in P24 mode, triggering reset with stop. No matter what I do, I still can’t get a kick drum to predictably play in time with Cubase. I put a snare on another track with a different VST drum machine with hits on beats 2 and 4. Sometimes they play on the kicks, sometimes they are way off the kicks. I think @user559 is right, there is some kind of sync issue with Cubase.
I think I found a somewhat duct-taped approach to get it playing in sync. I set a G8 1/16th note to play at the beginning of a bar and send that gate signal to reset on a clock or sequencer. Less than ideal if you want to run sequencers and feed MIDI notes from Cubase at the same time, but I suppose you could always channelize notes away from the reset signal.
Having downloaded and experimenting with the DAW - WAVEFORM FREE, I realised that the same syncing issue was present here as well.I went back to CUBASE and found a solution to our little problem. What I have done is to take CLOCKED (or any other clock module) out of the equation and replaced it with gates and resets sent from Cubase. The screen shots below should be clear.
This set up provides rock solid sync, run and reset. You can time stretch your clock track parts to get any clock divisions/multiplyers, swing quantise or imitate the pulse width function by altering the length/position of the notes. So far, I can’t see any CLOCKED function not being available with this approach. If anything, this solution is more flexible.
but this cant be the solution, did somebody report this to vcv? it doesn’t bring a lot of workflow with it if there have to be several midi tracks and midi to cv modules just to be synced in a project, does it?
I too am having this problem, where Cubase 11 and the Clocked module will sync BPM correctly, but will play out of step with each other.
I just wanted to add that I had this exact issue when trying to sync the sequencer on Arturia’s Moog Modular plugin with Cubase (that was on Cubase 10.5). Seems like that would point to it being an issue with Cubase rather than VCV Rack.
I’ve been digging further into this. You can get a reliable clock pulse without a lot of fuss and without buying modules or plugins.
I’ve found that triggering the Bogaudio RGate with the Midi/CV module’s Clock/N output is the most reliable and flexible method. You have to have the Clock/N divider (in the right click menu) set to quarter notes, though. It seems as though whenever you go smaller than quarter notes (never mind 24ppqn!), Cubase and VCV Rack drift out of step.
Of course, you need several instances of RGate to get close to the functionality of Clocked, and I’d much rather be using Clocked and the 24ppqn pulse from the clock out, but for the moment that isn’t possible in Cubase.
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)