Very long sequence of *concurrent* events may otherwise be truncated
because the backend requests a buffer-size of 64 bytes via
snd_rawmidi_params_set_buffer_size().
Since 5.8-245-g3e43585fa, a response hides the dialog Window
in ArdourDialog::on_response (to prevent dialogs windows staying
around unresponsive while Ardour does background work).
The RF is special, and also the only dialog using explicit
add_action_widget().
This is a job for the backend, which should really get the names from the hardware/driver
and make a mapping between a device UUID and the name. Neither the ALSA, JACK or ASIO
backends can do this at present
e.g. stretch-shrink 3712 samples down to 1780.
The filter order defines nFact which can become larger than length - 2
leading to out-of-bounds array access.
e.g. m_ord = 2 -> nFilt = 2, nFact = 6; process < 7 samples (here 6)
A Dialog Window may not be tightly scoped, and may be around
for a while (query settings from the dialog instance). The destructor
may only be called later.
This can be hard to reproduce and I have not been able to work out the steps to
reproduce reliably, but as it is still occuring work around the issue by just
checking the variable is valid before dereferencing it.
Resolves: #7304
eg. at the end of a loop, the session may already be playing the
beginning of the loop. The TransportLooped signal was emitted.
Yet due to playback latency, the audible frame is still at the end of
the loop.
To interpolate the playhead position the UI needs to be able to know:
Relying on the TransportLooped signal is not sufficient because it
does not take playback latency into account.
