Make click & drag in the left-hand half of a region with the Timestretch
tool stretch the region on its left, leaving the end position of the new
time-stretched region in the same place as the end of the original.
Deleting _track_canvas_viewport automatically destroys
any child Items. The LocationMarker's group was already destroyed
when ~ArdourMarker() runs and calls `delete group`.
So first delete the marker, then the canvas
* correctly handle clicks on the immediate right or left of a beat line
* prefer Mid-Twist and End-Stretch terminology over Twist and Linear
* static-tempo vs ramped-tempo is orthogonal to mid- and end- drags (TODO)
We now use the same actions in all modes, and the logic is:
1. is there a selected mixer strip and are we in it: if so, delete selected
processors
2. are we in draw or internal mode? if so ..
2a. if there are selected control points, delete them
2b. if not, attempt to delete MIDI notes
2c. done
3. continue with delete operation as before
When cutting multiple regions with Ripple-ALL, removing
the first region ripples the remaining tracks which includes
selected regions on those tracks which are to be cut later.
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.
This concept from 2007 is no longer required Temporal::get_grid
already limits the number of grid-lines depending on the step
size (mod-bar, beat_div) and start/end positions.
Import via Drag/Drop previously worked by selecting a track,
and then importing to the selected track.
This approach fails when the selected track is in a track-group,
and selecting the track also selects other tracks of different type.
Now the track to drop onto is passed directly passed through to
::finish_bringing_in_material as existing_track.
Found via `codespell -q 3 -S *.po,./.git,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch -L acount,ba,buss,busses,discreet,doubleclick,hsi,ontop,retrn,ro,scrollin,seh,siz,sord,sur,te,trough,ue`
An attempt to satisfy #8848.
Add a new action, "fork-regions-from-unselected", which unlinks all
selected MIDI regions from any unselected regions, but maintains links
within the selection, and add the new action to the region MIDI context
menu as "Unlink from unselected". Rename the existing "fork-region" action
to "fork-selected-regions", and amend the existing "Unlink from other
copies" menu item to "Unlink all selected regions" to (try to) clarify the
difference.
Attach the <Tertiary>U default key-binding to the new action: I personally
think it's generally slightly more useful (otherwise I wouldn't have
implemented it), though I'm not that fussed.
In the case that there's only one MIDI region selected, or that none of
the selected regions are mutually linked, both actions will have exactly
the same result. Ideally, we'd only show a single menu item in this case,
but that would require (a) implementing a function to check whether the
selection contains any linked regions, and (b) making the region MIDI
context sub-menu dynamically generated, so that it can change based on the
result of that function, neither of which I've tried to do yet.
The track-header (gtk) is packed with 1px box spacing. This
is added at the top of each box (best seen by looking at the
group-tab vs track-header alignment in the editor).
However the actual track separator line on the canvas is at the
bottom of each track, aligning with the top of the next track
or automation-lane.
The first track however lacks a separator at the top, which
needs to be provided by the ruler. Once the canvas is scrolled
this ruler/canvas separator overlaps with the bottom separator of
each TAV.
Using ruler Rectangle::set_outline had various issues.
The outline extends outside the rectangle. It bled into the
video-timeline instead of the canvas' top y-axis pixel.
Also the separator was above the video-timeline, not above the
canvas. Hence a dedicated separator Line is preferable.
It also provides a consistent separator if no rulers are visible.
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.
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.
Stem-export defaults to use selected tracks. This retains
the selection, so focus remains. Repeat stem export will use
previously exported tracks if the selection is empty, or the
current selection (again).
This splits apart the actual signal handler from the work that needs to be done
to update the GUI in response to a tempo map change. This allows us to do the
visual update when we are manipulating the thread-local write copy of the map
during e.g. a drag operation.
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
This allows it to be used in an idle callback. If we use
::redisplay_track_views() directly, we do not disconnect the idle
connection. This will happen automatically since the callback will return
false, but it seems better to explicit about this. Even better would be to use
::connect_once() but this may not be available in the version of glibmm that we
are using at present.
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.
Major changes: do not delete and recreate markers and curves for every tempo map
change, attach tempo curves directly to their (preceding) tempo marker, notable
cleanup of TempoCurve class to remove unnecessary members.
More tweaks expected since algorithm for matching markers and tempo map
points is not correct yet.
After beginning an edit operation with TempoMap::write_copy(), the tempoPoint and meterPoint objects
referenced by markers are incorrect, since they refer to the original map, not the copy we are working
on. Fix this with Editor::reassociate_metric_markers()
Some instances requiring this fix may still remain
