LED Issues with brand new controller

joyofresh · December 2, 2025, 6:49pm

Hey Yaeltex,

I am having some issues with my controller:

Killowhat is NOT connected during this demo.

The issues are that two LEDs (for me CC 99 and 101, card 131 and 133 in killowhat, key “115” and “117” in the .ytx json object i think) don’t seem to respond to midi feedback. AFAIT, CC99 and CC98 are identical except the param number, but CC98 responds as expected and CC99/CC101 does not.

The second issue is that the controller drops messages, and whats worse, it sometimes corrupts messages. Dropped messages are annoying, but can be handled in my software. Corrupted messages (lighting the wrong LED the wrong color) is harder to deal with. I didn’t mention this in the video, but the wrong color LED thing can happen even when the LED in question isn’t being sent any messages, suggesting there is broken message routing somewhere.

Also not shown in my video, under moderate load of messages computer → controller, messages from the controller → computer sometimes get dropped or delayed significantly. I’m using relative controllers with compute-side acceleration, so delayed messages means my acceleration goes down and the actual param essentially doesn’t move (or moves very slowly). I don’t have a unit test for this case because I found the two cases above trying to reproduce it.

Is there a test script I can run or diagnostic mode? Would love to get to the bottom of this.

.ytx file: theallelectricsmartgrid/patches/WRLD.BLDR.ytx at main · jvictor0/theallelectricsmartgrid · GitHub

Best,
-Joseph Victor

joyofresh · December 2, 2025, 6:50pm

my scripts:
first script i ran:

github.com/jvictor0/theallelectricsmartgrid

scripts/two_broken_leds.py

main

import mido
import time
import itertools

# ============================================================
# CONFIG
# ============================================================

TARGET_NAME = "WRLD.BLDR"   # substring match for your device name
CC_OUT_NUM  = 98
CC_OUT_CH   = 3        # channel 4 in MIDI-land is 3 (zero-based)
CC_IN_CH    = 2        # channel 3 inbound is 2 here

# ============================================================
# Locate ports
# ============================================================

out_port_name = None
in_port_name = None

This file has been truncated. show original

second script i ran:

github.com/jvictor0/theallelectricsmartgrid

scripts/led_check.py

main

import mido
import time
import itertools

# ============================================================
# CONFIG
# ============================================================

TARGET_NAME = "WRLD.BLDR"   # substring match for your device name
CC_OUT_NUM  = 0
CC_OUT_CH   = 3        # channel 4 in MIDI-land is 3 (zero-based)
CC_IN_CH    = 2        # channel 3 inbound is 2 here

# ============================================================
# Locate ports
# ============================================================

out_port_name = None
in_port_name = None

This file has been truncated. show original

joyofresh · December 2, 2025, 7:57pm

Ah! Issue #1 resolved! CC99 and 101 are NPRN reserved CCs. I changed my mapping to skip 99 and 101 and put the left side on a different channel. Now all CCs are between 0 and 64, just on different channels, and the “dead” LEDs are gone.

Unfortunately I still have issues with the LED “corruption” where the color is wrong.

I pushed the changes to my .ytx and scripts to github.

joyofresh · December 3, 2025, 7:14am

I think this is quasi solved, by reading this forum, this is the now infamous encoder gets stuck behind LED updates issue that I was originally having, and I can fix these glitches by not being… a little intense… with my midi updates. My old launchpad could take it, but thats on specialized hardware.

I think encoders stop working around 32 messages every 10ms. For me thats not a lot, but I can accept that I am unusual here.

francoytx · December 3, 2025, 1:33pm

hello @joyofresh!

Welcome to the forum! You designed a beautiful and powerful controller
I’ll put some spacers to divide topics

NRPN/RPN

Good job on finding the NRPN and RPN issue.

It’s like you say, those CCs are the beggining of the NRPN and RPN messages.

If you send the same message twice, or as you did, skip those, you should be ok.

This is not a problem if you use NOTES!

Data Corruption

The green pixels and the scanning are possibly because you are sending too many messages to the controller.

I see you are using value to color, so probably the value of the CC is being corrupted.

MIDI is a protocol originally designed to process no more than 1000 messages per minute.

This means that you should not send more than one message every millisecond.

If you say you’re sending messages at the same time, ensure there is at least a one-millisecond gap between them.

Then, the controller uses a two-stage process to update LEDs, which is the source of the timing sensitivity:

Main Processor Buffering: When your Max patch sends MIDI messages, the controller’s main processor receives them. Instead of immediately updating the LEDs, it adds each feedback request to an internal list, which is a buffer that can hold up to 256 updates.
Sending to the LED Processor: The firmware is designed to be efficient. After it receives the first message of a burst, it waits a very short time (5 milliseconds) to see if more messages are coming in. After that 5ms, or if the buffer fills up with 128 messages, it sends all the buffered updates in a high-speed burst to a secondary processor that is dedicated solely to controlling the LEDs.

The main processor then waits until the secondary processor flags that it has ended the job before sending another burst.
While the secondary processor is working, the main processor continues to receive and buffer updates. However, if more than 256 updates occur during this time, some of them may be overwritten.

As I said at the beginning, this shouldn’t happen at all if the MIDI speed limit is complied with, since the secondary processor’s feedback “show” process doesn’t take more than 15-20 ms.

A proposed solution or test:

If you find that only 32 buttons update correctly, send your feedback messages in chunks of 32 or fewer, with a small delay between them.

Send the feedback messages for the first 32 buttons.
Insert a delay of 10 to 3 milliseconds. You can test which gives the best result. This gives the LED processor a moment to clear its buffer before continue to receive updates.
Send the feedback messages for the next 32 buttons and repeat.

If you find that this stabilizes the behavior, then you can start increasing the amount of LED updates each time, for example to 48, 64 and so on.

Let us know what you find!

joyofresh · December 4, 2025, 1:00am

Word, thank you.

I realized yesterday what I’m asking for is a lot, and a crazy thing to do day one. Literally the first thing i did was renumber the digitals 0-128, glad its not broken. I’m porting a JUCE app which used to run on 4 launchpads and a midifighter twister: dedicated hardware with huge economies of scale, relative to yaeltex. These controllers can handle thousands of messages a second, so i just took that for granted, but now I’m realizing thats a bonus feature of these controllers and not something i can automatically expect from a flexible platform like this. I’ve been playing this instrument for two years and I’ve never had a midi glitch, even when sustaining 5k messages/second.

I found that if I keep to 32 messages every 11ms frame, the LEDs become stable, but the encoders get slow. I read the code and forum last night and came to the same conclusion… if you’re sending a constant stream of 32 led updates / 11ms you still slow down encoder updates by a lot. Unfortunately, I’m extremely stubborn, and won’t change my instrument, so instead I’ll try to make the firmware match my extreme requirements.

I think i might experiment with checking the encoders in the LED update loop. Worst case scenario is it doesnt work. I’m pretty excited actually about the hardware hackability aspect of yaeltex. If I get something that works, or if I can’t figure it out, I’ll post about what I did/learned.

Yall made a great platform!