Deleting _track_canvas_viewport automatically destroys
any child Items. The LocationMarker's group was already destroyed
when ~ArdourMarker() runs and calls `delete group`.
So first delete the marker, then the canvas
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.
Tempo Map updates can change a region's position/length, in which case
region-automation may follow the region, and DiskReader:: playlist_ranges_moved
will save additional undo information.
These MementoCommand(s) need to be included in the undo operation.
The class now has two separate methods for setting a duration or a point
value. They MUST be used appropriately, because their behavior is different.
When ::set_duration() is used in timecode mode, an extent (inclusive-end
length) is shown rather than a length.
Some objects, such as the TimeInfoBox, now deliberately shown an inclusive end
for their "end" clock, but this not universally followed, pending more feedback
from users and investigating of conventions in other DAWs.
Locations::ripple() skips these markers when the ripple action is committed.
...but the editor moves the marker-items as a visual aid, before actually
committing the changes to Locations()
...so the editor needs the same logic, to avoid visually inconsistent behavior
This commit leaves two issues outstanding:
1. unclear/ugly semantics for drag operations that reset the GUI thread's tempo map to the writable copy
2. undo/redo for the tempo map
These will be addressed in future commits
Major changes: do not delete and recreate markers and curves for every tempo map
change, attach tempo curves directly to their (preceding) tempo marker, notable
cleanup of TempoCurve class to remove unnecessary members.
More tweaks expected since algorithm for matching markers and tempo map
points is not correct yet.
The objects referenced by markers point to the copy of the map held by the per-thread ptr. But
the edits must be done on a writable copy of the map. ::reassociate_metric_markers() fixes
the references to use the writable copy, so that when we pass references to the objects in the map
to the writable copy, it will find them and modify them (rather then ones in the previous
generation of the tempo map)
After beginning an edit operation with TempoMap::write_copy(), the tempoPoint and meterPoint objects
referenced by markers are incorrect, since they refer to the original map, not the copy we are working
on. Fix this with Editor::reassociate_metric_markers()
Some instances requiring this fix may still remain