the rest from `tools/convert_boost.sh`.
* replace boost::function, boost::bind with std::function and std::bind.
This required some manual fixes, notably std::placeholders,
some static_casts<>, and boost::function::clear -> = {}.
previously, _chunksize =
```
minimum_disk_read_bytes / sizeof (Sample)
```
can become larger then actual allocated ringbuffer:
```
audio_playback_buffer_seconds * sample-rate
```
In which case the buffer was never filled.
The disk writer has similar issues
Previously loop-wrap around asked the butler to perform
a unnecessary seek operation next time it is summoned.
If the butler is then summoned for a PostTransportOverWrite
event, the seek causes a DR::Underrun.
Mute and Panner are the only automatable Route owned controls
(that are not managed by a processor). So they need special
casing to be moved when moving a region.
AudioPlaylist::read first clears the buffer passed to it, in
order to sum all layered regions into the buffer.
This cleared data in the ringbuffer that is concurrently being
used for playback.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
This is never for inline references to parameters, only for starting parameter
documentation blocks. The "@p" command is for this, although unfortunately
Doxygen doesn't actually do anything with it and it's just an alias for code
text.
This reverts commit 96ebac646d.
There are some valid cases where refill is called from the GUI
thread. e.g adding tracks, or adding channels to an existing track.
Loop Location start="a1665678660" end="b145920"
Loop-end (at 122BPM) is a2109859636
at 48kHz this is sample 1794098.32
Now play the loop and play sample 1794098 = a2109859248
Range::squish start: a1665678660 end: a2109859636 squish: a2109859248
squish() does nothing, since there are still 388 superclock-ticks
until the end of the loop.
However, DiskReader::get_midi_playback convertes the value back
to samples(), this leads to effective_start == loop_end;
resulting in an endless loop.
Thanks to MikeLupe to provide a session to reproduce this issue.
"While 'atomic' has a volatile qualifier, this is a historical
artifact and the pointer passed to it should not be volatile."
Furthermore "It is very important that all accesses to a
particular integer or pointer be performed using only this API"
(from https://developer.gnome.org/glib/2.68/glib-Atomic-Operations.html)
Hence initialization of atomic variables is changed to also use
this API, instead of directly initializing the value.
This also fixes a few cases where atomic variables were
accessed directly.
see also libs/pbd/pbd/g_atomic_compat.h
In rare cases it can happen that the GUI thread results in
a call to DropReferences(), while the backend (RCU) still has a
reference to the track and processes the track.
However the call to DropReferences, DiskIO processor will
have cleared the pointer to _track, leading to segfaults when
the processor runs.
Since the DIO processor is owned by the track, one cannot directly
pass a shared_ptr<Track>. That would keep the Track around forever.
However the DIO processor cannot exist without a track passing
a reference is acceptable.
The cross-over point of an exponential fade occurs further towards
start of the fade. This increases consistency of cross-fades moving
the cross-over point to the center of the fade.
Also looped material is likely correlated in which a linear fade
is more appropriate.
