the API now provides the option to call ::get_grid() with an iterator which may
be re-used on subsequent calls. This avoids unbounded O(N) "walks" from the
marker preceding the start point of the grid to the start point.
This commit also includes "fast-path" code for the common case of a single
tempo and single meter
* Use an atomic reference count since the freeze-thread
can call use_playlist.
* Remove explicit argument to construct unused playlist
because playlists are unused by default. This also
lead to use-count becoming negative (or rather UINT32_MAX)
* Do not emit signal with source-lock mutex held
* explicitly drop references when called directly; notably from
EditorSources::remove_selected_sources
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
After recovering from a crash, the user still needs to
retain the option to ignore the changes that were done
just before the crash after investigating them (or save them
into a snapshot).
Previously crash recovery unconditionally overwrote the
session file (see discussion on bug tracker).
This allows to move or copy whole sections of the timline (everything
you hear) to a differnt position on the timeline.
NB. Markers and tempo-map are not yet moved, and interpolated MIDI
events are lost.
This fixes a crash when deleting routes, while there are still
automation events queued for the route.
Specifically, SoloControl has a reference Soloable& _soloable; which
points to the parent route. A rt-event can still hold a valid shared
pointer to the SoloControl, even if the route is destroyed.
Calling SoloControl::actually_set_value is fine (the control still
exists due to the shared ptr), but then checking the parent route:
```
if (_soloable.is_safe() || !can_solo())
```
accesses the already deleted route, which causes a crash.
The solution implemented here is to not bind a shared_ptr to the
realtime event. However, since deletion of the route happens in the main
UI thread, there may or may not still be a race.
Grid controllers will largely want to access clips in the order they appear on the Cue page
It is up to the device (and/or its ControlProtocol) to handle banking