TransportMasterManager::destroy () destroys any remaining
TransportMasters which in turn unregister their ports.
However the PortEngine was already destroyed.
Deleting _track_canvas_viewport automatically destroys
any child Items. The LocationMarker's group was already destroyed
when ~ArdourMarker() runs and calls `delete group`.
So first delete the marker, then the canvas
When starting RangePlay while the transport is already rolling
the transport is now stopped (and de-clicked) before locating.
This should not clear the RangeStop event when it is caused
by a RangePlay request.
Since 4ad1c19166 "select all" etc no longer plays
all notes, and possibility to get a loud speaker-blasting
cacophony is greatly reduced.
We may still want to add some additional heuristics, or
special case drawing new notes/hits, but for now this it
is sensible to enable this by default.
Session::possible_states correctly filters files
and also directly returns sorted base-names.
We can remove the redundant `get_state_files_in_directory`
API now.
see also 193b35e885
Editor::motion_handler() only updates the snap-cursor
when no drags are active. While dragging, Drag::motion is
responsible to set the cursor accordingly.
In many cases the snap-cursor simply remained stuck at
the most recent position. Since in many cases
(e.g. RubberbandSelectDrag) it makes no sense to show the
cursor, so Drag::start_grab now hides the cursor by default.
This also fixes cases where the cursor is shown, but
was displayed in the wrong location.
Besides, it can happen under normal circumstances that the
Editor window, or any other window with clocks (prefs) is
visible while no session is loaded.
In rare cases DiskWriter::run() may call finish_capture()
concurrently with the butler thread from transport_stopped_wallclock,
this can lead to memory corruption (CaptureInfo).
Using a Mutex here is not great, but it is not usually contended
and better than crashing at rec-stop.
We should probably change DiskWrWiter::_was_recording into an
atomic bool, and use CAS to prevent concurrent calls.
A rec-region is added to the streamview just like any other region
(::add_region_view_internal). This subscribes to region->DropReferences.
When the DropReferences is handled first by StreamView::remove_region_view
the corresponding RegionView is destroyed.
This can happen even while recording is still active, eg. when locating
(which stops the current recording).
MidiStreamView::setup_rec_box() is called and crashes in
`dynamic_cast<MidiRegionView*> (rec_regions.back().second);`
due to a use after free.
Strictly speaking this is a logic error in how ::setup_rec_box()
determines if to add or remove the rec-box. But due to the
asynchronous nature of signal emission and transport-state changes
the best solution is to destroy the rec-region at the same
when the RegionView is destroyed.
To reproduce:
* create a session with a MIDI track
* disconnect the input (empty MIDI regions are removed)
* Preferences > Transport > *enable* latched-record-enable
* use the Dummy backend's MIDI generator
* connect Hardware > MIDI > MMC -> Ardour misc > MMC in
OR use JACK-transport to locate while recording.
