Preserve alignment between notes and control points when doing an internal
copy/paste of both.
Relative alignment between points on multi-paste is still not preserved. Both
behaviours here are actually useful, perhaps a modifier...
No functional changes in this one (for easier auditing), but towards having
round up/down only if necessary modes, rather than kludging around that
situation with a double round as we do currently.
The idea here is that pasting several times to the same location doesn't make
sense. Instead, the paste is appended past the last paste, snapped to the
grid. This make it simple to replicate a given section a number of times,
simply by copying once and pasting several times.
This behaviour only appears when successive pastes are done to the same
location (whatever the edit point is). When the paste point changes, the
"multi-paste" state is reset.
Boots 'n cats 'n boots 'n cats.
However, keep the path for deletions in the editor-mixer via _entered_mixer_strip
TODO: if nothing was deleted, assume the user was trying to delete something in the editor instead
Show selected plugins by a red border
TODO: more work on the selection model for plugins and mixer strips
This had to be hacked because the editor_mixer strip is on the editor and doesnt respond to mixer keybindings.
Also force the gain intry to lose focus if the user leaves the mixer strip. this will probably solve some long-standing complaints. although perhaps a more elegant solution is possible.
This is needed to be able to lock the application fully on OS X, where the global menu bar would still allow interaction
even when a modal dialog is displayed.
Remove Canvas::Layout, use Canvas::Container for the same purpose, move child-rendering into Item::render_children() so that it
could theoretically be used by any derived type.
To handle any further issues like this, I generalized and added an optional argument specifying that the canvas=>trackview transform is required, thus
centralizing where this done.
The idea now is that a scroll group item can be added to the canvas which will causes its children to scroll in either or both
directions (horizontal or vertical). There are few complications: the position() of the ScrollGroup is ambiguous depending
on whether you want it with scroll taken into account or not, so Item::canvas_position() was added, which defaults to
the same value as Item::position() but is overridden by ScrollGroup to return the position independent of scrolling. This
method is used when translating between item/canvas/window coordinate systems.
Note that the basic idea is that we MOVE the scroll group when a scroll happens. This mirrors what happens in the GnomeCanvas,
where Nick Mainsbridge came up with a great idea that allowed unification of the time bar and track canvases.
Add a value for Ripple to EditMode enum.
Add Ripple edit mode to edit mode dropdown, by adding it to the
Editor::build_edit_mode_menu() helper function, and remove the old code that
added items to the (now unused) Editor::edit_mode_strings.
Add the regions that should be affected by the drag to RegionDrag::_views so
that the drag carries them along automatically.
Use a copy of the RegionList in Playlist::core_ripple(), since bad things
happen when iterating over regions and they get moved around in the list.
Handle rippling in removal of regions from playlist.
When dragging in ripple mode, exclude all regions that lie before the
original start position of the selected regions being dragged from
rippling: this is what Mixbus does.
Make editor dragging respect snap-to settings, by using the existing
compute_x_delta() function, which did almost the right thing. Move setting
of _last_frame_position out of that function so all ripple-dragged regions
can move.
Ripple when dragging from region list: even though Mixbus doesn't do this, it
seems like a good idea.
Prevent multi-track selection being dragged across tracks, by making
RegionMotionDrag::y_movement_allowed() virtual, and overriding it in
RegionRippleDrag to forbid dragging of selections containing regions on more
than one track to dofferent tracks in ripple mode.
Remember which TimeAxisView a ripple-mode drag that's allowed cross-track
drags started from, so that the effect of rippling regions after any region
that's dragged off that track can be undone.
Dragging regions vertically does the quantization BUT speed control is lacking and the region ends up on
a track that is still invisible ... to be fixed as the sun rises.
Many more changes than I would typically like in a single commit, but this was all very intertwined.
Vertical scrolling using track-stepping still to follow.
Best guess right now is that optimization does something bad when ceil() is called twice on a very large dbl-precision number,
which results in a zero (empty) redraw area. Without the removal of the redundant ceil & floor functions, no expose events
would be delivered to the canvas in an optimized build during drags (and maybe more).
gtkmm2ext/keyboard.cc has a special case to emit a signal on the key-up of
the modifier key used to adjust track heights in conjunction with the
scroll wheel, so that the same track continues to be resized even when
it's shrunk to no longer be under the mouse cursor. However, this code
assumed that the modifier key for this was <Shift>.
Fix it to use the event->state bit corresponding to
ScrollZoomVerticalModifier instead, and rename the relevant functions to
clarify that it's the 'zoom vertical' modifier key they're dealing with.
Partially fixes#5610.
when using ImportDistinctChannels, correctly name regions so that playlists for each channel/track
are also named differently, and thus reloaded properly when the session is reloaded.
gtkmm2ext/keyboard.cc has a special case to emit a signal on the key-up of
the modifier key used to adjust track heights in conjunction with the
scroll wheel, so that the same track continues to be resized even when
it's shrunk to no longer be under the mouse cursor. However, this code
assumed that the modifier key for this was <Shift>.
Fix it to use the event->state bit corresponding to
ScrollZoomVerticalModifier instead, and rename the relevant functions to
clarify that it's the 'zoom vertical' modifier key they're dealing with.
Partially fixes#5610.
when using ImportDistinctChannels, correctly name regions so that playlists for each channel/track
are also named differently, and thus reloaded properly when the session is reloaded.
