Cabbage Logo
Back to Cabbage Site

Race condition when switching presets

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?

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 :joy:

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:
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: (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 :rofl: 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. :+1: 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.