i noticed this post on the other thread
its of course possible that there is some assembly issue. but i also took the time to check the bleached firmware:
that’s a very hot loop. the BOM specifies a teensy 3.2, which is a 96MHz part. this firmware tells it to use every single CPU cycle available to read the ADC, perform a comparison, and blast out a MIDI essage. the result is going to be an ungodly amount of USB traffic, a correspondingly enormous number of lua callbacks on norns, and also a maximally high current draw. (i do realize that it is filtering on a comparison, and further is limiting the resolution, but still - the read itself is gonna be happening something like a million times a second.)
i’d strongly recommend trying a call to delayMicroseconds() in the main loop. to determine an appropriate amount of delay, i’d first check and buffer some values of elapsedMicros to see how much time is spent doing work. (alternatively, move everything out of the main loop and into a Timer.) i wouldn’t think there would be any benefit in sending MIDI messages at more than 1khz. (even that would be pretty extreme; i’d probably go for 5ms or 10ms polling and call it a day.)