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"
