This works around for compilers with non-static-data-member
initialization.
spinlock_t is-a struct { lockType _; } and BOOST_DETAIL_SPINLOCK_INIT
initializes the first member of the struct.
All defines of BOOST_DETAIL_SPINLOCK_INIT include c-style curly braces
to initialize the struct's data member.
However, modern C++ compiler interpret the braces differently resulting
in copy constriction of the initializer.
Depending on implementation, d8ae3fd may only construct the spinlock
once to `sl_init`. Later it is only copy-constructed and that leads to
compile and/or runtmime errors.
e.g. gcc-8.3 fails to compile
error: use of deleted function ‘boost::detail::spinlock::spinlock(const boost::detail::spinlock&)’
This fixes an issue with
* XMLNode::get_property(const char*, T&)
* XMLNode::set_property(const char*, const T&)
resulting in
string_convert.h:77: error: 'long int' is not a class,
struct, or union type
buffer-size = periods * period-size
Previously, buffersize was used for period-size.
This fixes an issue with a dedicated .asoundrc configuring a specific
period-size or buffer-size that has to be exact.
Ardour's device configuration failed in this case.
This has not been an issues since most hardware devices offer a wide
range: 8 < period-size < 262144 ; 16 < buffer-size < 524288.
Only a subset of which (32 .8192) is allowed by Ardour.
Ardour's Tracks/Routes are not capable of handing more than one
MIDI port per per route properly. Most Plugin standards don't support
this either.
However, at this point in time IO::ensure_ports_locked() is not
limited by this restriction!
It is still possible to indirectly add a 2nd MIDI data-buffer
and output-port via plugin pin-management, or simply plugins with
two MIDI output ports when using flexible I/O.
In theory different UIs can show different meter-types, so it
can make sense to maintain the type in different places.
MeterType is a bit-set and PeakMeter implementation provides for this.
However, this is not being used, and the current implementation
was rather fragmented, cross-connected signals to keep types in sync,
allowed inconsistent meter-types in GUI and backend.
MeterType is now kept by meter itself, however it is still
saved/restored as part of the Route state.
N.B. This change breaks the API, various methods have been renamed
for consistency.
