The former was incorrectly implemented, and the latter has already been tested more
in real life.
We should likely remove ::remove_time also and use shift() there too, but that
requires testing negative shifts more broadly.
Editor::duplicate copies regions one at a time. This lead
to region layeres not being retained, particularly since
Playlist::duplicate() puts the duplicated layer at the top.
Fix "warning: this statement may fall through [-Wimplicit-fallthrough=]",
caused by the misspelling of "fallthrough" as "fallthough" in
editor_ops.cc.
Note that if you use ccache, you'll need to clear its cache to actually
get rid of the warning, because the pre-processed file (with comments
removed) is identical before & after this change, and thus won't get
recompiled otherwise.
Fix the equivalent typos in marker.cc too, though in those cases there's
no actual warning, because presently all the fall-throughs are from empty
cases.
This fixes undo/redo action sensitivity for non-editor
history stack changes.
Notably recording was not undoable, because the butler
thread creates the reversible "capture" command.
When multiple regions are duplicated Playlist::duplicate
is called sequentially for each region.
Previously that lead to a call to Playlist::flush_notifications
after each step, which is rather expensive.
Playlist::ContentsChanged and Playlist::LayeringChanged
trigger SessionEvent::Overwrite and GUI updates.
We now use the same actions in all modes, and the logic is:
1. is there a selected mixer strip and are we in it: if so, delete selected
processors
2. are we in draw or internal mode? if so ..
2a. if there are selected control points, delete them
2b. if not, attempt to delete MIDI notes
2c. done
3. continue with delete operation as before
When cutting multiple regions with Ripple-ALL, removing
the first region ripples the remaining tracks which includes
selected regions on those tracks which are to be cut later.
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.
