citations are needed to explain when&how this is useful
the definition of Ripple is "accommodate cut/insert/moves by moving all
regions to the 'right' (later) of the operation by the same amount".
moving markers to the 'left' of the grabbed_region explicitly breaks the
definition of ripple. it makes documentation hard.
furthermore, in a more complicated session with multiple tracks, this behavior
ignores the regions on other tracks and the markers that still might be
associated with them (consider the case where you move the first region
on track A but there are many prior regions on track B with markers over
them)
* move abort_reversible_command into the correct bracketed location
* check for missing _session at top of function to avoid unnecessary nesting
* this fixes an undo 'assert' when an action like "clear xrun markers" has no effect
* this was likely a copy+paste thinko since they are adjacent in the code
Found via `codespell -q 3 -S *.po,./.git,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch -L ba,buss,busses,discreet,doubleclick,hsi,ontop,ro,scrollin,seh,siz,sord,sur,te,trough,ue`
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
Range->Delete is the most common type of ripple-editing imho
... so we need to implement ripple_marks for that common action
* markers inside a deleted range should be removed
* range markers (start+end) need special handling
* remaining markers to the right can be rippled by libardour
* implement undo
* cleaner table layout
* explicit options for bouncing to Trigger and Clip List
* any bounce is added to Source list, so remove that from menu
* format context menus to match "(with processing)"
* use same code structure where possible
Previously every region fragment was added one at a time,
with each emitting signals and updating the GUI. If there are a
few thousand regions Ardour can freeze for a significant amount
of time.
There is still the issue that the GUI freezes after the progress-bar
reached the end: consolidate overlapping ranges after analysis, then
add regions.
And Playlist::flush_notifications still emits
RegionFactory::CheckNewRegion() for every region individually
and RegionListBase::add_region becomes the bottleneck.
But at least adding 7k regions now returns in under 5 minutes
instead of taking over an hour.
The track-height change needs to be applied so that
vertical_adjustment max range is set correctly.
Otherwise vertical_adjustment.set_value() may fail
or scroll to the wrong position.
In 5b3eacd421 `redisplay_track_views()` was moved from
EditorRoutes to Editor. The call was delegated to the idle
thread, potentially collecting multiple calls before performing
the update.
This resulted in "Fit selection" to set the y-offset before the
height-change was applied.
Previously a triggerbox_ui.h change triggered a complete UI
rebuild. This follows the concept of other editor_selection
lists which use forward declarations.
Paul Davis
Ben Loftis
luz paz
Mads Kiilerich
luz paz