| Age | Commit message (Collapse) | Author |
|---|
|
float <=> string conversions are performed using PBD::to_string/string_to via
XMLNode
|
|
The gain property float <=> string conversion is now performed using
PBD::to_string/string_to via XMLNode
|
|
Not necessary when using XMLNode::set_property API
|
|
There are no float <=> string conversions and they are all now performed using
PBD::to_string/string_to via XMLNode
|
|
There are no float <=> string conversions that require a LocaleGuard and all
conversions are performed using PBD::to_string/string_to via XMLNode
|
|
These are no longer necessary as float <=> string conversion is handled by
locale independent PBD::to_string/string_to via XMLNode::get/set_property
|
|
|
|
|
|
|
|
Also GainControl can just use the AutomationControl's implementation of
get_user_string()
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This exposes an AutomationType dependent abstract version of
inteface_to_internal(), internal_to_interface().
|
|
|
|
|
|
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)
|
|
remove use of
- unbound_min/max
- list->default_value and min/max_y
|
|
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().
|
|
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.
|
|
|
|
|
|
|
|
outside of libardour)
|
|
|
|
for a certain string leads failure to launch the application on Windows 10
|
|
|
|
because reordering a TreeView [pragmatically] does not retain selection.
|
|
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.
|
|
There's no TargetEntry receiver for the custom DnDTreeView<Route> object.
We can just use a default Gtk::TreeView.
|
|
|
|
|
|
|
|
|
|
|
|
|
