min/max processing

[funwithtriangles]

So I've been thinking about this an while previously my feeling was that all param values should be normalised, I'm now thinking the opposite. Below is my proposal for how we should handle min/max stuff with params.

All node values are absolute, not normalised

The values for nodes in state should match exactly what comes into the sketch. No final interpolations before the values are handed to the update method, this should happen at the input level (including UI sliders).

Nicer sliders

With absolute values being displayed, it's nicer for the users. Position X really is the final value, not some weird calculation of 0.75 * max or whatever. This is also means we can have sliders display a little pip to show where 0 is, which I think is very helpful sometimes to visualise that a value is going into the negative.

sliderMin and sliderMax

For param config, instead of minValue and maxValue, we should be using sliderMin and sliderMax. As described by their names, these two properties indicate the min and max value of the associated slider for that param. If a user wants more range on their slider, they adjust these values.

Users shouldn't be scared to change sliderMin and sliderMax

In old Hedron, changing the min and max value of a param could have some unwelcome side effects. You may have all sorts of inputs setup for a param, and changing the min and max can mess all that up. Because we'll now be using absolute values, changing these ranges doesn't affect previous work, it just means users can slide further.

Param values can go outside of sliderMin and sliderMax

sliderMin and sliderMax is just a way to help visually represent the value on the slider. Some input (or a timeline keyframe) can happily go outside of this range. The slider component should ideally represent this to the user (e.g. the left border of the slider goes red if under the range, right border goes red if over the range).

Inputs

Inputs have their own separate range settings. If we have an audio input on a param, it looks at it's own min and max range settings, and nothing else. When first creating the input for a param, the input logic might want to copy over sliderMin and sliderMax as some sensible defaults, but after that, it's completely independent. A user may want to increase the sliderMin and sliderMax so they can better see the output of their audio input on the slider (e.g. it's clipping outside of the slider max), but nothing breaks if they don't do this.

[funwithtriangles]

@cale-bradbury what do you think? This is a bit more inline with how you had it setup in your PR for the temp repo. Do you plan on getting that PR over to the main repo now? If you're too busy I can also take this on and copy over what you did so far.