Cabbage Logo
Back to Cabbage Site

Race condition when switching presets

#1

Maybe this is a noob question, maybe this is something overly complicated.

I am having an issue where switching presets does not update my widgets properly. Rather, it might be in some sort of buffer, where some of the preset data does not update in time and instead only updates when you select the next preset, breaking the continuity and “blending” presets together visually. The values of the widget however are correct. It’s just how they are displaying.

I think there’s a race condition happening, and the problem is likely how I am checking if a preset is selected, from cabbageChanged on the preset combo box (line 212). I also have other code blocks that change the widgets individually, but removing them does not solve the issue, even though they are probably interfering too.

I just want all of the dynamic widgets to refresh when a preset is selected. Is there anything wrong in my approach? Thank you in advance. StepRouterWIP.zip (20.6 KB)

#2

I just tested this here and I can’t recreate the problem you’re having in either Cabage or a DAW. Maybe I’m missing something. Can you take a short video of the issue just in case it’s more subtle than I thought. Right now, if I go crazy with the widgets and save a preset, it gets recalled without any problems.

1 Like
#3

Sorry about the wait! Here I have recorded a silent video of my end (had to upload to GDrive because my connection isn’t the best here): https://drive.google.com/file/d/18v_hC0Zi9AKB4MtlDiit4OYMTScUYx0m/view?usp=sharing

Since this isn’t the first time I am having an issue with runtime, I have a feeling it might be my hardware, so I showed it at the beginning. I will try out this code on a different computer to see if I get different results.

EDIT: I am using Cabbage 2.9.0 and CSound 6.18.0 on Windows 10 in case that is relevant.

#4

Oh yes, that’s entirely relevant :slight_smile: Can you try the latest beta build? That’s the one I’m using, and it’s also 100+ minor version ahead of 2.9.0. If that doesn’t work better I’ll take this apart in a little more details :+1:

#5

I updated two computers to Cabbage 2.9.155 & Csound 6.18.1 and then copied over my project files. My first computer has Windows and my second one has Windows and Linux on separate drives. I didn’t record them individually, because they are all having the same issue, with or without my audio interface and regardless of the buffer size. On Linux I actually had more graphical glitches, such as the knobs missing their marker and some label widgets not updating automatically until I changed them with a button press.

I must be doing something wrong but I have no idea what it is, so I’m at a loss for what I should do.

#6

Let me try on Windows and see if I can recreate the problem. Right now I’ve only been testing on my Mac…

#7

I went to boot up my PC just now and the CPU fan died. :see_no_evil: That means I’m without a Windows machine until I can get a replacement. I’ll see if I can find a temporary one for the interim. The good news is it’s almost the holidays, and only fools like me will be using a PC over Christmas :rofl:

1 Like
#8

Please take your time, I don’t want to occupy your holidays with some unknown issue :joy:

#9

Ok, I managed to get my hands on a PC. And I can recreate the problems you’re having. But I’m away now for a few days so I won’t be able to take a deeper look till later in the week. But at least we can confirm it’s not something particular to your setup. :+1:

1 Like
#10

That’s good to know. What could MacOS be doing that is different from Windows and Linux? Perhaps it matters little, because I think the move is to fix my code. I likely have to reimplement how I display everything.

#11

Don’t reimplement your code just yet. If it works on MacOS it should work on windows :+1: let me take a look first.

1 Like
#12

@rorywalsh were you able to find out anything regarding this, or does this issue seem like a dead end?

#13

Oh that’s likely fixed. Can you try one of the most recent builds?

#14

The issue still persists over here. Tried Linux 6.7.9 and Windows 10 with Cabbage 2.9.193 and CSound 6.18.1 separately installed.
I also noticed my other plugin starting to have issues with “latency” or whatever this may be. Instead of assigning a default string to ten textboxes like normal, the first two are empty and I need to manually update them for the default to become visible. Likely the same root cause.
If the issue is no longer reproducible, then I can do a workaround to avoid the issue and move on.

#15

I’m just looking back over this thread to refamiliarise myself with the issue. I should get a chance to look into the cause of it today. I’ll let you know.

1 Like
#16

Cabbage is being told to make certain buttons invisible when changing presets - Im’ not sure why. That 16x16 grid contains all the buttons right?

#17

Yes, that whole grid is dynamically generated - there shouldn’t be anything hidden. Maybe the issue lies in my presets? They could be outdated :see_no_evil:

There are also the buttons to the left with the numbers on them, but everything should be visible.

#18

I created a new preset today and I couldn’t get it to misbehave. Can you try creating a new preset with a recent build of Cabbage and see if it works, at least that preset?

1 Like
#19

I’ve decided to recreate my presets. But in the midst of doing that, I’ve encountered new problems that might explain what the root problem is.

image
image619×509 66.5 KB

Going to debug these and try to fix them.
Current version with this problem, in case I made any changes: StepRouterWIP2024.zip (17.4 KB)

EDIT: when a preset is made, or anything else that modifies the button happens, the first button reappears. It seems like it is not keeping up.
It also turns out that when the instrument “main” is initialized, is when the issues occur. Before then, they all display correctly. Seems that my code is interfering, not Cabbage.

EDIT 2: I’ve got it now. Whenever the plugin starts, each of my cabbageChanged variables executes once and it modifies the first instance of a widget - which is why the first row is being affected.

EDIT 3: big dumbdumb, I init variables with “0”, and so at i-time it modifies the first row with null values. changing it to any number that does not correspond to a row, like “-1”, partially solves the issue. Now to address the preset-updating code block… (edit: solved as well)

#20

Well, I’ve made two new presets, but they are indeed still misbehaving. It does not happen as much if I slowly switch between them, but it eventually reveals the visual artifacts.

If I comment out the code block that updates on changing preset, it occurs on changing preset. If I comment out the code blocks that update on changing individual widgets, it still occurs on changing preset. Commenting out both stops the updates and issues. These code blocks use cabbageChanged, and when I check to see if all the triggers equal 1 at the same time while switching presets, it is only sometimes the case, not always. I’m not sure if the trigger timing is the problem, but it seems to have latency.

New version: StepRouterFix1.zip (17.5 KB)

EDIT: Ah, now, well I can’t reproduce what I was seeing in the debug log. I may as well go insane haha. This version includes a print statement I removed to test the triggers: StepRouterFix1a1.zip (17.5 KB)

EDIT 2: Making the individual update code blocks mutually exclusive with the preset change code block is impossible. If a preset changes and I set the individual code blocks to execute when the preset change trigger is not equal to 1, they execute anyways. Had the cabbageChanged triggers equal 1 at the same time and same duration, they wouldn’t execute.

Going to stop for tonight and let you sift through these spaghetti posts if any of it makes sense. I reckon I need an alternative to cabbageChanged, but I can’t imagine how.