16n is a bank of faders [release thread]

Question: I got a 16n from Michigan Synth Works a few months ago - Everytime i use it to control midi, there is a lag between fader movement and result on screen. CV works fine - haven’t tried i2C yet. Anyone else have this problem?

It is technically functional, but with it not being very responsive it makes it difficult to use the midi portion in a musical manner.

“on screen” in what, specifically? do you have any other MIDI programs running in the background?

I would recommend speaking to your builder if you did not build it yourself. It should be very, very responsive.

Ableton mostly. I’ve tried controlling Norns as well and it has the same issue. I sent Michigan Synth Works a message so i guess we’ll see. I had them flash it to be i2C master so maybe that was part of the problem? Either way, the lag i experience currently is at least a full second from when i move the faders.

I2C Master shouldn’t effect the midi performance at all. And I don’t know what version of the firrmware MSW will have put on. I suggest you speak to them about this. That lag is absolutely not normal, I can supply a build of the latest official firmware that you can use Teensy Loader to put on the board without needing to compile it, to see if it’s a firmware issue, but you should speak to MSW first.

1 Like

Lasercut panel (faders missing). Nice and scratchable :slight_smile:


Hi all; you might be interested in the 2.0.0 firmware for 16n, which has its own thread now. Linking it here for those of you that will get an alert by me doing so…


This looks like such a nice thing to pair with the Er-301 which I am looking to buy.
The only thing is I really really don’t like the little usb port for powering it.
Would the best/easiest thing just be to put it in a bigger enclosure and have an internal adapter with usb b out?

in short, yes. The micro-USB port that powers it is there because it’s the one on the Teensy, and it’s used for data transfer as well as power.

At least one 16n-derivative design adds a mini-B USB jack to the mainboard itself, primarily for added physical integrity - the Teensy jack is not the most solid part.

Of course, the product is entirely open source, and you’re welcome to adjust the circuitboard to your own needs; there might be space to add a full-size B jack and reroute to connect to it.

I just build the 16n (berlin version 1.4)
I have a few issues

  1. It doesn’t turn on in my eurorack.
  2. it turns on via usb (computer) but it reaches like 1.5 or 2 Volts (max)
    Anybody have an idea what could be wrong?

@infovore: I just recently discovered the 16n in form of the Tesseract Sweet Sixteen faderbank, and I really like how it made my ER-301 “touchable” when connected via i2c.

The only downside: It doesn’t have enough faders. 16 are a lot, but 32 would be better.

Please, is there any way to “chain” two 16n or Sweet Sixteen, so that they appear on the i2c bus as one device with 32 faders?

1 Like

The Berlin Modular version is a derivative, so perhaps their Github pages for it are the best place to ask for support? I know it moves a few things around, and adds a filtering cap on the 5V line (I should have done that). But I don’t know the full details of what’s changed, so can’t quite support it. For instance:

It doesn’t turn on in my eurorack

That’s a Berlin-Modular specific issue, because vanilla 16n has no Eurorack connector.

The whole thing does smell like you’ve got a short circuit somewhere, likely in the power section, but without images of your soldering it’s hard to tell, and like I said, that’s not a product I designed.

It doesn’t have enough faders.

in your opinion, a crucial distinction!

Please, is there any way to “chain” two 16n or Sweet Sixteen, so that they appear on the i2c bus as one device with 32 faders?

No, sorry.

But: both 16n and @M4ngu’s Sweet 16 are open-source, from firmware through to hardware, so perhaps you could investigate what it might take to do that? If you’re asking me to do it, it’s not a feature I have a huge amount of interest in.

I know I regularly write “it’s open source, why don’t you try?” on lots of these posts. I’m not doing that to be passive-aggressive. I’m doing that because that’s exactly one of the advantages of making open-source projects: people can investigate modifications that are really valuable to them, even if the original maker doesn’t care. Some of them make things like the Sweet 16 or Berlin Modular version that other people prefer.

And: I’m not a trained EE. Everything I learned about electronics, I learned from open-source designs and other resources; Tom Whitwell and Émilie Gillet are largely responsible for my electronics skills. (Hell, everything I learned about code I learned through open-source products, tools and languages!). I know many people will bounce off that suggestion, but some of them stick it out and end up with new skills, or something unique that they’ve made, or something other people will like.

