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.
* during drag and trim operations, we use "dragging region" transparency
so you can see the audio data beneath your region(s)
* we already do this for region-end-trim fade drags, which is a special
kind of trim operation, accessed from the 'lower' drag handle
* now we also trigger transparency for regular fade trims.
see discussion at:
https://discourse.ardour.org/t/regions-transparency-in-7-2/108060/31
* HitCreateDrag::start_grab does not need to do anything
a hit cannot be past end of region. Drawing at or past
the end of a region will create a new region (not an event)
* HitCreateDrag::finished now calculates the position like
NoteCreateDrag::finished.
* the selection does not need to be cleared. Creating new
notes/hits selectes the newly created ones.
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
When copying regions from multiple tracks, use the same
time domain for each region (depends on grid).
The primary region position is set the time-domain from
RegionMotionDrag::_last_position replacing the region's
prior time-domain. Other regions should follow suit and not
retain their time-domain.
Fixes: Enable snap-to-grid, select regions on multiple tracks,
ctrl+drag copy them.
This fixes rendering of opaque MIDI regions (previously
MIDI regions were always transparent). This change provides a
way to "flatten" layered MIDI regions, while still allowing
to show the note-line and grid behind the regions.
Double-clicking on a line in internal edit mode adds
a new point in the line. In this case LineDrag need not
manage automation events because the "add" functions already
do. see AutomationTimeAxisView::add_automation_event and
AudioRegionView::add_gain_point_event
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()
In the presence of tempo-changes distinguishing between offsets and
absolute positions is signficant. It is only valid to convert absolute
times using the tempo-map
Furthermore since GUI zoom-factor is time-invariant (samples per pixel),
all GUI operations must explictly use samples (or timecnt). It is not
valid (and problematic) to use use a location dependent timepos.
The class now has two separate methods for setting a duration or a point
value. They MUST be used appropriately, because their behavior is different.
When ::set_duration() is used in timecode mode, an extent (inclusive-end
length) is shown rather than a length.
Some objects, such as the TimeInfoBox, now deliberately shown an inclusive end
for their "end" clock, but this not universally followed, pending more feedback
from users and investigating of conventions in other DAWs.
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
In case of auto-scroll it is apparently possible that the
move_threshold_passed, but ::motion() is not called.
There already is an explicit _starting_point_passed variable
that is set when first_move occurred. So far it was just unused.
when dragging their location
* it should be possible to launch an arbitrary (non-quantized) sound
'anytime' on the timeline
* this was already possible anyway, by switching the Grid to None
When no movement has occurred, TrimDrag::motion was never called
and `begin_reversible_command()` was not called. There is nothing
to undo. This fixes
`commit_reversible_command(Command*): Assertion `_current_trans' failed`
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.
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.
