16n is a bank of faders [release thread]

I calibrated mine with a Teletype but in the 16-n-faderbank.github.io/editor/ app in Edit Configuration/Device Options there is a setting you can work with. In that window there is the following: “Bearing in mind there is a small dead zone at either end of a fader”

1 Like

So, mechanically, there’s a dead zone on the fader at either end. It’s particularly noticeable if you’re looking for it. That’s not meant as trolling, it’s just true: once you know it’s there, you’ll see it a lot. It’s not a problem with the 16n; it’s just how the slide pot works.

However, the deadzone at the top might be exacerbated by the firmware, and this is where the ‘calibration’ process available in the firmware editor (assuming you’re on firmware 2+) will help you fettle it.

But what you’re running into is actually part of the design of the fader, I think, rather than the design of the 16n.


Thanks that’s very helpful!

I’ve got an ER-301 and a TELEXb, and I just picked up a second 16n.

Does anybody know if it’s possible to use both 16n’s simultaneously to control my ER-301via the TELEXb, and if so are there any considerations that I should be aware of?

not without firmware modification at at least one end. they’ll just conflict and not work. one 16n per I2C bus is how it’s all set up.

1 Like

If you do have a Teletype or crow, perhaps this post might help.

If you have a crow and a norns, you could connect the ER-301 to crow, connect crow to norns, and connect both 16n faderbanks via USB MIDI to norns and use a modified version of this script/library to collect the MIDI CC data from both 16n faderbanks in norns, send these over to crow, and have crow send them out via i2c to ER-301.

I have not tested any of the above, as I still only have one 16n (a Sweet Sixteen, to be precise) to control my ER-301.

1 Like

Updated to the latest firmware earlier today and everything seemed to go off without a hitch — my 16n interfaces perfectly with the software.

However, the orange LED next to the reset button is lit constantly now, where it was never lit before. Is this anything to be concerned about?

For context: I’m using a MSW-built unit, which has an LC.

This is fine. I believe that there is a toggle in the config to change that behavior if you prefer.

1 Like

Hello all. I recently built a 16n and am having an interesting problem. The faders work if all of them are around 50% and above, but if one of them goes below this threshold, it immediately goes up to 127 and all of the other faders move up as well. I looked on this thread and it seems like other people have had similar problems, but as far as my eye can see, everything has been soldered pretty well. Not really sure what I have done wrong, would love some help!

Video: https://photos.google.com/photo/AF1QipMTjpkdXrMoeIGj1jeTIfHL69RVajA4eVIr72Hq
Photos: https://photos.google.com/photo/AF1QipMPPdvD_CJdDTnOBgiU1amk00XTi6EcSXMlmwGf

Yep, the default on a new unit is “power light on”. On the options tab in the config software you can alter this - both whether or not it should be on, and whether it should flicker on midi data.

1 Like

I’ve upgraded to 2.01 but I can’t access the editor in Chrome (83) on Mac OS Catalina

Midi Monitor recognizes the device but this web app does not. I’ve tried to disconnect, reconnect again, reload the page.

This test page works https://16n-faderbank.github.io/16ntest.html but not the editor.

Is there another way to configure the device ?


well, you could configure the device by sending sysex manually, but I wouldn’t recommend it.

it’s strange that the old testpage works.

Can you direct message me with a screengrab of the web inspector console from the editor page - command+option+i will open the window, click “Console” at the top?

You could also use the Opera browser, which supports webmidi, but it’s somewhat smelly that this isn’t working at all.

1 Like

Yes I can send you a screenshot, I inspected the console earlier, but it wasn’t showing anything, no verbose, no errors. I’ll try again. The previous firmware was a very old one. On my second 16n, it’s worse, it behaves erratically (it lags and then sends bursts of midi messages, not sure if it’s hardware or software related) and is not recognized either. I’m gonna do more tests and I will PM you with all the details

OK. I’ll do my best to investigate, but I’m a bit time-limited at the minute. Can you let me know how you’re connecting the 16n. Also, is it running a Teensy LC, or a Teensy board in it, and is it a board with screws in a “cross” pattern, or just three screws down either side of the board? The latter are very, very rare - I think < 10 people have them - but worth checking. (Those are “1.25” hardware.)

1 Like

Thanks. I’ll investigate too, no worries.
It’s not a 1.25 board. I had these board made in January 2019 just after the files were publicly released, it’s a 1.3x I believe. It uses a Teensy 3.2. I used the corresponding 16n_v201.hex (not the LC one). And I’m connecting the 16n with USB (from the micro USB port to a Mac using a USB-C adaptor to be precise).

I’ve just checked the Console on Chrome again, it’s empty, it shows no messages at all. Same thing with Opera.

Perhaps I should try to re-compile the firmware with Teensyduino ?

By the way is it the normal that the LED of the Teensy blinks when I’m moving a fader ? (Edit: Yes it’s normal, I’ve just seen this option on the config page ; )) )

Edit (solved):

  • :white_check_mark: I’ve just cloned the repo again and re-compiled using Teensyduino, this time it’s working :wink: Chrome instantly recognizes the device.

  • :x: For the test, I’ve re-uploaded the 16n_v201.hex just after, and this time the Faderbank is not recognized anymore by Chrome or Opera but it’s still sending Midi CC (according to Midi monitor).

  • :white_check_mark: Back to normal when I recompile and upload with Teensyduino.

that is weeeeeeeird.

the hexfile should work for everybody (and has been doing elsewhere).

So - yes, the new default is “LED On”, “LED flashes on MIDI data”. You can alter that in the third tab of the editor’s edit view. It’s a good way of knowing the new fimrware is on there.

The only debug thought I had was: the old editor just looks for a MIDI device and receives MIDI data from it, which is why the old editor Just Worked. The new editor does a little Sysex handshake to confirm it’s talking to a 16n, rather than any old midi device. And it looks like because that handshake wasn’t working, nothing else would work regardless. Highly strange.

I think for now I’d like to just note you had an issue, and managed to solve it, and return to it if it emerges again… because it sounds like you have something working?

Do check that the editor will let you customise faders/options - that indicates the sysex transfer is working.

1 Like

Thanks. Yes, absolutely, now it’s working 100%, I can access the config page, (it’s great to have this web interface by the way, thanks). I was able to re-assign the CC numbers, disable the LED etc.

For the second 16n, the one behaving erratically, I’m just going to reflow the Teensy, it was stored on a shelf for months, it’s not supposed to be damaged but it’s probably an hardware issue, a cold joint or something :wink:

Has anyone ordered the aluminum top and bottom panels from Front Panel Express recently? Am I good to simply open the files in FPD and order from there?

Im going away for some time and today i plugged my 16n (berlin Modular Version) and updated it with the latest firmware on the github.

When i connect it to teletype via i2c, and do fader x etc… my teletype read values from 0 to -32767, if the fader is in the middle it reads 9559

How can i adjust this range?


Please consult the Teletype manual and look for the FADER.CAL.MAX and FADER.CAL.MIN instructions.