@clonescope has a race condition with the UI
Opened this issue · 2 comments
Since the fixes in #279 for making onload stuff async, I've been trying to chase down some race conditions around loadbang actions that change the UI... namely, @clonescope which frequently changes the contents of the display and the number of input and output ports.
Right now, doing a [stepseq 8,3] (from the mfp-patches repo) 10 times will give slightly different results. Sometimes not all the output ports show up; sometimes a single step or a single UI element within a step (a dial, for example) are comically misplaced. Sometimes it works fine.
The underlying object in MFP is fine, but the display properties get out of sync.
The above commit puts a solid nail in the coffin, I think. Basically it implements the policy that the GUI owns "gui_params" and the main process has to explicitly change each value that it wants to change. This reduces the surface for the race condition appreciably. It's still possible that a race could come up -- this is a mirrored-data situation with loose sync and slow update. But I can't reproduce it any more. Closing for now.
This still shows up in some cases. Particularly the [mix8bus] object... [mix8bus 8] from the [bobtronix] patch will have the second channel (first cloned channel) offset in X and Y by 20 or so pixels.