Now that both Audio And MIDI tracks support all three record
modes. Monitoring should be consistent. When recording
"Sound on Sound" does cue monitoring, while "layered" (opaque).
and "non-layered" monitors only the input.
Two differences remain: (1) when not recording MIDI tracks still
monitor both Input and Disk (unless Non-layered is set), and
a final special case is that MIDI tracks always monitor input
as fallback. the latter ties in with (2) audio tracks can
use hardware monitoring.
Change assumption that the "pos" argument to AutomationRegionView::add_automation_event is region-relative, by
making it global.
This did not affect non-MIDI automation because that used
AutomationTimeAxisView::add_automation_view() instead.
This fixes an issue when switching formats.
ExportFormatDialog::update_selection iterates e.g. WAV BWV.
If BWV was selected and a user selects WAV the following happpens
1. WAV is selected
2. BWV is deselected
3. Since BWF and WAV are the same format, ExportFormatManager
deselects WAV
This fixes a bug introduced in d06a0d9c9d. The MIDI data
has to be written first, otherwise the CC-event do not exit
and MidiModel::source_interpolation_changed() crashes.
StartupFSM does not catch SessionException from Session::load_state,
but bails out early, after checking `get_info_from_path` instead.
So we have to explicitly report errors.
We now generate a grid from the TempoMap of appropriate "density". Doing this
in the editor just gets things wrong (and partially duplicates the (complex)
logic already present in the TempoMap).
There were many logical errors in the previous implementation. This one is
simpler to read, and appears to work much better.
It also allows the caller to specify the quarter-note subdivision to use when
generating the grid, rather than choosing only between some bar modulo or
quarter notes.
