VoltageKnob - MaxValue???

[seal58]

I'm working on a module where I use SetRange() to set MinValue and MaxValue of a VoltageKnob dynamically.
Now I'm surpriced that SetValue sets knob value even when it is higher then MaxValue. Is that normal or a bug?

[Waverley Instruments]

Pretty sure this is normal behaviour.

Whether it's correct or expected... well, I guess that's debatable

But, it's probably because SetValue() is defined in a base class and isn't overridden with range validation in components where a range makes sense - i.e., knobs, sliders etc.

My €0.02 - SetRange() is a UI thing, but I should be able to set the value to whatever I like programmatically, including values outside the UI range.

-Rob @ WI

[ColinP]

I should be able to set the value to whatever I like programmatically, including values outside the UI range.

Why?

[Waverley Instruments]

Why?

Why not?

Like I said, debatable...

[ColinP]

The value is the value of the knob isn't it? Why would one want to store a value in a knob that is outside of the possible range of the knob? And what is the knob supposed to do? It can't represent that value. If a user adjusts the knob what happens?

Say we have a bicycle that's a subclass of vehicle. One wouldn't want to set a maximum speed for a vehicle but if I explicitly say the maximum speed of a bicycle is say 100 mph then being able to instruct a bicycle to do 50,000 mph doesn't make any sense even though some other vehicle might be able to achieve that speed.

[Waverley Instruments]

Sure, there are lots of examples where you wouldn't want to set the value outside of a range, but the question, to my mind at least, is whether VoltageKnob (and other range-based controls) should enforce that validation on your behalf within SetValue(). I don't think it should.

Let's say that range has to change for some reason. What do we do with the current value if it's outside the new range? Clamp it to the new range? I don't like the sound of that, personally, do you?

What if the default range is setup in Initialize() then the actual range is determined by some other control value, let's say a type of something, "bike" or "car", to use your example. How do we know that the speed range will be setup correctly for the type, before the speed control gets set a value on state restore? I don't like the sound of that either...

Similarly, changing how it currently works could have implications with released code. Like I say, debatable, but I bet you €1, the CA response would be that it's by design, i.e. not a bug and I'm fine with that.

Again, my €0.02, but if you don't want the control value to be programmatically set outside the range, then... don't set the value of the control outside the range. And if you're worried about doing that accidentally, or someone else on your dev team doing it, then cover it in your model with an assert.

-Rob @ WI

[UrbanCyborg]

I'd say that's a fine case where enums would work. In fact, I do that in a module I'm working on now:

Code: Select all

    private enum ranges    {

        LOW  ( 0.00001, 2.00000, 1.00000, -9.9999, 9.99999, 0.00000 ),
        HIGH ( 0.01000, 20.0000, 10.0000, -9.9999, 9.99999, 0.00000 );

        private final double coarseMin;
        private final double coarseMax;
        private final double coarseDef;
        private final double fineMin;
        private final double fineMax;
        private final double fineDef;
        private final double totalMin;
        private final double totalMax;
        private final double totalDef;
        private final double fullRange;
        private final double halfRange;

        // Constructor taking six doubles
        ranges(double coarseMin, double coarseMax, double coarseDef, double fineMin, double fineMax, double fineDef) {
            this.coarseMin = coarseMin;
            this.coarseMax = coarseMax;
            this.coarseDef = coarseDef;
            this.fineMin   = fineMin;
            this.fineMax   = fineMax;
            this.fineDef   = fineDef;
            this.totalMin  = coarseMin + fineMin;
            this.totalMax  = coarseMax + fineMax;
            this.totalDef  = coarseDef + fineDef;
            this.fullRange = this.totalMax  - this.totalMin;
            this.halfRange = this.fullRange * 0.5;
        }   // ranges()

        // Getter methods for enum values ----------------------------------------------------------------------------------------
        public double coarseMin() { return coarseMin; }
        public double coarseMax() { return coarseMax; }
        public double coarseDef() { return coarseDef; }
        public double fineMin()   { return fineMin;   }
        public double fineMax()   { return fineMax;   }
        public double fineDef()   { return fineDef;   }
        public double totalMin()  { return totalMin;  }
        public double totalMax()  { return totalMax;  }
        public double totalDef()  { return totalDef;  }
        public double fullRange() { return fullRange; }
        public double halfRange() { return halfRange; }

    };  // enum ranges

I use the getter functions to set values for Coarse and Fine knobs:

Code: Select all

case Button_Changed:   // doubleValue is the new button/toggle button value
{
    parametersHaveChanged = false;
    if(component == freqRangeToggle) {
        freqRangeToggle.SetOverlayText(doubleValue == 1.0 ? "High" : "Low");
        currentRange          = ranges.values()[(int)doubleValue];
        SetFreqRange(currentRange);
        parametersHaveChanged = true;
        break;
    }
    if(parametersHaveChanged) {
    	// do follow-up
    }
}

Reid

[ColinP]

I'm actually quite surprised by your position, so I somehow don't think we are going to agree on this and neither of us expect CA to change their code.

I'm making a technical argument based on what is the knob's value. From my POV it's the setting of the knob it's not something else that's overloaded onto the value of the setting of the knob.

For instance a Frequency knob's value on a VCO represents the knob's setting not the actual frequency of the VCO. The actual frequency will be based on some mapping between the knob's value and a base frequency and then this will be modified by any modulation. Trying to store the actual frequency in the knob's value would be insane.

Value and type constraints are a valuable aspect of engineering as well as real life. That's why we don't construct sentences like "Sorry John, I can't make it tomorrow let's meet yesterday or banana instead".

If we need to change a knob's range then yes the old value should be clamped or set inside the new range using a proportional value that maintains the knob's angular position, either way it should be in range as the meaning of the value is the knob's setting not something else. I don't see any other sensible strategy. Having a knob set to some value that isn't representable by the knob is crazy.

In reality CA's range code throws away the old value and sets the new value to the default. So to set a new range one has to get the current value, change the range, clamp or rescale the old value and then set it again. Similarly when setting a new default value the old value is lost so one has to store it and restore it.

But fundamentally my arguments are 1) that value and type constraints are vital tools in reducing the number of bugs when programming. That's why most of us use enumerations rather than ye olde worlde #defines for instance. And by extension if one calls a range method constraining an object to a particular range one would expect it to be respected. And 2) object states should represent their purpose and not be overloaded with vague additional meaning except when this is unavoidable such as type default and null references during construction.

Reading this discussion back it sounds a little heated. Sorry if I've come across as too ardent or zealous but I do have a strong opinion on this subject and I think you may be promoting the dark side.....

[Waverley Instruments]

My position is simply that I'm neither surprised or care that SetValue() works the way it does, although it's not a feature I can see myself (ab)using anytime soon.

But, I guess where our opinions differ, in the unlikely event I did want to do this, nobody's going to stop me, unless you get the CA guys to "fix" it. Then for backwards compatibility, you'll need a request for SetValueNoRangeValidation() too...

It's a feature of the current framework. It might be useful one day, who knows? I certainly don't, and I see little point in forbidding myself from even entertaining such a thought.

I gave up looking at other developers' SDKs through the prism of my own software engineering principles a long time ago. You can thank Apple for that.

-Rob

[ColinP]

So this isn't actually a Spinal Tap spoof then?