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.
This used to be a distinct kind of drag, but ended up being refactored into
something that happens during a regular drag. Has not been used in quite some time.
We need to delete all existing region views before we redisplay the track. This
was removed as part of an "experimental performance optimization" in 4f7a4cd233
but playlist switching is a rare and non-performance limited operation
Note position in samples must be calculated using absolute position
on the timeline. Otherwise the tempo-map is not applied correctly.
Previously this caused issues since the position was first
offset back by _region->position() - time relative to region left
edge - and then the tempo-map was applied.
Another solution identically would be:
(note_start + session_source_start).samples() - _region->position().samples()
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.
UIConfig insert-at-position saves/restores the enum as integer.
This is used directly as parameter for insert_at_combo.set_active().
For this to work, the enum needs to match the order of elements
in the dropdown.
It would be preferable to register the enum, and map the
dropdown entries, but for now this does the trick, without
breaking existing UIConfigs.
PresentationInfo::Change (Properties::selected) is emitted and
handled before Mixer_UI::add_routes() is called. At that point
in time the MixerStrip(s) to be selected may not exist.
Visual selection state was lost.
Furthermore move_stripable_into_view() calling translate_coordinates()
only works after GTK has completed the resize operation.
This lead to the mixer scrolling back to the left edge when creating
new tracks.
Also each selection change caused all tracks to be re-packed.
Now redisplay_track_list() is only called if visibility or order
changes. This signficanly improves performance with large sessions.
