Strange, the behavior you are describing is something I ran into on an LC board before @infovore posted the 2.0.1 update.

oscilloscope shows a healthy 0-5v on the fader and now max can see it, though the editor can’t. i can live with that. thanks for your help!

This is really strange.

“Reverting to 1.34” = the 1.34 firmware from the MSW site?

This is hard to diagnose for me: I don’t have an MSW-manufactured 16n, just OG ones I built myself. I’ve tested this firmware with other users of MSW 134LC boards, too, and haven’t been able to reproduce that.

If Max “can see it” - you mean over USB-MIDI? If so, what channel/cc combination is fader 1 spitting out - and then, in the editor, is that what the editor is expecting? If there’s a discrepancy, you could user the editor to alter the channel of fader 1, zap the new config over, and then reset it to whatever you want. There could have been an issue with the new firmware setting its “factory defaults”. Seems unlikely, but “not moving a box in the editor” vs “not actually sending any data” are not the same issue, and I’m trying to work out which you mean, given Max has got some data somehow. It could, after all, be a bug in the editor.

1 Like

yes, the 1.34 linked on the MSW site. i also used the 2.0.1 firmware from both the github and the MSW site. currently running the github-downloaded 2.0.1 LC-specific firmware.

max “sees” it over USB-MIDI, a midiin -> midiparse -> message reports “[cc] [value],” and is (i just checked) responsive to changing the cc in the editor. this is different from the initial behavior i observed, where max didn’t seem to be receiving anything. this may have been user error as that aspect is working perfectly now.

“not moving a box in the editor” appears to be the issue as everything seems to be working as expected in max at this point.

Ok. What channel/cc combination does Max report for the fader that doesn’t work in the editor?

i tried 1/32, 1/48, 1/75 and the same on channel 2, to no avail last night.

now (meaning when i tried it 30 seconds ago), of course, everything is working perfectly, editor included. i am confused but pleased.

Ah, to be extra sure, what browser are you using? Does it support web midi? And have you given it web midi permissions?

1 Like

chrome on osx, it’s been fine with web midi in the past.

if it starts acting up again i’ll document more thoroughly but for now all is well. thank you!

yeah, it wouldn’t even show anything if you didn’t have WebMIDI. (The very first thing the editor checks is to see if the browser can even support it).

1 Like

I‘m having an issue with my 16n build after updating to 2.0.1. I’m using an Oshpark Teensy 3.2. The activity LED is constantly on, and with the editor page open, the teensy gets constant sysex requests, but the page doesn‘t recognize the faderbank. When I move the faders and use a midi monitor to monitor the midi messages, it shows me (seemingly random) channels jumping from 0 instantly to 127 when I move it a little up from the 0 position. However on version 1.3.4 everything works as expected, even after downgrading again. Any help would be greatly appreciated!

other boring questions: what browser? and are you on PC or Mac?

also, was the Teensy used for any other projects before this? My only guess is: there’s a thing about how the firwmare works out whether or not to overwrite the EEPROM for factory settings, and if the EEPROM wasn’t empty, it might not have configured itself properly, meaning it won’t spit out stuff on useful MIDI channels. I can see a way to force an override, but it requires new front-end editor code, and a firmware update.

I might have used it one time for the Ornament Crime eurorack module, but I‘m not entirely sure…

I‘m running macOS 10.14.6 and I’m on the newest Chrome version. Also tried with 3 different USB cables.

you know, that might be it - if it was previously used on OC, my firmware might not flash correctly.

I’m really busy with work right now, but I’m going to kick off a Github issue to investigate this.

OK, thanks to @arev’s excellent diagnostics it looks like I’ve found an issue with 2.0.x - namely, if your Teensy EEPROM wasn’t empty/unused, upgrading to 2.0.x doesn’t quite work right: it never prepopulates the board with factory defaults, meaning the editor doesn’t understand how to connect…

I’m solving this by adding a sysex message that forces the device to reset to factory defaults, and functionality in the editor to trigger this.

I’m quite slammed with work right now, though, so this will take a little while to see through, but it’s not a huge amount of code - just need to work out where the interaction lives. I think this might solve at least one other person’s mystery “why can’t the editor see a 2.0.1 board” issue.

2 Likes

is github down? I cant enter the site :frowning:

define “the site”. The homepage (https://16n-faderbank.github.io) is up and fine, as is the editor. Good bug reports include a bit more context: what browser you’re using, what you mean by ‘the site’, etc.

Hello it’s ok now sorry :slight_smile: everything works fine and well.
Just got my sweet sixteen today. I got everything working with teletype. My setup is as on the picture atm.

2 Likes

Hi all, I hope this is the appropriate thread for a question like this - a friend built two 16n’s and generously gifted me one (!!!) but I have 0 experience with midi or funds to invest in something like ableton. I was wondering if someone could recommend a free or online midi platform that could connect to the 16n with minimal/no interface tools - hoping to use it to send melodies or sequences to my modular… is this a pipe dreaM?

Thanks so much!

A 16n isn’t a midi to CV converter. It can’t send computer data to your modular. It’s a controller; it emits the position of its faders via a variety of outputs.

The simplest application with one doesn’t involve a computer: power it from any micro-USB charger, like from a mobile phone, and the jack at the back of each fader will emit 0-5V CV, dependent on position. This makes for a fun macro controller for a modular or voltage controlled system. There are some nice video examples of this over at the 16n splash site.

(The computer-based example would be to send that data as MIDI messages over USB to a computer, for instance, to control channel volume, or parameters in a virtual instrument.)

Is there a way to change what i2c channel the sliders of the 16n come through as? I wanted to use both the Ansible and 16n as leaders to the ER-301, but for obvious reasons, don’t want competition between both of them.

Thanks!