The float conversion in Diskstream::get_state is now done using
PBD::to_string/string_to via XMLNode::set_property API.
There was no explicit LocaleGuard protecting the string -> float conversion to
remove so it was probably protected by the caller.
Saving the new ControlList interpolation methods (enum) breaks loading
the session in older version. The session-format version will
need to be increased.
Until then:
* Fader automation + region gain envelope uses linear fades
* The automation-line visible in the GUI does not match the actual fade
(the y-axis is log/exp-scale, the fade is linear)
* Adding new points on the line is not using the correct initial value
* Custom changes of interpolation mode are not available
Neither of these issues is a regression.
The Control and ControlList uses the raw value (eg. coefficient for gain,
Hz for frequencies) and those Lists are stored in existing sessions.
In the vast majority of cases interpolating automation values using exp/log
scale for dB, freq makes more sense -- it's also what the fader does.
Adding additional interpolation methods is future proof (we might at allow
to even add different methods per automation point (to the next) like other
DAWs do.
Currently it's mainly used in preparation for consistent GUI automation-
lanes. Between 2 points there's always a visual straight line.
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.
Functions formerly in ardour/util.h and some more functions.
The main motivation is libevoral which can use libpbd but not libardour.
The eventual goal is to consolidate various different interpolation,
scaling and deflection methods.
Trim automation is planned via SlavableAC as normal AutomationMode.
Some of this code have a revival (a special "Trim+Preview" state
before merging Automation but that has to be more general than Pan & Gain.
The first click to select a new stripable may actually un-select strip.
counting and ignoring this leads to strange behavior.
Also when the selection_counter hit zero, VCAs were not ignored.
whatever this workaround was good for, it's more trouble than it's worth.
As side-effect this also improves DnD + Gtk::Entry behavior with stock GTK.
