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.
Editor::motion_handler() only updates the snap-cursor
when no drags are active. While dragging, Drag::motion is
responsible to set the cursor accordingly.
In many cases the snap-cursor simply remained stuck at
the most recent position. Since in many cases
(e.g. RubberbandSelectDrag) it makes no sense to show the
cursor, so Drag::start_grab now hides the cursor by default.
This also fixes cases where the cursor is shown, but
was displayed in the wrong location.
* 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)
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.
The old code could not snap to the grid, because it had a lot of confusion about pixels vs. time,
and between line-origin-relative time and absolute time
a drag on a segment without adjacent points would crash because we never
set the _grab_button for the Drag, so the LineDrag object never gets deleted
on mouse-up. This leaves a dangling reversible command, which will then
cause an assert(false) crash in the next Editor::begin_reversible_command()
Confusion caused during nutempo development when a boolean related to nick_m's old
"for music" concept ended up becoming the "auto_partition" argument instead
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.
* in the case where there are no existing automation points, then
initiating an automation range drag (select range, switch to Draw)
should initialize the line at the current knob position
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
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.
