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.
The design ignored the ratio computed by the drag interaction, and relied on getting the stretch
ratio from the dialog. This truncated the actual ratio, leading to (relatively) small errors
in the length of the generated region.
Now, if the ratio provided by the drag is not (1/1) (i.e. a single click while in timefx mode)
then the percentage stretch spinner is marked insensitive and the stretch ratio is taken from
the given ratio. For single clicks, the user can still adjust the percentage as they wish
* 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 prevents the case where have enabled snap, and you add a note that
appears to be on a bar line. but actually it is {some Grid value} off,
it just looks right because of pixel rounding.
This fixes the issue where you click to create a note, but move the mouse
just a little, resulting in a note of invisibly small length
Do the calculation in ::motion so it displays the final
size while you are dragging. "what you see is what you will get"
The ::start_drag() implementation now defers add/extend selection logic to
MidiRegionView::note_selected(), and drops the original limitation that we did
not do extend-selection on button press, only button release.
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 was broken during development of ripple-all.
First explicit rdiff_and_add_command() was used, but
when that was reverted later, the original stateful_diff
was not restored.
989408626d1ccf272d58
This addresses an issue with missing guard points at the
beginning of a range drag when the range is not snapped to
a musical grid.
Note that the code below "same thing for the end" does not use
.beats() either.
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.
Editor::drop_regions() creates a new RegionInsertDrag()
with the region to drop to the timeline.
RegionInsertDrag is-a RegionMotionDrag is-a RegionDrag is-a Drag.
However the region does not yet exist on the timeline and
RegionView is NULL.
This will likely need an API change. e.g.
Directly pass the TimeDomain as argument. The information can
be provided by the region, or from the TimeAxisView or RouteUI
when dropping a new source/region.
Important logic from 6.9 was either missing or incorrectly implemented. New
version is much simpler - we just use the RoundDownMaybe mode of round_to_bbt()
to ensure that the note start is always within the current grid even if the
mouse is more than halfway "through" it.
MSVC is happy to ignore the above pragma although it aborts the build if it encounters #warning
#pragma GCC warning seems to work fine here for Clang - so start by changing just 1 x file to see if there's any detrimental effect for the other builds.