Working Clock Multiplier/Divider/Phase Shifter with tolerance for uneven clocks

This is great!

I followed you on your Youtube too. Nice little box!

2 Likes

Do you think that the arduino could handle three clocks at once (given that there are enough pins :wink: ) ? Or would this be a problem timing-wise? So basically what sam did in his video, but with only a single arduino and a bit more coding…

3 Likes

Hmmmm it’s possible, although the i/o is there, we’re going pretty fast through lots of functions that chew processing time, so I wonder if maybe we might start to miss clock pulses or slide out of time at the higher multiplications/divisions.

It’s worth a try though. I can see if I can have a crack at this after my current contract work, I’m tied up with a hefty programming task for the next 6 weeks or so.

Perhaps if you don’t hear from me after that, prompt me to remind me to check it out - it would be a nice thing to be able to multiply it out for more utility!

3 Likes

Cool! I did look at the code and maybe something like the direcIO library could also help to make setting the pins faster… I will check that out maybe :slight_smile:

I had something like this in mind for my module:

4 Likes

The jacks between the pots will make these awkward to use once a cord is patched in…

3 Likes

Good point! Maybe I put the CV jack there where not delay is and move all pots one step to the left… :thinking:

1 Like

More like this! (still very rough :wink: )

Still need to think if I really want the internal clock (top knob) or rather space things out a bit more… Maybe switch delay and divide knob, or reset and CV jack…
And maybe an on off switch per channel?

3 Likes

My opinion is you don’t need that clock…
Unless this is your only clock source, that is.
But usually you want one “master clock” and sync everything with that.
That clock can go from a MIDI clock, a dedicated clock with stuff like BPM, down to a simple LFO.

And in the unlikely case you want a “second/non-synced” clock, the LFO will do… (sometimes useful for generative patches)

2 Likes

The clock pulses could be read with an interrupt so you’d at least know you’ve seen them all. Maybe the TimeKeeper stuff could go in the interrupt handler too, worth a try. Then handle the controls inputs in the loop. That’s kind of what I do in my sequencer, handle the user interface in the loop and pre-calculate anything the clock handler needs if possible, then do all the clock handling in the interrupt.

Maybe timer interrupts to handle output pulses?

If it’s too slow to handle all the input pulses maybe you can at least recover gracefully if you know a pulse came in but was missed. And yes, you could use DirectIO to speed up the digital reads/writes.

2 Likes

I think people should keep in mind how many pins are capable of hardware interrupts. I think the nano only has two right? (Not that everything needs to be a nano ofc)

Sure, but you can connect one pin to an OR of the clocks and then check individual pins to see which one actually fired.

Edit: Hmm, maybe that doesn’t actually work, if one clock comes on before another has turned off… needs some thought, maybe can’t do it with a Nano after all… unless you shorten all the clock pulses before the OR… ?

1 Like

So far, no interrupts are used in Jesse’s code, right? So maybe it works without when all operations are quick enough. IO operations can be made quicker with directIO e.g., I have not yet looked at the math stuff, but there might also be ways to precompute stuff or use lookup tables instead of doing real calculations etc. :slight_smile: Or maybe a simple timer interrupt would be good, it just checks for new clock pulses at regular intervals and the rest of the calculations would be done ‘in between’… seems complicated but doable, but maybe it would be easier to just use 3 nanos xD

3 Likes

Heya - oh yes there are no interrupts for outputs because we don’t want to schedule anything, everything has been crafted to be constantly reassessed to keep it dynamic, which is why this clock div/multi is different to others, and you can ratchet at any point, rather than only beginning to ratchet when a new clock pulse is received.

This was because there was a need to change on the fly between possibly very long clock input pulses (up to 2 seconds possibly), whilst simultaneously being robust enough to deal with an uneven clock, or even a clock that is changing each beat (could even deal with a clock that is ramping etc).

So yes whilst there could be efficiencies gained in offloading some things to interrupts, they would undo what makes this quirky one different from others and useful in these strange use cases.

And yes directIO could speed up writes/reads, but I think much of the processing time we’re looking at here is dealing with creating, maintaining, and reading the generated waveform so we can dynamically modify it on the fly for clock outputs (at least from memory that’s what we were dealing with, it’s been a little bit).

3 Likes

Oh and just to be clear, this was definitely a collaboration between myself and my great friend Rohan Mitchell so I can’t take all the credit :slight_smile:

2 Likes

I guess the real problem is that if you have one clock and its multiples at presumably not above a few tens of Hz then you have tens of ms or more to handle each incoming tick. But as soon as you have two clocks the time between an incoming tick from one and a tick from the other can be arbitrarily short. So whether interrupts are used or not, the code has to be structured in such a way that time consuming stuff has to be done on a time available basis and actual response to ticks has to be kept very, very short. I still think interrupts on incoming ticks would be the best way to make sure all ticks are seen, but there might not be time to do anything in the interrupt handler but store the clock # and time, to be processed in the loop, and the loop would have to be able to gracefully handle a backlog of ticks. It’s probably a much harder problem than a single clock. A Nano per clock would probably be a lot easier.

2 Likes

Hey, i just built this thing, just buffered the outputs with transistors. Works fine, even on 7-9 V.

10 Likes

Hey this is great! I love it! Nice bright LEDs too

2 Likes

It is also possible to just port this code to another Arduino IDE compatible microcontroller. Unfortunately my other go-to microcontroller that I run most of my home automation and control for things like self-balancing robots etc, the mighty and super cheap ESP8266 in the form of the Wemos D1 mini (and clones) only has a single analogue input.

It’s such a lovely micro that can be easily socketed like the nano, and runs at a whopping 80mhz (compared to the nano’s 16mhz). I usually pick up the clones in bulk for about AU$5 each.

Although it’s possible to extend the analogue inputs on these, you’ll be starting to build quite a fair bit of hardware and then troubleshooting these extensions.

Could be nice to deliver firmware updates over wifi to them though! :slight_smile:

4 Likes

Hi @klausklaerwerk ,
I am planning on trying this module.
But as a newbie I have no experience in designing the buffer.
I have read a bit about it, theoretically.
Would you mind sharing your schematics?
All help appreciated!

1 Like

Would this make sense as an output buffer based on transistors?

Note: The 1K resistor at the end, is the original 100K from Jesse’s circuit (that he preferably changed to 1K).

It is based on this article by synthnerd:

see https://tinyurl.com/2jz9lob8 for a simulation.

Any advice warmly appreciated, still learning here!