Age | Commit message (Collapse) | Author |
|
float <=> string conversions are now using PBD::to_string/string_to via XMLNode
for locale independent conversion and these guards are not necessary.
|
|
ARDOUR::AutomationList is no longer using LocaleGuards as float <=> string
conversion is using PBD::to_string/string_to so the reason for adding these
guards as per comment no longer applies.
|
|
PBD::ConfigVariable uses PBD::to_string/string_to methods so this LocaleGuard
is no longer necessary.
|
|
ConfigurationVariable is now using PBD::to_string/string_to for float <=>
string conversions so LocaleGuard is no longer necessary.
|
|
I think this was only to protect the float <=> string conversion in
Session::setup_click_state related to click gain which is now using
PBD::to_string/string_to and so no longer necessary.
|
|
Route and all members are now using locale independent string <=> float
conversions.
|
|
All float <=> string conversions are done using PBD::to_string/string_to via
XMLNode and LocaleGuard is not necessary.
|
|
This presumes that all ControlProtocol implementations either use
PBD::to_string/string_to for float <=> string conversions, which is now the
case.
|
|
All float <=> string conversions are done using PBD::to_string/string_to via
XMLNode so no LocaleGuard is necessary.
|
|
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 in MidiDiskstream state methods,
these guards must have been to protect conversions in Diskstream state methods
which are now using PBD::to_string/string_to via XMLNode so no longer need
guarding.
|
|
All float <=> string conversions are performed by PBD::to_string/string_to via
XMLNode.
|
|
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.
|
|
All float conversions are using PBD::to_string/string_to via
XMLNode::get/set_property API
|
|
Property conversions <=> string use PBD::to_string/string_to so float
conversions don't need to be protected by a LocaleGuard
|
|
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)
|
|
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
|
|
|