WIP: step repeat sequencer

Hi, I am currently planning on making a step repeat sequencer similar to the Ryk m 185 or the Metropolis

Now I need some help with various things, firstly the panel design. Since 8 pole slide switches are hard to get, I planned on using rotary switches instead. My first design is close to the Metropolis:

(note: this will be a 20 by 20 cm Kosmo module)

But the problem here is, that the rotary switches are very close and it will probably be hard to operate (as shown in the Cheap Component Search - #146 by sebastian thread:

So, my current iteration looks like this:

next to the 7 segment displays is a rotary encoder and the two potentiometers on the bottom (between the jacks will be gate length and portamento. I was thinking about moving the display and buttons to the top… and maybe I need another line of buttons for each step in order to mute certain steps…

What do you think?


Make it wider than 20cm !

How do you plan on labelling the gate “rythm patterns” switches ?
It looks hards with rotary switches while easy with the linear one…


Good point with the labels, I have not yet thought about that! Maybe something similar to the Metropolis labeling could fit if arranged in a circle…? Or I just make different numbers /shapes of points and then I need to remember or put a legend somewhere xD
Making it wider: I thought about this, but pcb’s get expensive quickly! But maybe I could go with a separate 10cm panel for display, buttons and jack sockets?

1 Like

I feel you!. I’m slowly researching how to put together something similar to Metropolis.
I found couple of them on Alibaba, but minimum order is 1000 peaces. I will probably try to get sample order from them when the time comes. I’m sure i will manage as i have Alibaba account with some history for work purposes. So try to get samples and see how that goes.

Took the words out of my mouth.


With careful optimisation you should be able to put it onto multiple boards. One thing I like about modular design principles is that they give you a chance to build the piece up as a collection of subassemblies. Amplifier here, mixer there and so on. Plus it makes it easier to test parts of your build independently.

1 Like

Now that you formulate it like this it sounds really good! This way I could make the large panel mostly the “Interface” or “control” already with shift registers and stuff, which either has its own microcontroller and communicates with i2c (or similar) to the “brain board”, which does the quantization, generation of CV etc. Maybe I do not need 2 microcontrollers and just connect the boards via SPI is enough, but I will think about this! This really helps channeling thoughts! Thank you all!

1 Like

And… Tadah…
I may be possible to make the “brain” board work with one or two “control” boards to get 8 or 16 steps…


Might still move the pots for gate time and portamento from the control board to the brain board, but maybe not…
At least finding motivation again and doing some progress! :slight_smile:


Too much complexity!! :fearful: I can not fit all the stuff onto the brain pcb, I might need to make it a sandwitch!
Currently I am planning to add a second nano to the control board and then communicate via I2C, but I am not sure if that is better than just using SPI and a single cpu… the advantage of a second nano are: a bit more pins available, a little easier to test, maybe more modular? I am not too concerned about additional delay when moving the sliders etc., but maybe I2C needs so much time that I will have trouble reading the encoder? No idea… need to test this, but it’s hard without the hardware and putting all of this on a breadboard will be difficult! But probably I can only connect a single shift register / mux of each type and write the code for all and then see about timing…?


Rather than a second Nano, it may be worth looking at something like the Mega2560 Pro Mini, which is a small form factor, third party copy of the Arduino Mega2560 in much the same way that the Nano physically scales down the power of the Uno. You get a lot more pins and there are humongous tracts of Flash storage as well as a very decent (for a hybrid Harvard architecture chip) 8KB of onboard static RAM.


And as you might guess, the synchronous protocol SPI is blindingly fast compared to I2C. It’s much better suited to transferring large amounts of data quickly. You can even use SPI to add more memory to an Arduino. I2C is fine for monitoring sensors and sending comparatively slow data to LCD controllers. Your main concern running SPI may be keeping the transfer rate low enough to avoid noise.


I’d put a second Nano on the control board.
That will make everything much simpler.
You just have to send changes to controls from control board to brain board, just like midi does with CC’s, and for that even the serial port is fast enough (at the very reliable 115200baud it can transfer about 10KB/s, at 5 bytes/msg (start/board#/control#/newvalue/checksum) thats 2K msgs/sec…)
And you’ll be able to use two control boards to get 16 steps, with minimal control of who talks on the serial “bus” (a single line pulled low by the talker just like I2C does, checking it’s state before doing this).

For the brain board, you’ll have no other choice than a sandwich, those PCB mounted jacks are HUGE (as you designed it, none of the pots/tact-switches will reach the front panel), and need to be mounted on a second board anyway. So make it the whole module size, put most electronic stuff on it, and add an electro-mechanical board with the pots/switches and maybe some “conditioning” electronic like the LED drivers.

Some afterthoughts…
newvalue needs obviously to be 2 bytes because of analog values for the pots.
Messages will be 6 bytes, max rate 1.6Kmsg/sec, still faster than any human can manipulate the controls :slight_smile:
I2C doesn’t exactly have a line reserved for bus contention, it uses the clk line for this.

At boot-up, you need to transfer ALL controls values.
Better yet, you can just send them regularly. No special boot-up code to write, maintain, and waste code memory for.
I can see 34 controls on your control board (and thats a whole byte for each tact-switch, not a byte for all eight at once…). Sending one every 10ms gives you an approx 3Hz garantied refresh rate, with the controls you detect having changed being sent as soon as they happen in between the regular scan.

1 Like

The Mega Pro MINI looks interesting, but I would like to keep things simple also in terms of parts and I already have these weird sliders and rotary switches which are not very easy/ cheap to find :wink:
Yeah, I think the data that I need to send from the control board will be very little, you will probably only change one fader/switch/pot at a time anyway, so there is a lot of headroom!
@eric Would there be an advantage of using serial communication instead of I2C or is that just an example?
You are right about the PCB jacks, but this is just for me to think about the spacing, I planned to make a separate pcb for them. But your idea of making a (full-sized) board where I can put all this stuff is a lot better!


Serial vs I2C is just an example.
I’ve never used a Nano (or any MCU for that matter) as I2C slave, I don’t know how well that works (or even if the atmega and/or arduino library handles it at all).
Start with two Nanos on a breadboard and test this before going any further…

I’d say, with two hands like most humans, you’ll be limited to two controls at most :slight_smile:
OK, some people may move several faders at once with their fingers or the palm of their hand… but if you want fine control…


Looks like this now! So, with two panels this will be 5 PCBs for this, definitely not a cheap project!
Some more questions:


I was wondering how to drive the LEDs, there are 8 in the faders, 8 additional ones that I put on top of the faders and then 4 seven segment LED displays. They are all connected to their 74HC595 shift registers and so far each LED has its own resistor. I know, that the 74HC595 can deliver up to ~75mA, so I need to run each LED with only ~8mA instead of the usual 20mA, right? In the Kassutronics quantizer he uses very high values of 2.2k for each LED and connects the cathodes to the shift registers. I don’t really understand why…
I do not want to use multiplexing, because I read that this leads to noise on the power supply / CV circuit. Is there a difference if I use common cathode or common anode wiring (or choosing in case of 7segment)? Something like the shift registers are better at sinking current than supplying?

CV out

For CV out I see basically 3 option:

  1. use MCP4822 like the Super Sixteen sequencer (he does the V/oct tuning in software somehow…)
  2. use MCP4922 like @analogoutput uses in his dac/ino board, this requires a reference voltage as well but then can instantly be used for 0 to 5V.
  3. Go with PWM like Kassutronics, which has higher linearity, but also needs an extra regulator and a filter to smooth the PWM signal. He writes that the software is easier, because you only need to write to a register, but it uses advanced arduino timing stuff, which I am not so familiar with.

I need to investigate this a little more, I think, but currently the MCP4822 looks like the easiest solution to me…

Software design

My “blueprints” for this project are the super sixteen sequencer and the Kassutronics quantizer and they have very different approaches in their arduino programming: Kassutronics looks very advanced with using timer interrupts for a lot of stuff and directly writing to pin registers. In the super sixteen sequencer I recognize a lot more easily and seems more beginner friendly (it pulls the encoder simply from the main arduino loop, for example). But I really like the approach of Kassutronics with the timers for different tasks, like running the UI scanning code at a fixed 1000Hz, to make sure that the UI reacts as you would expect while making sure that the CV outputs are always updated when needed (like at a high frequency). I like that you set your “requirements” and then make sure that the code that is doing it runs fast enough… but maybe someone with more experience can comment on this?


For the CV, do you want only semitones in your output or a (sort of) continuous pitch range? If the latter then PWM may not give you enough resolution, at least if you do it the straightforward way. My understanding is it’s possible to get better than 10 bit resolution with PWM but I’ve never found a good explanation of how to do it.


That makes a lot of sense. I’ve had a lot of time to think about my build (the one with up to 64 rotary encoders) and it seems the weak point is the reliance on a massively centralised digitisation scheme. I can probably do a better job with one processor per bank (or even two, subject to the electrical limitations of SPI). The bank controllers can summarise the changes and communicate them to a central brain. Microcontrollers are inexpensive compared to a lot of the other hardware I’m using because of the number of chips involved.


Any updates on this? Google bought me here when I was searching for something else but I’m very interested in a sequencer like this, there’s been a fair few people start a metropolis clone and they all seem to have lost momentum, hopefully this isn’t another…