This was triggered when reloading session and immediately duplicating range with
keyboard shortcut. As clicked_selection was uninitialized it would try to use
an invalid index into the TimeSelection.
This fixes an issues where Ardour never completes to flush the GUI event
queue due to rapid updates for meters and similar events.
ARDOUR_UI::load_session() never returned and the complete session
ran inside Gtkmm2ext::UI::flush_pending(), this later causes a crash
at exit.
as side effect, this also speeds up session load.
Due to some change somewhere along the road the nudge clock does
no longer fit in the transport-bar on 1024px screen with 100% font-scale,
even if the 2nd clock is hidden.
However, these days it does fit nicely on its default position even
with wide-editor-mixer on a 1024px screen.
Visibility is driven by the currently selected mouse mode.
Visibility no longer depends on entering/exiting the region.
Range mode shows the lines but not the points.
Fixed option text to reflect new operation.
- its now possible to use snap modifiers in combination with others
afaict this hasn't worked for some time.
- use "contains" rather than "equals" during drag. Still uncertain
about this wrt beginning a drag. for now they are all "equals".
- probably solve the "snap modifier modifier" problem using
ArdourKeyboard::indicates_snap () and friend.
- user can abs/rel modifier key in prefs->user interaction
suggested for linux - absolute->alt ignore snap->alt-shift
- Constrained mode works the same as button 2 drag (initial move
sets constraint axis).
Currently we don't do anything special on layering prefs change
(relayer only occurs when each playlist is first edited). The idea here is
that "undo" is still available to restore previous layering in case of any
surprises.
“number of visible tracks”: count automation lanes
as tracks. Distribute equally.
“Summary View”: the visual lane represents both
track + automation. Set the total height.
Left to do: recursive “Shrink” and “Expand” tools
if there is no explicit selection.
Fix several other cases where a single mouse click could cause several
(not nested) selection ops.
Fix missing selection memento for midi notes and midi commands.
Rename some variables.
Fix random style issues.
The user can now replay *all* earlier selection operations until the next
session undo/redo command, or the completion of a new operation.
Nothing relating to selection ops is stored, and selection operation history
is begun on first idle.
Selection operation history is fundamentally different from the history of
operations which act on a selection in terms of both their viewport and the
amount of information required to replay them.
WRT undo, the user of a selection op doesn't care about the viewport state
at the beginning of an op, but rather that at the end of the previous one.
For example, if you're in a note and something about the mode changes, it's the
underlying region context that needs to change. So, seems we need a stack of
entry contexts to deal with this sort of thing.
Switching in/out of smart mode still doesn't update immediately because we
don't have the y-coordinate needed to update it.
combines selection related editor properties with the current editor selection.
The related editor properties are:
mouse mode,
zoom setting,
left frame of the canvas,
y origin of the canvas.
Selection state now includes region views (storing the underlying region id)
and time.
This patch also fixes a region mute undo bug.
This lets us get a more explicit handle on time conversions, and is the main
step towards using actual beat:tick time and getting away from floating point
precision problems.
The idea here is to do the reasonable thing, and copy objects of some
type (e.g. MIDI region, gain line) to tracks with a matching type. The user
can override this with a track selection, which will be used straight-up.
Lost: ability to copy/paste lines across types, e.g. gain to pan. This is
often questionable, but sometimes useful, so we will need to implement some
sort of "greedy mode" to make it possible. Implementation simple, but not sure
what to do. Perhaps this should only be possible if one automation track is
explicitly (i.e. via track selection) involved, and the types are at least
compatible-ish?
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.
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
the documentation was correct: “GTK+ uses G_PRIORITY_HIGH_IDLE + 10
for resizing operations, and G_PRIORITY_HIGH_IDLE + 20 for redrawing
operations.” but the priority for the idle visual changer was wrong.
fixes, follow-playhead and zoom/scrolling under load (no idle)
* retain [custom] track-height
Editor::override_visible_track_count() is called repeatedly (for
every change), there was a 50/50 chance of it saving the right value.
* adjust default for new sessions: use “Normal” track height until
told otherwise.
ArdourButtons now have a "pushed" animation.
The gradient is now implemented in the button, rather than providing 2 colors in the theme, which was burdensome.
Lots of code cleanup in ArdourButton. Removed several unnecessary flags.
Refactor more stuff into route_ui.
Consistent mixer strip button height.
The latter works by setting all the button size request heights to the
calculated height of the alphabet. Thus, all buttons of the same class will be
the same height regardless of their actual text.
All the different looks here didn't seem to convey anything useful to me, and
looked sloppy. I went with the style of the transport button.
It would be nice if we could style button elements like Inset in the
configuration, but this would require some work.
move toolbar box above editor-canvas. Without-editor mixer
there is no change. With Editor-mixer it is now above the
mixer-strip.
This makes the toolbar [almost] fit on 1024px width.
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.
This should really be done in ArdourDropdown somehow.
Fixes issues introduced at b9708d5: If after session-load some
radio-item other than the first one is set active, it is
impossible to switch to the first.
e.g. set "Snap to Grid", Save Session, Load Session, trying to
switch to "Snap to None" fails until another mode is selected first.
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.
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.
