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.
Ardour's "pbd/i18n.h" needs to be included last,
after any include that may indirectly pull in getext or libintl.
For that reason "pbd/i18n.h" must not be used in header files either.
In theory we only need to do this if the use of a loop for a given overwrite differs
from the previous refill or overwrite. However, keeping track of this is hard, and
this way effectively enforces the notion that if we do the arithmetic correct,
for cases where there's no change in the use of a loop location, this ends up
being a no-op (i.e. we are resetting it back to its current value)
There's no need to fill the whole buffer, because we do not consider the whole buffer readable.
This uses the recently-added PlaybackBuffer::overwritable_at() API to compute the correct
amount of data to overwrite
Since 4508d5bab this only happened after a fade-out.
Currently there is no fade when transport is stopped and monitor
mode changes MonitoringDisk <-> MonitoringInput.
DiskReader::DeclickAmp is only used for data from disk.
Fading live-input data passing through will likely need another
Amp.
Previously it was possible that
* declick_out = true,
* target_gain == 0, cur_gain != 0 (fade out active)
* speed != 0, disk_samples_to_consume > 0.
So the disk-reader advanced the playback_sample, but since
declick_out is active, the read from the ringbuffer was not committed.
When export is done, nothing a MIDI-only track will reduce the gain ("goto midi" inside
DiskReader::run() and the "declick-in-progress" state will be permanent
