According to the cdrdao man page, they should be defined as follows:
INDEX MM:SS:FF
Increments the index number at given position within the track.
The first statement will increment from 1 to 2. The position is
relative to the real track start, not counting an existing pre-gap.
To mitigate concurrent rendering, the waveform cache adds a random
range of pixels centered around the visible waveform.
Alignment is using integer half_width = width_samples / 2;
This always aligns the left-edge to the left-most cairo-pixel.
This fixes an issue with moving moiree patterns in waveforms when
zooming vertically (which invalidates the cache and uses a
different random number of pixels),
The left-most part may be a partial block of a given "sample per pixel"
range. Also previously there was an off-by-one [block] in case
sample_pos was an even multiple of samples_per_visual_peak.
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.