OS isn’t just a neat way of getting PCBs and building things cheaply, it’s a way of joining in, making what you want, and sharing. And that’s why I’m going to keep writing “it’s open-source, have you considered trying to make those modifications yourself” every time there’s a feature request I don’t think is critical for the OG 16n.

(FWIW, I think building a Sweet-32, rather than chaining two, might be an easier approach, but that’s just me. It also means you can’t, say, have two banks of 16 at different locations in a rack, but that appear as one 32-fader device.)


Thanks for your response,
I understand what you’re saying,
I try to contact them, and see what’s going on :wink:

sure - if you solve it, do let us know here. And you can always share a board-picture here, I just can’t guarantee it will be solvable here. Other people here might be able to help, too!

Thanks @infovore for taking the time to answer me. I did not take it as “passive-aggressive”. Please let me explain why I asked instead of making it myself – and I hope that this also does not appear as passive-aggressive.

While I do see your point regarding the benefits of Open Source beyond “building things cheaply”, I did not go for an OS device because it allows me to save money. I bought the Sweet Sixteen fully assembled and gladly paid for it, because I still fail at proper soldering (I really tried several times), and buying an assembled instrument saves me time.

My goal is to get lost in making music, and with the limited time left at the end of each day I have to decide whether I want to make music or learn new skills to become even more of an instrument builder than I already became when falling in love with modular electronic instruments over 35 years ago (Hm. Was that a mistake? Should I have stuck with learning the piano back then? :wink: )

Anyway, after reading this I assume that in order to create a Sweet-32 out of 2 Sweet-16 I’d need to connect the two 16-channel multiplexers to one Teensy. The S0 pins of both 16-channel multiplexers could be connected to Teensy pin 5, the S1 pins to pin 6, S2 pins to 7, and S3 pins to 8, so that the Teensy switches both multiplexers simultaneously. The analogue out of the first multiplexer is connected to Teensy pin 14, so I assume the analogue out of the second multiplexer needs to be connected to Teensy pin 16. Then I’d need to change the Teensy firmware so that it alternates between reading the analog input pins 14 and 16, and the alteration happens after having completed switching thru all 16 position of S0, S1, S2 and S3.

But putting this theory (which might or might not work) into a new circuit board holding the Teensy, and which connects to the 2 Teensy slots of the 2 Sweet-16, is beyond me. Or, to be more precise: Playing with what I have is more important for me at this point.

In any case, thank you for all the work you put into the 16n, without it I would not have so much joy using the ER-301! And without your answer I would not have put in the time to try to find out how 2 multiplexers might be “merged” in theory – thank you for that as well! :slight_smile:

It is possible to connect two faderbank-style devices to the ER-301 using a monome crow or Teletype. You would simply leave them in follower mode and run a script on your monome device which polls all 32 values then forwards them to the ER-301. It is quite stable on the Teletype but the relevant crow firmware is still in beta.

Alternatively you could use a crow script like my Phage script which addresses multiple ER-301 SC.CV ports per fader. This approach can be good if you’re trying to save space.


similar idea but without crow/teletype: could have one running in follower mode and run the 2nd one with a modded firmware that would poll the first one.

1 Like

Thank you for your ideas!

Taking the crow idea further, I guess I could connect crow to ER-301 via i2c, and norns to crow via USB, and my Sweet Sixteen and Faderfox PC-44 faderboxes via MIDI to norns, and have norns merge & convert their MIDI CC messages to i2c SC.CV messages.

The other way inspired by your Phages script is to realize the “i2c control surface page switcher” functionality right inside the ER-301. I will try this today and if successfull, I will open a separate thread to report.

Thank you, but alas, as I am still only doing baby steps in Lua, modding a firmware accordingly is beyond my capabilities.

I ran out of CPU trying to build soft pickup page switching in the ER-301. Probably because everything runs at audio rate and I was using a load of units. ER-301 badly needs an option for slower control rate units IMHO.

I have to admit that I gave up today when I found out that just switching between 2 track&holds for each fader isn’t enough. I will need to learn crow and give Phages a try!