@mike, thanks! It’s made much more enjoyable by the quality of the firmware code and @francoytx being so responsive! He is ON IT and this code is going to be polished to a mirror shine by the V1 release.
@francoytx, I updated by edit above your post (confusing of me!) & will send pix or video when I get a chance. Pretty sure now that the controller is 100% capable of what I hoped it would do
I updated to the 0.14 firmware and am not seeing any issues so far. My tests seem to work as expected! I also updated it with my own color palette and it’s looking good.
That’s great news @mike!
I think that version didn’t include @gc3’s fix though 
Looking at the code again I saw that there was a flag being set inside the if statement which is colorIndexChanged and that is why encoderSwitchChanged wasn’t there.
That looked weird enough to think there was something else actually bothering, but @gc3 actually made it work!
So yeah, there was… the problem was that the BANK_END (now BURST_END) message was not being sent at the end of the data burst. This happened because the last updates of the burst were meant to be the encoder switches, but they weren’t because there wasn’t changes.
When @mike tried to turn everything off, if the last encoder switch updated was already off, that prevented the main controller from sending the BURST_END message, and if it was on, everything would update.
It’s a long and complicated chain of unfortunate events hahah
the good thing is that the fix that I found also fixes the problem, and everything makes sense
This will be released soon as the v0.14.
Aha! BURST_END. That’s a part of the back-and-forth I never started trying to follow. Much happier to know why that fix worked, it’s unsettling when something starts working without a satisfactory explanation…
Well done @francotyx!
Pretty funny that two separate people in the small beta test pool were [A] doing bulk blanking of [B] encoders that were [C] already off and [D] last in the chain. But it’s great to see all those [FIXED]s going up.
I tried installing the posted 0.14, and I also cloned from gitlab and updated with my palette. In both cases, I’m still getting issues with buttons not being turned on/off when I send messages.
I haven’t updated yet–just using the version with my workaround–but I’ll try the bugfix branch and see if I can still replicate on that.
Oh no! sorry to hear this @mike, I was able to reproduce the issue you and @gc3 described here, and I the fix actually seemed to solve it
@mike can you confirm if it’s the same issue as the encoder switch being updated last problem?
random stucked pixels?
EDIT: ok, i confirm something got in the update that wasn’t supposed to. Fixing ASAP
@francotyx, looks like you’ve spotted an issue already but the existing v0.14 did resolve my particular issue with frozen updates (maybe @mike was exercising a different problem).
Actually false alarm, I was hitting the wrong MIDI channel, dumb of me
I am sending (with buttons and encoder switches off):
BUTTONS ON
ENCODER SWITCHES OFF
wait 1 second
BUTTONS OFF
ENCODER SWITCHES OFF
wait 1 second
BUTTONS ON
ENCODER SWITCHES ON
wait 1 second
BUTTONS OFF
ENCODER SWITCHES ON
And I see everything update correctly.
Let’s wait and see if @mike can tell us a bit more about the issue he’s experiencing
I’ll try duplicating this test and see what I get. haven’t had a chance yet
Okay I’ve run Franco’s test. My test:
At each step, it also counts up through the first 4 buttons on the left, in white. I run this test 3 times, clearing everything at the start of each test and pausing 3 seconds between.
Here it is: https://youtu.be/bjKfM-7QhDs
Unfortunately:
if I step through the program in the debugger, everything works perfectly. also, if I put a second between each part (lighting all the pads is one part, lighting the encoders is another), it also works fine.
I put a delay after every single midi note or CC sent to the controller. If the delay is 12 millis or less, it doesn’t help. at 13 msec, it is basically fine, doesn’t miss anything (stuck pixels aside).
Yes, a small delay between messages might still produce some stucked pixels, because of small async problems between MAIN and AUX.
No delay at all however, should work just fine.
Again, I am not being able to reproduce what I see in your video @mike, I am trying to recreate the same conditions with different hardware, but sending similar amount of messages from a QT app with RtMIDI.
If I upload v0.13 I get the wrong behaviour we discussed earlier in this topic, but with v0.14 I see everything turn ON and OFF correctly.
When you cloned from gitlab, which I assume is the last firmware you left in your controller, did you clone from the bugFixFeedbackUpdate branch?
When I posted that, it wasn’t still merged with the develop branch. It is now.
I’ll keep trying to reproduce what you get as result, and if you make further tests, let us know.
No I just cloned the master branch. what should I test?
okay! I checked out master again and this time it seems to have worked. Franco’s test above works properly now.
I’ve been working on a UI mockup of my hachi sequencer, and that is now working fairly well too. however, at startup I first clear all the buttons and then fill in the central 128 buttons blue. they usually only half fill, until I added a sleep(1 second). I was also working on a beat clock, that would count across 16 buttons once per 16th note (so 125 millis at 120bpm). when I was drawing the whole set of 16 each time, it skipped around a lot. I simplified to where it only has to update the buttons that change, and now it looks fine.
so it seems like there are some limits to how many buttons you can light up quickly. on the other hand, I have buttons that immediately paint all 128 buttons, and that all seems to work fine. I’ll try to make a video.
That’s great news!
Sorry that this wasn’t clear, I’m working on getting better at git management 
For now I’m using the develop branch, since there isn’t a completely stable final version of the code, and the whole thing is in a beta state.
I set the develop branch to be the main branch in gitlab, but I guess it’s still confusing.
At the time I posted the v0.14 the develop branch didn’t have the changes merged, so actually the v0.14 was in the bugFixFeedbackUpdate branch.
Now the v0.14 is in the develop branch, and I’m testing and adding features to the v0-15-testing branch (encoder color change may be coming soon )
Simple sounds better, but 16 notes every 125 ms should work fine, I will take note and keep improving this.
Video looks very promising!
I’ll set this bug to FIXED again and if something comes up we’ll keep discussing
great work, everybody - sorry i couldn’t contribute, not much free time in the last 2 weeks, but it’s great to see very promising progress being made.
i also noticed some issues when updating encoder feedback. in my test, i’m running an app on the controller itself, and i hacked the feedback implementation to send feedback for 128 buttons every 30 ms - this seemed to work fine, but adding encoder feedback (which would get triggered by turning an encoder) introduced delays as well. pretty sure it’s the same root cause - will give it another test with the latest fixes and report back.
Well, I am still having this basic problem. I am losing a lot of notes. It happens fairly consistently, though there is no consistent reason why. In some cases, if I add a delay within the loop where I’m updating, things are fine. But the delay has to be 10 millis or so, which is really not usable when you have 128 buttons to update.
There are some inconsistencies. For example, I have a couple of different places where I color all 128 central buttons. One call works consistently, while the other almost always causes problems. The codepath is basically the same.
The one that breaks is in a “clear” function. it sets the central buttons and some of the surrounding buttons to off. if I comment out the calls to the surrounding buttons, then the central buttons clear fine, even without a 10ms delay. if I leave those calls in, but have a delay, the central buttons clear fine. Without a delay, it breaks. If I comment out the central buttons, I can run the outer buttons fine without a delay. Weirdly, these problems aren’t non-determistic – when it doesn’t work, it always fails in the same way, in terms of which buttons are on and off.
I also still have issues like if I try to clear all the buttons before the program exits, it often doesn’t work, even if I add a delay.