the API now provides the option to call ::get_grid() with an iterator which may
be re-used on subsequent calls. This avoids unbounded O(N) "walks" from the
marker preceding the start point of the grid to the start point.
This commit also includes "fast-path" code for the common case of a single
tempo and single meter
These were not thread safe, and could not be: to be useful, a thread looking up a time
conversion could cache the result, but it would be using the global (shared) copy
of the map (because lookup is read-only, and so no write-copy is required). But
inserting into the lookup table wasn't lock protected (and shouldn't be because otherwise
that defeats the point of RCU).
So just drop it.
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
