This allows to indicate that a control should by default be displayed
inline in the mixer-strip.
Previously that was hard-coded for and enabled for send-level
controls only.
It's a well established convention that pan y-axis automation,
or vertical uses (top) +1 for left.
This special cases rotary knobs (and horizontal sliders) to retain
a clockwise movement (or movement to the right) for panning to the
right.
Explicit cast to float (rangestep is unsigned int) when calculating
interface steps.
Also prefer to round to nearest value-point (rather than round-down).
And it's actually mostly moot. interface_to_internal maps
any range to 0..1.
The GUI could just hardcode min/max 0, 1 and steps 1/30, 1/300.
Except for controls that have explicit range-steps & ctrl surfaces.
This explicit case should never have existed in the first place.
Plugins can always implicitly exceed the range and are expected to
cope with out-of-range values (e.g. meters when fed with a peaking signal
may return an out-of-bounds value)
This allows complete mathematical description of a given parameter
and parameter values.
Semantic type abstraction is reserved for Ardour::ParameterDescriptor.
Shoot for roughly 30 steps for all controls.
Always keep sensible step information in ParameterDescriptor and just convert
for the UI.
This is a little weird, but it's less weird than it was before, and works.
Among other things, this means that automation controls/lists have the actual
min/max/normal/toggled of parameters, and not those inferred from the Parameter
ID, which is not correct for things like plugin parameters.
Pushing things down to the Evoral::ParmeterDescriptor may be useful in the
future to have lists do smarter things based on parameter range, but currently
I have just pushed down the above-mentioned currently used attributes.
