Add support for number-type inputs that display only as a slider, with human-readable labels for min/max/current values

[jswalden]

Is this a feature relevant to companion itself, and not a module?

• I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• I have searched the existing issues

Describe the feature

CompanionInputFieldNumber exists to specify a numeric value within a defined range. It can be made to display a slider control with range: true.

But in some cases, the particular numeric value might not be meaningful/important to the user: only its semantic meaning is important. For example, with MIDI NRPN parameters, you can set the value of an NRPN as any value from 0 to 16383 -- but that value as encoded in the underlying MIDI message probably isn't the value the user understands. (For example, with Allen & Heath mixers in the SQ line, you can set various levels [of some source signal in some sink] this way, from 0 to 16383 -- but 0 really means -∞dB and 16383 really means +10dB, and the correspondence between the two is quasi-logarithmic.)

I believe this can be supported by doing something like adding a CompanionInputFieldNumber subtype that looks like this:

interface CompanionInputFieldRange extends CompanionInputFieldNumber {
    range: true,
    display?: (value: number) => string,
}

and then if display is specified as a function, that function is used to generate a begin label for the range, an end label for the range, and upon adjustment of the slider a label showing the current value can be generated. It could look something like this, omitting (or visibly hiding) the field that currently displays the numeric value:

<begin label> |===========(o)============|  <end label>
                   <current label>

If display is unspecified, it could backwards-compatibly display as the widget currently does.

I don't know whether there's adequate support at the widget level to implement this proposal, but I figure it's probably possible to at least hack something together that would come close.

Usecases

SQ audio mixer levels could be set using this input type:

-∞dB  |==========(o)====| +10dB
                 0dB

Similarly, SQ audio pan/balance controls (to pan a mono source from left to right within a stereo sink, or to adjust balance of a stereo source in a stereo sink) could use this (rather than the current dropdown of L100, L95, ..., L5, CTR, R5, ..., R95, R100).

L100  |==========(o)====| R100
                 R75

[Julusian]

For example, with Allen & Heath mixers in the SQ line, you can set various levels [of some source signal in some sink] this way, from 0 to 16383 -- but 0 really means -∞dB and 16383 really means +10dB, and the correspondence between the two is quasi-logarithmic.

I don't think this scenario is a good case to consider. I think it is better for the module to translate this into user friendly numbers, instead of making the ui handle that conversion. You will need to do this conversion anyway for any variables.
The behringer-x32 module does this, as it's osc uses values between 0 and 1 to represent the -∞dB to +10dB.

I would be open to adding some options to tell the field that the min value should be interpreted as -∞, as that is currently lacking and is typical for audio faders

[jswalden]

I think it is better for the module to translate this into user friendly numbers, instead of making the ui handle that conversion. You will need to do this conversion anyway for any variables. The behringer-x32 module does this, as it's osc uses values between 0 and 1 to represent the -∞dB to +10dB.

Ah, fair point -- I hadn't thought of variables as functionally part of a module's interface that way. But you're right, that is worth considering.

I would be open to adding some options to tell the field that the min value should be interpreted as -∞, as that is currently lacking and is typical for audio faders

So basically you're saying I'd still have { type: 'number', min: -90, max: 10, default: 0 } or somesuch (-90 to +10 being the range of internal encodings of levels, with the module itself forcibly treating -90 as -∞), but with an additional minIsNegativeInfinity: true added in? The trickiness is that a number input ordinarily does in fact only accept those specified numbers, and I dunno whether it's possible to override the display of -90 in number inputs in that case -- maybe coreui (?) differs, but also potentially not.