So one issue I see is this line:
This is passing a value of 16 as visible in one instance. Cabbage only chcks for values of 1 and 0. It treats16 as non 1, so assume it should be 0. Why init to 16?
Race condition when switching presets
in fact, why are you setting the visibility of any of those step buttons? They are always showing right? So the simple fix is to stop setting their visibility.
It seems that the ternary operator is returning 0 every now and then. Im not sure why, but by commenting out that code I can get all of your presets to loaded without any disappearing.
For kStepVisible, I donât remember why I have it initialized and why itâs 16. I likely had other plans for it before I began storing everything in arrays, so it can be removed.
As for the ternary operator, I do manage the visibility of the step buttons - I misunderstood your previous question. I will take a look to see if the ternary operators are interfering with each other and if theyâre passing the appropriate values.
Later today I will record a video to give better context of whatâs going on, because writing text only goes so far 
Okay, Iâve recorded about 40 minutes demonstrating whatâs happening on my end so far and what I think is happening, on YouTube instead of GDrive: https://youtu.be/_H5SL1rdWIY
You might not have 40 minutes or more at the moment to sit through the entire thing at least once, Rory, so I respect that and donât expect anything.
My takeaway is that I have four or more options: leaving it as a known issue and move on, removing the preset functionality entirely because its only fun not necessary, reworking the preset change code block to somehow work within the individual visibility code blocks, or finding an alternative to cabbageChanged which seems like the worst option.
I also noticed as I was rewatching my recording that the âinterferingâ part where the grid buttons disappear from the individual-visibility-code-block at â0â instead of remaining on-screen with the preset-change-code-block at â1â, it happens most often to the bottom-most rows where there is a change. If I only modify the first 8 rows and change presets, it happens in the middle, and if I modify all 16 rows and change presets, it happens at the bottom. I donât know how much of a clue this is but itâs a pattern. Here is the version that Iâm referring to, if itâs even reproducible: StepRouter0or1.zip (19.1 KB)
I will try my third option of reworking the preset-change-code-block into the individual ones tomorrow or later and update you on it.
I cetainly donât 
but thanks to the âplayback speedâ option I was at least able to see why you need to toggle the visibility. I think the first port of call for me here is to see why switching to that first preset doesnât work. If I can sort that, it might hold the key to the rest of it. 
This one is a real puzzle.
Iâm just looking at this code again.I donât think the tf statements with kPreset != 1 are behaving as expected. With your latest csd file, whenever I update a preset I get the following lines of text printed to screen:
changed preset!
updated step length visibility!
updated step button visibility!
updated step length text!
But during a preset change kPreset should be 1, so those other if statements should be triggered? Is that the logic youâre trying to implement here? I think whatâs currently happening is that youâre updating teh visibility of the button several times on a single k-cycle?
Yes, I noticed it not working as well. The way I currently have it is that during a preset change, the if-statement triggered using kPreset updates all the widgets on its own, on all rows. I made it this way because the other if-statement code-blocks would not change all the rows, I think, and so I essentially replaced their behavior for that particular case.
But, changing the preset does update all the channels anyways, so it would be better to not have that first if-statement work like this. Trying to make it exclusive doesnât work, as you saw. I also realized that it is probably updating several times as the trigger equals 1, so I could have it run once and then stop somehow. I will play around with it.
I am back after what, 2 months? I have since then tried doing the ârun it once and then stopâ functionality by adding a boolean that locks after the first run-through and then unlocks when cabbageChanged stops triggering. It marginally improved the issue, but the visual artifacts remained.
My ultimate solution for all of this was to refactor my code and hardcode all of the dynamic parts that handled the widget updates with cabbageChanged. It quadrupled the lines of code I had, but it achieved acceptable results. I can still get the visual artifacts sometimes by switching presets very quickly, but it is only in my labels and at this point I no longer care for perfection.
The plugin will be out soon though! Can finally put this issue to rest by assuming that cabbageChanged must be used carefully with multitudes of widgets.