see also 25c0bd9274
play, locate, play resulted in the video-monitor showing
the target frame shortly, and play a few frames from the old
location.
This was due to locate happening async. Click to locate
directly sends the new location:
```
VideoTimeLine::manual_seek_video_monitor
ARDOUR_UI::update_transport_clocks
CursorDrag::fake_locate
CursorDrag::start_grab
DragManager::start_grab
```
CursorDrag::finished unset _dragging_playhead before the
call to resuest_locate(). Meanwhile playback continues.
The TransportFSM is now responsible for deciding what to do at all transport state transitions. The Session (via the TransportAPI) merely
provides mechanism (locate, start, stop, set_speed). Default and most recent speed requests are managed by the TransportFSM too
This fixes another deadlock calling send_change with the
Playlist's RegionWriteLock held.
In this case due to "MIDI region copies are independent"
when duplicating MIDI regions.
```
ARDOUR::Region::send_change ()
PBD::Stateful::apply_changes ()
ARDOUR::RegionFactory::create ()
ARDOUR::RegionFactory::create ()
ARDOUR::MidiRegion::clone ()
ARDOUR::RegionFactory::create ()
ARDOUR::Playlist::duplicate ()
```
This fixes various issues with signal emission(s) when creating
regions from withing playlist operations.
eg. Playlist::duplicate() takes RegionWriteLock() and then calls
RegionFactory::create().
see also 6a82aa392c
This is an initial work-around for signal emission with
Playlist:region_lock held:
Playlist::duplicate() takes RegionWriteLock() and then calls
RegionFactory::create(). The newly created region does NOT have
property-changes suspended, and the RegionFactory can change
region-properties which results in signal-emission.
This in turn can lead to a call Editor::session_gui_extents()
-> ARDOUR::Playlist::get_extent() -> Playlist::RegionReadLock
which deadlocks: https://pastebin.com/84rSbsA3
Eventually we need a mechanism to create regions with
->suspend_property_changes() and add it to the playlist's
thawlist (pass a thawlist to the region-factory).
RegionInsertDrag or Consolidate Range or any other operation
calling Playlist::add_region() previously triggered RangesMoved()
which resulted in DiskReader::move_processor_automation()
NB. insert + ripple still moves automation correctly.
Playlist changes do not include region-property changes.
When inserting a region, position(s) of other Regions may
change and those changes have to be recorded explicitly (for now).
see also RegionRippleDrag.
The undo command needs to be started before calling
playlist->add_region() because that may move automation
or include ripple changes. see the following backtrace:
```
UndoTransaction::add_command
ARDOUR::DiskReader::move_processor_automation
ARDOUR::Route::foreach_processor
ARDOUR::DiskReader::playlist_ranges_moved
ARDOUR::Playlist::flush_notifications
ARDOUR::Playlist::RegionWriteLock::~RegionWriteLock
ARDOUR::Playlist::add_region
Editor::bounce_range_selection
```
Except. it seems automation is moved incorrectly in this case..
TmpFileRt::get_samples_written() returns the number of
samples written *to disk*. It is only valid after the FileFlushed
signal is emitted.
This fixes an assert() with Limiter and Analyzer being configured
with a too low total sample-count, leading to an overflow in
the analysis graph array.
