While putting together a live performance case focused on creating percussion patterns, I ran head-first into a problem that has frustrated many Eurorack users: how to make sure all of your modules agree on where the downbeat is.
Some modules offer a handy Reset input, but they may disagree on what it means: When some modules receive a Reset pulse at the same time as a Clock pulse, they treat the current clock as the downbeat. Other modules treat the next clock as the downbeat, ignoring a clock that might have come in at the same time. This disagreement can put these modules out of sync with each other. The video below demonstrates this problem and how I solved it; if you’d like more details about what’s going on and some other ideas I tried, read on below the video.
In my case, I am using an ALM Pamela’s New Workout (PNW) as my master clock, as it allows me to create different divisions or multiplications of a central tempo: For example, I send a 24 ppqn clock to my Mutable Instruments Grids, but 1/16th notes (4 ppqn) to my vpme.de Euclidean Circles v1. I also have it send out a pulse every 8 or 16 beats (2 or 4 measures of 4/4 time) to act as a reset signal, to let modules with a Reset input know where the downbeat is.
The video above deals with solving the differences between Grids and Euclidean Circles v1, which are good representatives of two different ways Eurorack modules interpret reset:
Method 1: When Grids receives a Reset pulse, it looks at the current state of its Clock input. If a clock is currently active (“high”), then it treats the current clock as the downbeat. If there Clock input it “low” (not active), it waits until the next clock, and calls that the downbeat.
Method 2: When Euclidean Circles v1 receives a Reset pulse, it looks for the next “rising edge” (transition from low to high) on its Clock input, and calls that the downbeat. If the clock is already high, it is ignored.
Euclidean Circles v2 has an option to work the same as v1, or the same as Grids: It calls these “edge” and “level” modes, respectively. But I have an ECv1, and a few other modules I have – from the old school analog Doepfer A-154/155 sequencer combo, to the non-DIN-sync clock and reset inputs on the new school digital Five12 Vector Sequencer – work the same as the ECv1.
There are a few ways to deal with these differences, each with their own pros and cons:
Approach 1 (fine in most circumstances): Instead of my reset-every-8-or-16-notes configuration, you can change the “clock division/multiplication” value for an output on Pamela’s New Workout to send a new rising edge signal when you stop it. If you patch this to the Reset input on Grids and EC, they both will then wait for the first clock after you re-start Pamela, and will call that the downbeat. The problem for me is, if I change the clock division one of my modules is being sent while PNM is running, that module will fall out of sync with the others, meaning I have to stop and start again to get them back in sync. This “gotcha” only applies to crazy people like me who might be changing the division during a “song.”
Approach 2 (the well-intentioned mistake): You can program the Reset signal on PNM to be sent slightly early, by altering its Phase parameter. The problem is, Phase is defined in increments of 0-99%, or 100 divisions between clock pulses. At 120 bpm (0.5 seconds per quarter note), and my typical 8 beats between pulses or 4 seconds for a reset signal, a phase adjustment of only 1% is 40 msec – which is very audible (and I’ve recently doubled the number of beats between resets in my system, making the problem even worse). With Grids being clocked at 24ppqn, and EC being clocked normally at 2ppqn, this caused even more headaches when trying to get the two to sync on “the next clock.” So know that you should forget this approach.
Approach 3 (acceptable for some): Instead, we can use PNM’s Phase parameter to delay clocks going to EC by 1% of the 2ppqn signal it is usually sent. At 120 bpm, that’s a clock every 0.25 seconds; 1% of that is 2.5msec – which is a smaller delay than many samplers etc. have. However, there are circumstances where I can hear that delay as smeared attack; at very low tempos, it becomes an obvious flam (double hit). So although this solution will be fine for most people, between my current “downtempo” tendencies (lower BPM) plus OCD/engineer demand that things be tight, it left me personally unsatisfied.
Approach 4 (our winner): I spoke with Vladimir Pantelic of vpme.de and asked him just how much later the clock had to be compared to the reset for EC to recognize it as the “next” clock, and he said it was well under 1 msec. In fact, he had a workaround for Pamela’s Old Workout: The original Pamela would update its outputs one at a time, meaning output 8 would go high later than output 1. He would use output 1 for the reset and output 8 for the clock, and that delay was enough. However, Pamela’s New Workout is designed better, and updates all of the outputs at the same time – so Vlad’s workaround no longer worked.
So…what modules do I have that would delay a signal a tiny bit, so I wouldn’t hear it, but it would still be enough to satisfy EC? Matthew Allum of ALM suggested triggering an envelope generator with an instant attack (as well as decay, with no sustain), and using the envelope output as the delayed clock signal. A typical EG has a minimum attack time of about 1 msec, which should work fine. Also, some gate “delay” modules have only a tiny amount of delay at their shortest setting, and may also work.
What I ended up using was an active logic module, like the 2hp Logic or Intellijel Plog. These have a microprocessor in them, so there will inevitably be some small processing delay from the time they receive a signal to the time they output their answer. In this case, an OR function works fine – and both Logic and Plog delayed the clock enough to make Euclidean Circles (as well as the Doepfer sequencer) synchronize on the current clock when they received a reset signal, without the delay being audible. (Note that a passive OR gate like the one from Intellijel will not work: Since they use diodes, they respond at the speed of electricity, which is not a large enough delay to fool EC or the Doepfer. We need the “fault” of processor delay it fix our problem here.)
If you listen closely to the video above, you will hear that using the Logic module to delay the clock did indeed result in a tighter sound when both drums were supposed to hit at the same time, and it did not vary with tempo. Problem solved!
This post originally appeared on my Patreon Learning Modular channel; that post has additional details about my set-up and other issues I’ve encountered with it. If you like to dig deeper into modular synths, I think that channel is proving to be a good resource (plus a way to access my modular synth online courses); please consider joining – I’d love to have you.
This topic was very useful. The Tiptop CR also resets to pulse two when run from an external clock. Apparently that has been fixed in a firmware revision but it was only after watching this video that I was able to patch a solution
Thankyou
I wrote the CR code and that has never been the case. Your Clock and Reset source sent the Reset after the clock.
Hi, over at the Orthogonal Devices Forum Brian has measured the timing between pulses from PNW on the different outs as well as on the expander with a 100Mhz Oscilloscope. It seems that above info that the pulses are all at the same time on PNW in relation to PW is incorrect. The sequence is only slightly strange: 1 – 5 – 2 – 6 – 3 – 7 – 4 – 8, there is 5microseconds time lag between the pulses. The 24PPQN output on the expander fires 10 microseconds before oiutput 1. I will try above setup now without the logic module but considering the given time-lag. Best regards, Alexander
Thanks for the indepth research – that’s interesting indeed!
I spoke with Vlad at vpme.de about the issue, and he found the timing delay from output 1 to 8 on Pamela’s old Workout was enough for ECv1 to determine it was the “next” clock, but when I tried the same patch idea with PNM, it was not enough of a delay.
In my case, I am sending the dedicated 24ppqn output to external devices (others I am playing with), and setting up channel 1 on PNW to be the 24ppqn clock for Grids.
I’m having issues getting PNW, FLXS 1 and Steppy to sync with each other on the reset. I have put together a video below:
https://www.youtube.com/watch?v=rOC672SDKsA
In this video, I am using a trigger on the first step from FLXS 1 on the cvb output.
Any thoughts? The Steppy seems to hang on the first step and puts the two off by one beat.
I have tried using PNW in the same manner (Sending a clock on one output, a reset on the second every sixteen beats). I have come up with the same issues.
Would the method you have described in your video help solve this issue? Thanks!