bindCHOP input order issue


2_Sliders.tox (8.8 KB)

Here we got two practically identical custom made slider components. The only difference of them is the bindCHOP inputs order. Component on the left got its slider kinda stuck from time to time if you move cursor from the slider panel
Order in bindCHOP obviously shouldnt affect the UI behaviour in the presented case.

1 Like


The issue becomes directly apparent when trying to drag on the left slider quickly, it will often not go all the way to 100%. The right slider always works properly.


Hey @Whitevoid @keeponthumpin

Thanks for the report.

I was able to reproduce and this is logged for a developer to look into it.


1 Like

Okay we did a little dive on this and it’s a classic UI problem. In a nutshell, the problem is that there’s a race condition between the two inputs to the bindCHOP when the 2 values change on the same frame. Because the lower input takes priority, the order matters, thus the unexpected difference. This particular manifestation is because the clamped panel value stops changing once you go outside the limit, but the bindCHOP is stuck on the par value which is one frame behind.

While you can solve the problem by ordering the bindCHOP inputs differently like in the example, I think the more graceful solution here is to keep your ui value (u) more separate from your data (Value). I built an example.
3_sliders.toe (7.7 KB)


Thanks for the example @Ivan!