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
Now using a globally-scoped static variable which is updated by the
AudioEngine whenever an SR change occurs. Defaults to 48kHz and can
be used even before there is a backend.
* 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
Due to recent changes, when the master bus is disconnected its
private port latency was never unset. This lead to misalignment
when using stem-export if master (or monitor) output was not
connected.
This will eventually have to be fixed, currently split-channel
files are not correctly tagged and post process commands
are only emitted for the last file.
But fixing this is complicated, so meanwhile a workaround is used.
Eventually this commit should be [mostly] reverted!
When a track's output is not connected, we assume
its output playback latency matches that of the master-bus.
This is to prevent the track's output latency to float
freely (see also a556e96ed0).
This failed if a track is connected to another track which is
not connected.
On Intel systems ArdourCanvas::COORD_MAX (1.7e+307) was rounded
to (gint) -2147483648. gtk+ treats negative window size-requests
as 1px.
However on ARM, COORD_MAX was truncated to +2147483648, gtk+ limits
this to 65535. Most WM/Xwin systems cannot handle windows this large.
It also exceeds the max size of cairo [image] surfaces.
This issue was introduced in a1c67b4ad7
when "natural_size" was removed. Before that change infinitely large
canvas had a natural_size of 2x2 px.
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.
