@clonescope has a race condition with the UI

[bgribble]

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.

[bgribble]

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.

[bgribble]

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.