Some overzealous locking to track down RequestObject related crashes.
bc0fa4d689 wrongly locked the current event loop's
request_invalidation_lock instead of the invalidation's list lock.
Also Abstract UI is able to delete requests concurrently with with
EventLoop invalidation.
e.g. PortManager::PortRegisteredOrUnregistered and GlobalPortMatrixWindow
so the lock needs to be exposed.
If this solves various issues, mutexes should to be consolidated
(request_buffer_map_lock + request_invalidation_lock) and be chosen
such that there is as little contention as possible.
- music-locked regions are moved by drag beat distance
(will conform to tempo changes over the drag distance)
audio-locked regions are moved by frame distance.
Currently implemented for Region and Range selections.
The new option is false/off by default to maintain existing behaviour. I'm not
sure it should require another option, perhaps Zoom to Selection should be the
default and accessing the region properties dialog can be via Modifier+double
click, but further changes can be made on user feedback etc.
Related: #7112
Add Zoom to Selection (Horizontal) action to access previous behavior.
Remove Editor::temporal_zoom_region as it was duplicate code and broken for
both_axes
Should Resolve: #7112
- when drag-copying MIDI regions, a partial region ctor is used
which can lead to _start_beats being off by a sample.
this in turn leads to 7168 happening, but only if magnetic snap
is used and the regions are copied as a group.
this should fix 7168, but the magnetic snap part is not yet addressed.
read_peaks_with_fpp() already holds _lock, build_peaks_from_scratch()
takes the _lock again.
Depending on glib[mm] and the threading lib it may either result in a
deadlock, or with EDEADLK in undefined behavior when a
non-recursive lock is released twice.
