#55

Yes indeed! Standard 16n build with a 3.2. :+1:

1 Like
#56

Yes! Thank you sir! 20chars

#57

updated from 1.34 to 2.01 (on a MSW-built teensyLC 16n) and the leftmost fader isn’t spitting out any midi messages. nothing in the web editor and nothing going in to max. reverting to 1.34 puts that fader back in action. has this happened to anyone else?

not quite sure where to start poking around to find the problem but i figured i’d ask here in case anyone else has encountered this issue. searched the the thread but didn’t see anything.

1 Like
#58

There are 2 different hex files, it sounds like you more than likely need the “16n_v201_TEENSYLC.hex” file if it is from msw.

2 Likes
#59

i used the LC-specific hex.

further investigation shows that checking the “Rotate controller 180 degrees” box makes the leftmost fader active–but deactivates the rightmost! (not rotating the controller physically–so “fader 1” is probably a more accurate description.)

1 Like
#60

Hmmm, you could have one from the first batch of boards that used a teensy 3.2?

1 Like
#61

it’s possible. the sticker on the bottom says FW 1.34LC but there’s no harm in trying (as far as i can tell from this thread, ha ha).

exciting update: the non-LC hex didn’t work at all. back to the LC 2.0.1 and the problem persists. i appreciate the idea though!

#62

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

#63

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!

#64

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
#65

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.

#66

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

#67

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.

#68

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
#69

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!

#70

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
#71

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!

#72

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.

#73

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.

#74

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.