If you have an MSW 16n with an LC, this will not work. If you have tried to apply it, you should be able to reflash the MSW 16n firmware as others have suggested.
More work will be required to make this work with a Teensy LC, clearly. If anyone would like to, the code is, as ever, available.
After trying my 16n seems to be working just fine. I just can’t connect to the web editor. Or am I missing something and need to flash it back to a previous build?
I hinted at this before, as usb midi out was working just fine for my teensyLC based device with firmware v2 (monitored with midi monitor). the device was just not detected by chrome. at some point it did in fact detect it, then when I wanted to persist the settings it went white and I could never make it detect again.
I did cross check my setup with another 16n board teensy 3.2 based which works as expected.
my guess is the dynamic memory is not enough for some kind of device or sysex handshake? no idea
let me know in case I can check/test anything else
OK. So that sounds like there’s something going on with a) the sysex handshaking and b) the EEPROM memory on the Teensy. I could probably test this without a MSW 16n if I only had access to a Teensy LC board; if I do, it’s at my studio, which I currently don’t have access to.
That was it actually. I just rebooted my computer and went back to the web config and it’s seeing it fine. I guess that answers which teensy my MSW was built with.
If you’re following along and interested, I’ve got a much better handle on why the editor isn’t working correctly with LC-based boards right now:
This is in the Teensy 3.x/LC MIDI libraries: the LC is setup to have a maximum sysex buffer length of 60 bytes (unlike the 3.2, which gets 290). The current payload from the editor is… ninety bytes. Which means any edit transmissions bugger up entirely.
I would rather work out a way to fix this in firmware than to have to rewrite the editor to send multiple payloads per edit. Primarily because: this works fine on the product as designed.
Anyhow, at least I know where one of the major blockers is. @okyeron kindly assisted me with some initial LC debugging last night which helped me get to this point, because, as mentioned, I’m at home with no access to any LC boards.
This does one thing: it adds support for LC-type boards. This necessitated changes to both the editor code and the firmware itself, but it works fairly neatly alongside master-pattern 16ns, which is an outcome I can live with.
My two LC testers have confirmed it works for them, so now, if you have a 1.34LC board from MSW, you too can try this. There’s a specific LC hex file on the release you will need to download.
There’s also a change to the editor, which is slightly experimental, but I like: if there’s a newer version of the firmware available to download, the editor currently prompts you to do so top right:
Anyhow. Fingers crossed this works for you. Time for bed here.