I’ve noticed that if I send a bunch of note on and off messages to my controller for the buttons, I occasionally get a stuck button or two, where they apparently miss the note off message and stay lit up. there doesn’t seem to be any pattern to it, just like it occasionally drops a message.
yeah, i think it’s the same problem @gc3 has in Apparent overloading when moving RGB rotary encoder
there is a time limit (about 20-25 ms) as to how fast the LEDs can update, but I’m guessing it’s not that we miss notes or messages, but rather than the AUX firmware is not getting all the data correctly, every time.
I’m going to test this today a bit more and see if I can come up with an aux fw update.
1 Like
do you queue up messages so if you get a burst you can catch up, or if they start coming too fast you just drop them? queueing is fine by me, since my code is designed to prioritize getting the midi notes out on time and the colored lights can catch up as needed.
if you are queuing and it’s a matter of memory, I’d be happy to allocate more space to the message queue at the cost of being able to use fewer banks. I know my controller is pushing the limits of memory usage 
and actually, I’m worried about how bad it’s going to get when the user changes modes and I have to update all 128 buttons in the center grid.
I only have 96 buttons in my central grid but I can flash them all quite quickly for an indefinitely long time without overwhelming the buffer, and it looks quite steady (except for the occasional stuck-pixel glitch).
Conversely, I see stuck buttons (exactly as you describe) even with very low and very stable pulses of notes. My intuition is that there’s some much more subtle timing problem (either with MIDI in, with the feedback routines, or with their relationship to each other) which is causing the random drops.
I’m putting any theories I have into the thread @francoytx linked.
1 Like
HI guys!
Thanks for your patience on this matter.
We tested this a lot before launching, and I’m sorry it’s giving you headaches, but I assure you I am working hard to improve it and I can’t thank you for all the debugging on your side @mike and @gc3.
We couldn’t have gotten better controller stressers than you guys.
Burst of data between the main and the aux (like when there is a bank change) are handled quite robust, with checksum, retries, safeguards so the main doesn’t send data while the aux is showing pixels (interrupts disabled), but apparently there is still some sync issue.
For us, this only happened when the received messages were getting very fast and consistent (updates every 20-25ms), and we saw no stuck LEDs if the updates were slower than that nor we detected problems when updating encoders at the same time than updating feedback.
We thought this limit wouldn’t be reached for a while but you guys are awesome and pushed the limits of the controller. This helps us improve 
We’re working to solve this soon!
3 Likes