16n is a bank of faders [release thread] [current version:1.33]


The TT is talking fine with the TXo and TXi that is on the same chain.


I’ve also tried only having the TT on the TXb and tried reversing the i2c cable to see if that might spring things to life.


Are you using a stereo Trs cable?


No…should I be for 20 characters?


@unity2k Yes, absolutely :slight_smile: “I2C: monome-style I2C protocol over TRS (tip is SDA, ring is SCL)” and the sleeve is the ground


@unity2k wrote (in an email exchange):

It was easy enough to get signal to the ER-301 when the 16n was in Master mode, but checking what documentation there is I cannot find how to route the i2c signal to the ER-301 now??

I moved the conversation here as this might help other folks as well.

There are two ways to compile the firmware for the 16n.

  • With the MASTER compile switch on (should change that to leader), the 16n broadcasts i2c messages to the ER-301, TXo, and Ansible simultaneously. This makes it easy to put the devices on a powered i2c bus together and send signals. The TXo and Ansible connections support up to four of those devices on the bus with the 16n to utilize all of the sliders. You don’t want a Teletype on the bus in this mode as the multiple-leader scenario can cause problems.

  • With the aforementioned compile switch off, the 16n is a follower and will respond to inquiries from the Teletype using the FB n command as documented in the Teletype Manual.

There are also amazing things being done by @scanner_darkly in his alternate trilogy firmware that I’ve seen on Instagram, but I’ll let him add details for that if he wants.

Ok - to your question above - how to use the Teletype to pass signals from the 16n to the ER-301? Here is one way:

Create a metronome script that polls the 16n and passes them to the ER-301 and a couple of TXo. Let’s pass the first 8 sliders to the ER-301 and the second 8 to the TXo.

L 1 8: SC.CV I FB I
L 9 16: TO.CV - I 8 FB I

Set that metronome nice and fast (M 10 or even faster with the M! operator) and activate it (M.ACT 1) and you will be off to the races!

Another tip: a bit of slew on the outputs will help hide lower metronome rates. :slight_smile:


Tracked down the issue. Bad teensy. Now its twice that its happened, replaced with a different teensy, works fine. OSHpark ones…


All Teensy come from Paul’s factory and are rigorously tested - OSH doesn’t make the purple Teensy. They are literally the same as all other Teensy.

Unfortunately, I’ve struggled with a few too (to be fair - only a small number out of literally hundreds and hundreds of them). The ones that were problematic had pin connectivity issues after soldering. Could be the precision headers that I use…

I feel as if the vias that the pins go through are not fully connected to the Teensy PCB. A little lateral pressure and I have seen connectivity restored. So weird.


yeah, I’ve never seen a bad one before. Now I have two that do this, not sure what to make of it. I’m using good headers (Samtec), I’ll investigate some more.

And what blows my mind is that 1.31 works fine but the compiled 1.32s both lose a channel (albeit a different one in each case)


That makes absolutely no sense. The kind of thing that if I still had a reasonable amount of hair, I would pull some out.

Been doing that for too many years, unfortunately, and had to stop. :wink:


So the biggest change I can see in the recent code is the addition of midiReadTimer.

It’d be interesting to try commenting that out on one of your problem teensy’s and see if that changes anything.

Could this be some weird interrupt edge case?


This might also be related to an issue reported elsewhere. But again, I had trouble reproducing the issue earlier in the week.

I have space tomorrow to look into this.


Completed unit with anodized natural aluminium panels from Scheiffer and Verbos-inspired cap colourway


twenty characters of lovely!


You’d need a bad one to try with, it works fine most of the time but I now have 2/20 that dont


well - I can firstly see what’s going on with this interrupt, and if I don’t need it, or can tidy it up, I can send you a new build to prod.


Works for me. First of the “bad” ones it was ch3 (3rd from the left) the second one was ch4 if thats any help


OK, I’ve had a quick look at the firmware to see if anything could be funky there. The obvious thing I can think of is that writeMidi is just trying to do too much in the context of an interrupt; interrupt functions should be fast, but that’s doing a bunch of midi writing and possibly a bunch of i2c writing as well.

My initial proposal is to rewrite that so that the interrupts are just setting a flag, and the MIDI functions run outside the context of interrupts if that flag is true. I’ll see if I can get a branch with this code in done tomorrow am.


Does anyone have a compiled 1.32 firmware with the Invert flag enabled that I could download? Would be much appreciated :slight_smile: