I m having fun playing with the renoise an the rack in Linux, and I have a rudimentary synch between the renoise and the rack, sending and receiving MIDI and CV bidirectionally. using triggers to send start and reset signals to the clock and LFOs
I m trying to receive the midi clock from renoise in the rack but I can not find a module suitable to convert the Midi clock to BPM (is it necessary??)
I m receiving gates - triggers signals in the midi-cv module, but if I connect it to the clocked for instance, the clocked go to 120bpm no matter whatever is the timing set in renoise
is this possible? any clue about the correct workflow?
You might need to choose another clock mode in Clocked, i.e. P2, P4, etc depending on the pulses per beat (aka PPQN) you have in your DAW. In its default mode, BPM is a CV input as opposed to a trigger input. More here in case this may help:
Hi @marc_boule, I tried to sync with Ardour’s Midi-Clock today - PPQN in Clocked set to P24, but the fluctuation stayed all the time and the tempo differed throughout the recording.
Running on Linux Mint with Cadence, using Catia to connect Ardour’s (5.12) Midi-Clock Out to VCV Rack (1.1.6) Midi-CV in … Clikc-Divider also set to PPQN 24.
Ardour did send a clock of 120 BPM, VCV fluctuated between 106 and 111 BPM (not only Clocked also BPM Tools and Klokspid) . Is there any chance to get these two connected IN-SYNC? What am I doing wrong?
Hi @AlasdairMoons, sorry to hear you’re having troubles with the sync. I am not very knowledgeable in these types of setups, but what I have heard is that midi clock is intrinsically not very stable, and people seem to get much better results by actually sending a clock signal through an audio channel, and then from that audio channel to Clocked’s BPM input, in Pxx mode. Hope this helps!
I can confirm this, in Ableton Live at least. Using midi clock always had somme jitter… By switching to an audio pulse and the Pxx mode in clocked, got sample accurate synchronization.
I don’t not why but actually renoise is the only one that have a very stable clock, but sometimes it acquire some jitter, Jitter is a problem across all platforms
in Linux you can send gates or triggers directly through a Jack audio channel (no midi involved ), in my experience it is better if you need a very stable clock
Midi Clock-Sync between Ardour and Renoise is very quick and stable on Linux too.
The problem is not the Impromptu Clocked module, but it seems the how VCV receives Midi-Clock.
On Linux and Windows, if I use Renoise or Ardour or even my external Midibox Sequencer, there are a lot of Pulses dropped within VCV 's Midi-CV Module (set to 24 PPQN)
Thanks for the valuable research. Be careful with VCV:Scope and short pulses/triggers though. I have noticed that Scope does not show all of the really short (Schmitt) triggers, if that’s what the MIDI clock produces in Rack, only some of them, and some other modules don’t either, so it would be good to reproduce in some other modules and/or scopes. Thanks.
Same here… I would like to sync everything to a MIDI clock, but only Renoise seems to be able to do it stable, no luck with any other software so far.
Maybe the Renoise developers could share how they do it with the VCV developers?
perhaps a way to give more stability and reduce de Jitter could be add a option to “clamp” the bpm, the user set the time in the clock and clamp it and only use the external input to sync it every certain number of beats
That would be a nice feature … but then again, it is not the fault of @marc_boule 's Clocked module.
Somehow these jitters are from within the midi-core of VCV. Sometimes the boolean to generate a Pulse in dsp::PulseGenerator is simply not triggered, but I can’t find out why.
@moDlls MidiPoly16 has the similar jitters in BPM but produces even better Start/Stop Pulses than VCV Midi-CV.
If I take Ardour f.e. it does never change the BPM when syncing to a Midi-clock, but for Ardour the BPM is just a sort of Grid in Time, it does not change the Audio when chaning BPM.
I did a whole bunch of tests now an must say … I give up … my coding skills are not that good to really pin down what the coding-pros can’t handle
I think the resync would be potentially disruptive if the difference in phase is big enough, so not sure this would work well. I thought (and tried) implementing some averaging, but I didn’t get it to work well enough, so I dropped the idea. I might re-attempt that in the future though, but in the end, I opted to have Clocked sync on every pulse the best it can do, so as to always be in sync as fastest as possible. This does unfortunately make it susceptible to jitter.
For added context in this thread, here’s an interesting except from the manual of a very popular Eurorack clock module (Pam’s New Workout). Although no USB is used in the VCV use cases discussed in this thread, I think it still recaps well how midi clock is jitter-prone.
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.
Time spent trying to get stable sync through midi will just lead to hair pulling and gnashing of teeth…
Best thing you can do is give up on that and start down the audio pulse sync path which will quickly lead to sync heaven and you’ll kick yourself for spending all that time trying to get midi to work as you’d expect it to.