When using "VS" the numeric control shows the "default speed"
when not rolling. Then when starting to roll default speed will
be the actual speed.
Previously the shuttle was not updated when `last_speed_displayed`
was the current speed. This dated back to before "VS" showed
default speed.
Previously [GtkApplicationDelegate applicationShouldTerminate:]
triggered both StartupFSM::queue_finish and ArdourUI::queue_finish.
Both of which registered an idle-callback to call ArdourUI::finish.
heap-use-after-free. Marker is deleted (and re-created), when
the tempo-map edit is aborted:
```
#0 0x7f77528ac017 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
#1 0x55f81062800d in TempoMarker::~TempoMarker() ../gtk2_ardour/marker.cc:794
#2 0x55f80ffb2fc0 in Editor::reset_tempo_marks() ../gtk2_ardour/editor_tempodisplay.cc:205
#3 0x55f80ffb2b19 in Editor::reset_metric_marks() ../gtk2_ardour/editor_tempodisplay.cc:185
#4 0x55f80ffb49fb in Editor::tempo_map_changed() ../gtk2_ardour/editor_tempodisplay.cc:301
#5 0x55f80ffbdf00 in Editor::abort_tempo_map_edit() ../gtk2_ardour/editor_tempodisplay.cc:850
#6 0x55f80fcf967a in TempoMarkerDrag::finished(_GdkEvent*, bool) ../gtk2_ardour/editor_drag.cc:333
```
Since no movement occurred, the tempo-map was not changed.
however we need to drop the lock and writable thread-pointer...
This allows UI scripts (saved in preferences) to access
os.* functions (non-sandboxed), while preventing other
scripts to do so.
Lua scripts that can run os commands can execute arbitrary
code on the system. While this is a nice feature, it can be
equally dangerous.
Without this, Editor::button_release_handler() will handle a button3 press
without checking for an active drag, resulting in two drags, and two reversible
commands, and an abort ...
This involved a significant change in event handling for automation region views,
but it brings it into line with how it works for other things. On button press
we initiate a drag, then if no motion occurs, the Drag returns false during
finalization, and only then do we continue through Editor::button_release_handler()
to eventually end up in ::add_automation_event().
Although it is a substantial change, the fact that it now works the same
way for audio regions, automation regions and automation tracks seems
like a definite plus.
