Grids clock choice

One thing i have never been able to understand fully is why all mutable modules have this amazing pattern sync mechanism except for grids.
I do love my grids and with expert sleepers providing 24ppq is a breezy but i do wish i could clock it from the jittered clock of my marbles.
My question is simply why this type of clocking was chosen over the maybe more “modular” tap clock?

A combination of 2 things:

  • When I developed Grids (among the first 8 other modules), I was still in a very “MIDI-controlled desktop synth” mindset; so I assumed Grids would be driven from a 24ppqn clock from a MIDI interface, or at least a sixteenth note clock from another module. As a consequence, the module is designed in such a way that it can’t do anything between clock ticks.
  • I had the “break-through” about what seems to me the “right” way of doing clock multiplication/division/jitter (used in Marbles, Stages and upcoming modules - a technique I call “ramp extraction”) in summer 2015. This is harder to implement on less powerful MCUs.

fair enough, that makes a lot of sense.
Would a time mechanism as used in e.g. Peaks or tides be possible to implement into grids for a medium level programmer or is the hardware too efficiently used already?

Id be thrilled to learn morw about that ramp extraction.
The way i imagine it there are generally two ways:

  1. sequencer type clocking (like grids) meaning one pulse = one unit forward
  2. tap clock meaning averaging between incoming pulses either for the first two or continuously

Most of your modules seem to do something like the tap clock but listening for patterns in the clock over a specified time period.

How does ramp extraction compare to that?

Like having a much higher frequency internal clock (than the user is aware of) running a counter so you can measure the phase error at every instant an input clock edge comes in?

Reminds me of some of the techniques used in modern frequency counters :slight_smile:

Not really. This is more or less equivalent to having an infinite frequency internal clock.

I wouldn’t enjoy coding this on an 8-bitter. I wouldn’t even enjoy coding this without FPU!

See a description from Olivier at message 41 on the Marbles thread, around 8 April. He outlines this ramp technique of his, which is fascinating.

1 Like

here’s a link for posterity ^^


Oh sweet thanks for finding that!

I just got my Grids and since I don’t have any module that outputs 24ppqn I’m using it at 4ppqn and it lead me to think that maybe I could reprogram the module to accept 1ppqn. Not being really familiar with embedded programming this might be completely wrong but this is what I am thinking to implement:

  • copy how tap tempo counts between taps to get the interval between two clock inputs
  • use that time to tell the internal clock how to generate 24 pulses, starting immediately
  • wait for the next clock input (but should come at the 25th pulse)

Would it make sense? How bad would it be?

Would work well if your input clock is stable!

1 Like

Thanks for the quick reply.

In that case I’ll give it a go and will update when/if I make it work!

Hi, I love my grid module but I have hard time syncing it with other modules : a clock divider is clearly missing ( like clock implementation on Marbles), of course I can always use clock dividers on input and output but would save some space and focus to put it right on the module. Is that a hardware limit or can I find a software solution via an alt firmware ?

Both, in the sense that Grids uses an archaic CPU, without the resources to run something as detailed as Marbles’ clock input implementation.