Starting Sync

I’m not sure where to put this comment. The last time I put something in the Development forum Andrew moved it somewhere else, so I’ll just toss it in here.

I’m hoping module developers will sit down together at a big Zoom conference table or something and work out how to handle the start, clock, and reset commands in their sequencing modules so that everybody is doing it identically and has it nailed down. There’s an unfortunate lack of uniformity in this area.

Right now I’m attempting to use bidoo zOu MAi and Valley uGraph to do a nice normal 4/4 groove. Neither of these modules starts reliably! Once they’re running, they’re fine, but neither the Run button in Impromptu Clocked nor an external Run button will start them running reliably with the same conception of where the beat is.

When I send a 1x clock signal from Clocked to a Trummor, producing a reliable 4-on-the-floor kick that begins immediately when I hit the Run button, sometimes uGraph (at a 4x setting running from a Clocked 4x output) is in sync with the kick, but other times it’s one sixteenth-note late. The issues with zOu MAi are more complex, so I’m not going to try to describe them here.

I’m pretty sure these are not the only two sequencing devices that sometimes get confused when they’re asked to start playback. I feel strongly that this is an area where VCV lags behind other music production systems. Once a VCV patch is running, all is well – but starting on beat 1 of bar 1 is very much a hit-or-miss activity.

–Jim Aikin

The forum interface doesn’t seem to allow me to embed a video illustrating what I’m seeing, so I’ll just toss it over onto the Facebook group.

Perhaps in your case it’s just a question of geting the settings right in Clocked, since there are a lot of possible tweaks in the module’s menu.

Another thing to point out, perhaps to devs that are not aware, is that there is a Rack standard for modules with a Clock and Reset input to ignore the clock during the first millisecond after a reset, and this helps alleviate some of these types of issues.

I personally always like to us run cables when sequencers have a run input, and I have attempted to outline my Impromptu Modular method here, for anyone wanting to know more.

There is also the related and now infamous discussion here also, which I’m citing for reference only, but it’s probably overkill to read it:

As far as getting all the devs together to make a global standard, I would definitely participate, but unfortunately I don’t have the energy to spearhead this type of initiative.


The Rack development guide contains the following. My question is (I’m trying to understand Rack’s internals to do some module development): if developers followed this, would it alleviate the problem being discussed here?


Each cable in Rack induces a 1-sample delay of its carried signal from the output port to the input port. This means that it is not guaranteed that two signals generated simultaneously will arrive at their destinations at the same time if the number of cables in each signal’s chain is different. For example, a pulse sent through a utility module and then to a sequencer’s CLOCK input will arrive one sample later than the same pulse sent directly to the sequencer’s RESET input. This will cause the sequencer to reset to step 1, and one sample later, advance to step 2, which is undesired behavior.

Therefore, modules with a CLOCK and RESET input, or similar variants, should ignore CLOCK triggers up to 1ms after receiving a RESET trigger. You can use dsp::Timer for keeping track of time.

I haven’t looked deeply into the specific problem reported above, but anytime you press reset on a clock and some sequencers are connected to the clock with a reset cable also, it may happen that they see the new clock pulse that happens simultaneously as the clock is being reset (or a few samples after). This clock pulse can potentially be seen as a true clock edge, and thus the sequencers advance their step immediately, which results in the first step being missed (or played for a few samples only). So this was the reasoning behind the development of that Rack standard.

1 Like

It’s definitely possible to embed videos here in general. Would you please share the URL of the video you were trying to embed so that I verify admin-side?

(what’s not possibile is to upload video to the forum, but you know how to deal with that)

Anyone having problems about this, please make sure having read the existing discussions about it. The more they are, the harder it gets to figure things out, so please don’t open new topics but reply to the existing ones.

(suggestions about which topics should be merged would be welcome)