Revisiting MIDI mapping

It is paramount to restore V1's asymmetrical dual-range normalization:

fNormVal = nMidiVal <= 64 ? (nMidiVal ÷ 128.0) : ((nMidiVal − 1) ÷ 126.0)

In the lower range, one MIDI step = 0.0078125
In the upper range, one MIDI step = 0.007936508

The difference is 0.000124008 or a hundredth of a percent, which is practically undetectable.

MIDI data	Normalized value	Step size
0	0	0.0078125
1	0.0078125	0.0078125
2	0.015625	0.0078125
3	0.0234375	0.0078125
...
60	0.46875	0.0078125
61	0.4765625	0.0078125
62	0.484375	0.0078125
63	0.4921875	0.0078125
64	0.5	0.007936508
65	0.507936508	0.007936508
66	0.515873016	0.007936508
67	0.523809524	0.007936508
...
124	0.976190476	0.007936508
125	0.984126984	0.007936508
126	0.992063492	0.007936508
127	1	N/A

This is the least bad solution to a fundamental problem which is that MIDI data spans an even number of integer values, and therefore can't represent an exact middle. The MIDI data range is [0..127] and its midpoint is 63.5 which not representable in MIDI because it's not an integer.

Fundamental truth: for an integer range to have an exact midpoint, it must have an odd number of values. For example the range [0..10] has an odd number of values (11), and has an exact midpoint (5), with 5 values below it [0..4], and 5 values above it [6..10].

Dual-range normalization will solve the issue of controls not centering properly, just as it did in V1. An epsilon will be still needed to avoid infinitetesimals, but it will be much simpler to implement.

Range Start and End should be normalized real numbers. They can be percentages in the UI, but under the hood, [0..1] should map to the target parameter's natural range.

And: the Line Width parameter should go to zero, because line width is floating-point in Direct2D and line widths between 0 and 1 are supported and visually interesting. The range of Line Width should be [0..50], not [1..50]. This will make Global Line Width behave properly.