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.
Ripple edit undo/redo needs a "recursive diff" of all regions
in the playlist. To work properly owned changes have to be
cleared first, previously unrelated edits were be collected too.
This includes a more consistent version of
7a89d56009 using rdiff() instead of explicitly
saving region diffs.
The undo command needs to be started before calling
playlist->add_region() because that may move automation
or include ripple changes. see the following backtrace:
```
UndoTransaction::add_command
ARDOUR::DiskReader::move_processor_automation
ARDOUR::Route::foreach_processor
ARDOUR::DiskReader::playlist_ranges_moved
ARDOUR::Playlist::flush_notifications
ARDOUR::Playlist::RegionWriteLock::~RegionWriteLock
ARDOUR::Playlist::add_region
Editor::bounce_range_selection
```
Except. it seems automation is moved incorrectly in this case..
* Consolidate access modifiers
* Remove all public member variables
* Only expose required functions, use private
whenever possible
* Rename private members, prefix underscore
* Remove cruft
This combines SessionEvent per playlist. Now per change
there are "only" two SessionEvent::Overwrite events
queued per playlist in the GUI thread for later processing
the Butler.
These are triggered by Playlist::ContentsChanged()
and Playlist::LayeringChanged(), both of which trigger
DiskIOProcessor::playlist_modified.
(Previously there used to be two per region)
playlist->partition() calls DiskReader::playlist_ranges_moved()
which may add Panner and Fader automation state changes.
The reversible command has to be started before calling
playlist->partition(). Simply collecting playlist->rdiff() after
the fact is not sufficient.
This is in preparation to subscribe to playhead cursor position
changes in the recorder-UI.
This change also clean up the API, replacing a public variable
with a const access method and follows #12 of
https://ardour.org/styleguide.html
The issue remains if a track is selected by a "fit-selection" action second
last track covers the whole trackview. Then when scrolling one track up, the
huge track disappears and a smaller track follows, that covers a lot less
space.
-> Proper redraw of the track view is still needed.
When the cursor position is after the last item in the vector,
upper_bound returns the last given iterator, here:
`region_boundary_cache.end()`, which is invalid to dereference.
Furthermore prevent possible duplicate prev/next pair at zero,
when using the video-timelime.
It makes no sense to every align a region start/sync point during a drag or alignment operation
with the last sample of another region. It only makes sense to align with the position immediately
after the last sample of the other region (e.g. directly sequencing regions).
There are various ways to cancel a dialog. Only checking for
RESPONSE_CANCEL is not sufficient. e.g. Esc causes a delete-event.
* Gtk::RESPONSE_CLOSE
* Gtk::RESPONSE_REJECT
* Gtk::RESPONSE_DELETE_EVENT
* Gtk::RESPONSE_CANCEL
* Gtk::RESPONSE_NO
Among others this fixes "Clicking session > open,
then hitting ESC opens the currently selected folder and session"
This fixes an workflow edge-case when undoing a paste in order
to paste at a different location on the same track or automation lane.
After undo, any accumulated paste-offset needs to be reset
Previously this failed if the event was initiated outside
of the canvas (e.g. Zoom buttons).
This also fixes a special case of Zooming to an edit-point at zero.
StripSilenceDialog will now retain its threshold, minimum length, and
fade length values from run to run.
This is done via Session::add_extra_xml() and recalled during the
construction of StripSilenceDialog via Session::extra_xml()
Copyright-holder and year information is extracted from git log.
git history begins in 2005. So (C) from 1998..2005 is lost. Also some
(C) assignment of commits where the committer didn't use --author.
Changing the playlist (remove_region) invalidates selection and
unsets `clicked_regionview`. The region to operate on needs
to be stored for later use.
* Both the session-start and session-end point should follow the is-free option
* Rename the end-is-free option to session-range-is-free, to reflect that change
* This fixes the problem: recording before the start marker would move the Start,
even if the user had already fixed the End marker.
* When splitting in MouseObject, entered_region should get priority over selected regions.
This fixes the unexpected case where you try to split an unselected a region, but
a) nothing happens OR
b) some other region (maybe off-screen) is split
* Range mode now has its own option for splits, which can be:
Clear: the selection is cleared.
Preserve: the selection is left as-is. (default)
Force: all the regions that resulted from the split are selected (forcing a tool change).
* Un-hid the additional config options to select only the regions BEFORE or AFTER a split.
* Note: splits made with Cut Tool should be unaffected by these changes.