Yarns Clock

I’m sending the clock from Yarns into Grids with no problem but when the clock is sent to a Intellijel ustep 2 it sounds as though the ustep is being triggered late. The ustep manual says that “Rising edges trigger the steps”. Can any knowledgeable person comment on what’s going on here? I was thinking about whether to get a Doepfer a165 trigger inverter but I’m a modular newbie so clueless!

“Rising edges trigger the steps” is the normal behaviour. Grids works just like that too - you don’t need an inverter.

When you say “late”, how late is that?

I’m not in front of it now but maybe a 16th note/beat or so. I’ve checked the Swing setting on the ustep and it should be 0

Are you patching in just the CLOCK or also the CLOCK + RESET?

Definitely with the reset but i think also without but i’ll check and report

I have some issues when I use the internal clock of yarns to trig grids.
Yarns out clock div 96
Yarns input clock div 1
Yarns Bars 4
Yarns clock div /1

Yarns trig 3 (clock) to grids clock
Yarns trig 4 (reset) to grids reset
Grids clock set to 24 ppqn
Grids temp control to min (external clock)

I get some double trigs from time to time. The reset signal is out of sync with the clock. It sounds stable when I set yarns tempo to external and use the midi out from my Korg SQ-1 connected to yarns midi in.

I have recorded the clock and reset outputs from Yarns (Temp 52 bpm) to a audio track left and right. You can see that the reset is not align with the clock at all times. (Sorry for the weird file type. The uploader had some limitations…)

In the file you have posted, at what time is the glitch?

the reset close to 1:00:11:13.5 is of, not my much but sometimes it causes a double trig out from grids

This is how it actually sounds:
Grids everything 12 o’clock except tempo and chaos which are on lowest setting. Channel 3 to hihat and channel 1 to self oscillating filter sweep bd.

Ok, I’ll look into this!

I’ve made some more experiments and it seems like it’s the Grids that cause the problem.
The top track is grids reset recorded and the bottom is Yarns reset.
As you can se the first reset out from grids is in sync with yarns, The second pulse (which happens from time to time) is occurring after the yarns reset.

If I disconnect the reset on grids input (but leave clock in) I can see that the reset that grids is outputting always lags a little. But not nearly as much as the second reset in the picture.

From the Grids source code:

// Earlier versions of the firmware retriggered the outputs whenever a
// RESET signal was received. This allowed for nice drill’n’bass effects,
// but made synchronization with another sequencer a bit glitchy (risk of
// double notes at the beginning of a pattern). It was later decided
// to remove this behaviour and make the RESET transparent (just set the
// step index without producing any trigger) - similar to the MIDI START
// message. However, the factory testing script relies on the old behaviour.
// To solve this problem, we reproduce this behaviour the first 5 times the
// module is powered. After the 5th power-on (or settings change) cycle,
// this odd behaviour disappears.
if (pattern_generator.factory_testing() ||
clock.bpm() >= 40 ||
clock.locked()) {


Should it really be OR in the retrigging condition? So if clock is locked it will retrigg?

EDIT This should probably be moved since it’s not related to Yarns…

clock.locked() means that a BPM has been set by tap tempo (and thus that the knob on the panel no longer does anything).

For the external clock to be active:

  • The tempo knob must be set to its minimum position.
  • And of course, the knob must be taken into account, that is to say, tap tempo must be disabled.

So clock.bpm() >= 40 || clock.locked() is true iff the module is clocked by its internal clock.

I understand. Anyway, I build a Grids expansion today so I can use Yarns MIDI-out to sync Grids instead. Works like a charm. The only problem is to find a very short 5-pin DIN cable…