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
This fixes several callsites that were passing samplepos_t to get a TempoMetric,
some of them somewhat significant (e.g. VST plugins that want tempo information).
Bad API design on my part, apologies.
This commit combines libs/ and gtk2_ardour because the new private status
of the ::metric_at() call would be a blocking point for git bisect
Old code use the TempoMetric (Tempo + Meter) in effect at the old
location of the tempo/meter to compute the position of the edited tempo/meter,
using a BBT time from the dialog.
But this TempoMetric uses the very tempo/meter that we're editing!
So we have to use previous_tempo() or previous_meter() to construct
the relevant TempoMetric, and if it is the first tempo or meter, then
obviously it cannot move position at all.
Use the new map that is being edited for lookups while changing
the map in the in the GUI. This can changes directly visible
as the map is being edited.
This used to be done directly with the fetch_writable() API
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.
When a tempo map change originates from a drag, we know the required redraws have
already been done. Use a new bool member, ignore_map_change, to tell the Editor
to ignore the map change signal. For all other map changes, do the full reset.
We now simply move markers during drags, and do not seek to create/delete markers.
When the map is changed, we rebuild the markers from scratch. This might need optimization to avoid doing
when the editor itself changed the map.
Previously it was possible that the tempo-curve display was rendered
above a tempo-marker (e.g. create a marker in the between of existing
markers). With the tempo-curve in front, markers on the right
became inaccessible.
Code used to just push back new markers to the end of the relevant list, and
this would then the new marker to be deleted soon thereafter. Instead pass
an interator indicating where to place the marker in the list.
Note that we rely on the use of std::list<T> here to keep the iterator to the
existing marker valid.
Since we're reconnecting visible marker objects with a new map, there's a good
chance that the map will contain map points that don't correspond to the map
points currently referenced by those markers. Thus, tests for address
equivalence will often fail.
Instead, repeat what has been done elsewhere and use the heuristic that we only
allow one point of a given type at the same superclock position.
