pthread-w32 does not support pthread_setschedparam() with
SCHED_FIFO and bails out. While pthread_create() simply ignores the policy
and sets the priority regadless.
This only affects ctrl-surface event-loops & AutomationWatch on Windows.
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.
* remember master-ctrl value on assignment & save with session
* Control/AutomationCtrl only stores ctrl's own value (w/o master)
* virtual AutomationControl::get_value () -> use SlavableAC method
* MasterRecord uses weak-ptr (fixes recursive ~Controllable() deadlock)
This is theoretically dangerous, because a PBD::ID is supposed to be unique, and this new constructor
cannot guarantee that. However, the same danger already exists with the std::string-based constructor
Arodur itself on longer depends on C/C++ locale for saving/loading sessions.
However, the Localeguard is kept for 3rd party plugins: Reset the C locale
to "C" to enforce consisten numerics and portable sessions as well
as verify that no plugin changes the C++ locale.
All uses of this function have now been replaced by PBD::to_string() from
pbd/string_convert.h
Remove this function so that it isn't mistakenly used to perform numeric to
string conversion when the result is being used for serialization as that only
works if the global C++ locale is set with LC_NUMERIC=C, which is the case
currently but may not be in the future.
These are now unused and functionality is replaced by XMLNode::set_property
set_property is a better name as a node can only have properties with unique
names and the property will be set or reset(if it already exists). Changing the
name also makes it easier to transition and test the new API.
No longer need a specialization for bool as PBD::to_string/string_to already
has specializations for bool
Remove template specialization for float as string_to/to_string handles string
representations of infinity
A simple macro for defining the four template specializations required to
convert an enum to a string and back using the existing string_2_enum and
enum_2_string functions. Generally these will only be instantiated in one
source file, I don't think it is necessary to explicitly instantiate any at
this stage.
I would prefer "yes" and "no" as it distinguishes boolean values from numeric
but using "yes and "no" results in PBD::Property<T>::from_string failing to
parse the correct values when opening in an older Ardour version as there is no
specialization for bool.
Using 0 and 1 also results in less change to the Session file.