Age | Commit message (Collapse) | Author |
|
GUI interface values are always in the range 0..1 so there's no abiguity
with trunc()
|
|
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 exposes an AutomationType dependent abstract version of
inteface_to_internal(), internal_to_interface().
|
|
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.
|
|
Note: Control-surfaces should always use interface_to_internal()
and internal_to_interface().
|
|
Supports i18n, is case and whitespace insensitive for more resilent parsing.
|
|
|
|
|
|
|
|
This deprecates Evoral::midi_note_name(). we don't maintain i18n
for libevoral.
|
|
|
|
and used. The controls now own their own state, rather than proxy for state in their owners.
Massive changes all over the code to accomodate this. Many things are not finished. Consider this a backup safety commit
|
|
gcc6 returns a float for "rint ((float) val)"
|
|
|
|
This allows it to be used everywhere, as intended
|
|
|
|
|
|
|
|
|
|
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.
|
|
Set default range to [0,1] since [0,0] is problematic and useless anyway.
|
|
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.
|