Fader min max vs MIDI min max

Developers
1

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. Plus, any MIDI data received does set the fader to the correct value when the parameterMap is changed as well as my encoder turns.

Here is the reason for the question and above info:

If I use value:setMin() and value:setMax(), I can create a min and max for the fader movement as long as the new min/max is inside the range set by the MIDI min/max.

However - the fader and visible range is still fixed at the original Min/Max. What I’d like to see is when I set the value:setMin() value:setMax() the fader uses the full range across these values

Current example: trying to dynamically create a fader for various parameters. I can set the name, make it visible, and set a range for movement/transmission. However, since this is a generic fader control, I have to set the min and max in the GUI to the lowest and highest possible values (say 0 and 500) even though I’m not using them all every time (using 100 to 300). So my fader movement is a small section of the full range.

I kind of hope that’s clear. If I finish work on this section of the PCM 70 preset, I’ll include the link so you can see it.

Looking at the JSON, it appears I need to change the message min and max, but I don’t see an API to do that.

1 Like
2

the idea is as follows (writing a longer story to share a bit of inside stuff):

  1. the parameterMap is the real (and the only) data storage for parameters and their values. The values stored in it are always constrained to the MIDI min and max. These are referred as to MIDI values. Each MIDI value stored in the parameterMap has a list of controls (control values actually) that are linked to it.

  2. the display value is always calculated at the runtime. It is constrained with the display Value min and max.

  3. the conversion between the MIDI and Display value, in both directions, is done by knowing the mins, maxes, sign types.

  4. if a MIDI message arrives from the outside world or if you change it with setting a parameterMap. It gets stored in the parameterMap and updates of all control display values (display, Lua) are triggered automatically. As there can be more control display values linked to it, each of them uses its own display min and max to calculate the actual value to be displayed.

  5. if the change is triggered in the User interface, the parameterMap MIDI value gets updated and the MIDI message is sent out. As this is triggered with a specific (one) control (control value). Only the min and max of that control is used to calculated the new MIDI value of the parameter stored in the parameterMap. If there are any other control values linked to that parameter, they get updated immediately after the parameterMap is updated. Each using its own min and max settings.

So this is kind of in line with your observation. The only bit you miss is an update of properties of the Message object (min, max) I think. I stayed away from that in the past because changing it may make the data stored in the parameterMap invalid (eg value being outside of the min / max). Of course it is something that can be implemented. What we could do is that I would implement the simplest possible way. Just giving you control over the Message object and you would check if it addresses what you need. if so, we could take it further from there.

1 Like
3

@martin - yes, I think simpler is better most of the time. :slight_smile:
Adding a getMin() and getMax() to the Message object (like you already have for the Value object) would be all that is needed I think.