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)
Session::destroy() calls drop_references(),
which leads to InternalSend::send_from_going_away()
calling InternalSend::propagate_solo().
This looks up the SoloControl to test soloed_by_others(), incl.
and VCA maters. Those VCAs however may already have been destroyed,
and (weak pointer) _master.lock() fails.
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
The distance is between a given offset in the buffer (probably a
read position at some point in time) and the write ptr. Any data after
the write ptr is "old" and not readable, and thus not worth overwriting
since we would not read it anyway.
When a button has a fixed size, there's no need to call queue_resize().
This fixes an issue with the ArdourClock info displays when slaved.
The Timecode and Delta display text changes in small intervals and
caused excessive CPU load due to GUI size-requests + redraws.
* use left-aligned sign symbol with "sample" unit.
When the delta value jitters in decimal places (e.g. MTC)
it's otherwise no possible to discern + vs -.
* Use white text by default (not green)
An engine restart sends dis-connect messages for the reverse
port-mapping (after making the connection):
Connect: system:midi_capture_41a56f90 -> ardour:MTC in
Connect: system:capture_1 -> ardour:LTC in
DisConnect: ardour:MTC in -> system:midi_capture_41a56f90
DisConnect: ardour:LTC in -> system:capture_1
This lead to TransportMaster being marked as inactive.
This is likely an issue that should be fixed elsewhere, but in
case of JACK, we likely do not have control over this.
