Properties::region_fx may not be emitted for add/remove/reorder
cases when no disk-reader overrride is required.
However we need to inform the GUI when such changes happen,
and various UI widgets listen to property changes.
We should not call CueEditor::rec_enable_change() from CueEditor::trigger_arm_change()
because (a) the rec-enable change is coming anyway (b) at the time a trigger is
disarmed, the triggerbox is still rec-enabled. This means that in the end, a MidiView
gets its ::begin_write() method called again before we call ::model_changed()
and that leads it to have non-null _unfinished_live_notes (i.e. we're actively
recording, so do thing).
This allows the user to not have to aim for such precise timing, since they can
hold the note down during the count-in.
At some point the question will arise why we don't do this for controllers
etc. too.
This is a bit ironic, since EventSink is an abstract base class for MidiBuffer, which is
already supported for a flush_notes() call. But we use MidiBuffer::push_back() for that,
mostly for efficiency purposes (write() can insert an event at any time).
There is some weird behavior here, where causing a refill of the listview (e.g. by changing
the status of a port flag) doesn't interact correctly with the scrollbar. I can't find
a solution at the present time, so just grow the listview vertical size to accomodate a lot
more (potential) MIDI ports in both lists (without altering the prefs dialog size)
Allow for 192kHz session (needs testing, by ear and
by down-sampling to 48k vs. running directly at 48k, etc)
Also prevent plugin from loading when sample-rate is out of bounds.
Previously the plugin loaded but was pitched up when the sample
rate exceeded 96k.
This properly handles missing write permissions (that previously
crashed when trying to close the archive).
Also report and error on disk-full or other write failures
such as 4GB file limit.
