setMin and setMax no longer working as before

[NewIgnis]

I made presets before such as the one for the Korg 03R/W where the display limits of a control are set dynamically using value:setMin and value:setMax functions. But in FW3 they do not behave as before.

Before FW3 they indeed worked as new display values, using the full range of the bar to go from the new setMin value to the setMax value.

In FW3, it looks like the display limits are retained/imposed as set in the MIDI min and MIDI max of the control itself.Any value in setMin or setMax outside of the MIDI values is no longer reachable. Any value set that is within the MIDI values just limits the travel of a control.

To reproduce, load preset Electra One App

In its fx page, choose ‘reverb hall’ as FX1 TYPE. This will limit the travel of reverb time (the third control on the screen) to move from 0 to 99. That used to use the full length of the bar, but as the control MIDI values go from 0 to 200, it now uses only half the bar.

The ‘eq low’ and ‘eq high’ controls on the second row are worse, as their setMin = -12 and setMax = +12. But their travel is now limited to 0 - 12 , only using the first 6% of the travel between 0 and 200.

[oldgearguy]

Martin and i had a brief exchange about this

Fader min max vs MIDI min max

So what’s the relationship between the two different Min Max settings when defining a virtual fader? If I define a fader with no values at all in either, turning the encoder doesn’t do anything (as expected) If I define a Value Min/Max, the fader still does nothing. However, any MIDI data received does set the fader to the correct value when the parameterMap is changed, but moving the encoder does not change the value. If I define a MIDI Min/Max, the fader changes value as I move the encoder…

[NewIgnis]

Thing is: it used to work differently, so some of the former presets aren’t working anymore as supposed.

It used to work as follows: with the MIDI min / max you set the boundaries of the values transmitted, whereas with the display min/max you set how the values are displayed. The latter used the full scale of a control, and that is no longer the case.

I do think it’s a bug, as it diminishes functionality.

[oldgearguy]

agreed - when I first ran across that, I ended up doing a redesign to use a different way.

Also, since we’re keeping track -

if you use

myBounds = control:getBounds()

and then pass that to a helper to convert to a slot:

mySlot = helpers.boundsToSlot(myBounds)
print("Slot = " .. mySlot)

you always get 1

I wrote a quick converter function to use for now:

function cvtToSlot(bnds)
   local myX = math.floor(bnds[X] / 167) + 1
   local myY = math.floor(bnds[Y] / 90)

   return ((myY * 6) + myX)
end

Not sure how many people are making decisions based on where the control is located, but I found that to be useful for my PCM 70 preset.

[martin]

@NewIgnis

In its fx page, choose ‘reverb hall’ as FX1 TYPE. This will limit the travel of reverb time (the third control on the screen) to move from 0 to 99. That used to use the full length of the bar, but as the control MIDI values go from 0 to 200, it now uses only half the bar.

Replicated and understood. It is a bug indeed. In FW3, only the preset “data model” gets updated but the visual component is not rebuilt. If you switch to different page and then come back to the FX page, it will work properly. I am already fixing it.

[martin]

@NewIgnis @oldgearguy can you test 3.1.5 on beta. This should be resolved.

@oldgearguy - the boundsToSlot function (you mentioned above) is fixed too.

[oldgearguy]

I should have some time later today. Thank you for addressing so many areas.