Modui 3 stage controls behave strange



Gui Controls with 3 stages can’t display the 2. stage anymore. For example the High-Pass-Filter Order control switch from 0 to 3, stage 2 isn’t reachable. I notice the same behave on all 3 stage controls, regardless if it been switch or knob.
I notice that in the web-inspector the background-position is 0px - 0px, or -160px - 0px. When I edit the background posittion to become -80px, the stage will switch to 2.
Seems like something goes wrong in the setRotation: function in modgui.js when a filmstrip consist of only 3 steps.

How to reproduce

Load the High-Pass-Filter plugin and try to set the Order to 2 in the UI.
Yo can set the Order to 2 in the Control interface, but, in the UI the control will stay at 0 or 3.

Expected/suggested solution

Expected is a move from 0 to 1 to 2 (this has worked before, only I ain’t know exactly sins when it ain’t work anymore

Additional information

Open the controller menu (hold left knob down), navigate to Info > Versions and write down here the versions.

  • release: v1.5.0
  • controller:a5aa6d3

Also provide some information about your system if possible.

  • Operating system:linux
  • System version: debian/sid



In modgui.js line 1648
rotation = Math.round(steps) * Math.round(filmSteps / (portSteps - 1))
needs to be
rotation = Math.round(steps) * Math.round(filmSteps / (portSteps - 1) - 0.01)
in order to make it work again.
That’s because when filmSteps is 3, and portSteps is 3 as well we get 3/2 = 1.5
now, Math.round round it up to 2. If we subtract 0.01 from the value, we could avoid this special case.



Thanks for the report @brummer (and the fix). I’m not sure I like that Math.round much. This bug was introduced several months ago.

I’m worried your fix might break a different corner case, so I’ll have to cook it up a bit.


Digging a bit deeper in the source I wonder why there is the subtraction of 1 from the portSteps at all?
The issue is resolved as well when just using
rotation = Math.round(steps * (filmSteps / portSteps ))
which works as well for any other constellation, and avoid significant rounding errors.


Good point @brummer.

I’ll include a fix for this as part of our next 1.6 RC release in the next couple weeks. It’s hard to test this at a large scale but I did a few tests on my own with a few dozen plugins and couldn’t see any issues with the fix.