* update AFL position when preference changes
* "after post-fader processors (before pan)" is before
the main-out (not at the end).
* Fix "immediately post-fader":
The amp, when added was the last element. ++after_end then
made the iterator point to .end()
This likely worked in the past when the monitor send was added
immediately after adding the fader/amp before any other processors.
When creating a session from the Editor (after Session > Close,
or directly via Session > New) the engine-dialog needs to be displayed
to allow configuring the sample-rate.
This also consolidates scripted session setup: meta_session_setup()
is now called from build_session(), instead of all callers.
When there is no overlap (Evoral::OverlapNone) of local transport
position and the record-range, MIDI data does not need to be
offset.
This matches audio recording: Only write to the capture ringbuffer
when there is an overlap.
(There is still some unknown, unresolved discrepancy remaining
to be tracked down)
to_write must not exceed `total = _samples_pending_write`.
If the write succeeds (events spanning `to_write` samples are written)
to_write is atomically subtracted from `_samples_pending_write`.
This produces synchronous events on Audio and MIDI ports.
One rvent per second, exactly at every second since engine-start.
MIDI: C-4 Note-on/off (1 sample long)
Audio: +1/-1 transition:
+1 in sync with Note-on,
-1 in sync with Note-off
the value is used by the parser context; the old code called it only after the *first* parser context
was created. therefore the first XMLTree::read() call has its behavior determined by libxml2's default
for this value, rather than by our explicit choice (do not treat whitespace as a note). All subequent
read() calls will use our value.
This variable inside libxml2 is actually per-thread, which just increases the stakes for calling
xmlKeepBlanksDefault() at the right time
Some builds of glib on macOS end up delivering IO_PRI when IO_IN is also set. This differs from our own build stack
version, but it isn't really an error, so we should handle it.
