The diskreader uses the route's monitoring state when deciding whether or not
to fetch MIDI data for playback. Route::monitoring_state() would determine
whether or not we were already rolling to affect its return value. However,
using Session::transport_rolling() is affected by pre-roll and consequently
returns the wrong value during transport startup. Instead, we now use
::transport_state_rolling() which ignores preroll conditions. This leads to the
DR actually reading MIDI data from the initial playback position, which fixes
this issue.
Note that the bug only occured if the track or the session was rec-enabled. The
monitoring state value was always correct for non-rec-enabled conditions.
When using a UADx plugin on a Mono track in Ardour, the plugin
is configured to be Mono. by calling `setBusArrangements`.
The call succeeds and querying the Bus layout via `getBusArrangement`
as suggested by https://steinbergmedia.github.io/vst3_doc/vstinterfaces/classSteinberg_1_1Vst_1_1IAudioProcessor.html#ad3bc7bac3fd3b194122669be2a1ecc42
confirms this. The plugin acknowledges the speaker layout
for both input and output (Vst::SpeakerArr::kMono = 0x80000)
```
Input BusArrangements: 0 chan: 1 bits: 80000
Output BusArrangements: 0 chan: 1 bits: 80000
```
but UADx plugins crash later during process() if any of the lower
bits are unset and the bus is enabled.
PS. The plugin does NOT crash as long as a lower bit
(Vst::SpeakerArr::kSpeakerL or ::kSpeakerR) remains set
in addition to kMono.
Directly loading a new session (Session > Recent) stops the engine
when the sample-rate mismatches. All is fine.
When closing a session (Session > Close), the engine is kept running.
Loading a different session with different sample-rate shows
the "SR mismatch" dialog. Reconfiguring the engine then does not call
`Session::immediately_post_engine` again.
AudioBuffer::read_from() only replaces data within the given
range (offset .. n_samples + offset) leaving the rest of the
buffer untouched.
With in-place processing, where the same MIDI buffer is used
for input and output, each sub-cycle must only clear the
processed range, while leaving the rest of the buffer
untouched.
MIDI playback used samples instead of usec.
MIDI capture used time-stamp from previous cycle.
buffer-size changes were not applied to MIDI port latency
This is a tentative change and if it proves unwise we can back it out.
I just find it awkward to have to change modes to draw when it is
completely obvious whether I am drawing or not.
