When Prefs > Editor > Zoom to mouse position... is disabled.
Ctrl + Scroll now allows to override the current zoom-focus,
and zoom in/out at the mouse-cursor position.
1. Alt is still handled to change drag behavior
2. Selection doesn't store notes unless they are part of the cut buffer, which means we should not
be altering the note selection in the editor's selection object most of the time.
1) Notes are only present in a Selection object if it is being used as a cut buffer. They are never stored
there as part of "normal selection" - that is delegated/left to MidiRegionViews that own the notes.
2) MidiRegionViews are stored in the Selection as "just" RegionViews, so provide a convenience
method to access them. This doesn't actually change much, since even the old MidiRegions object
was actually just a RegionSelection i.e. RegionViews.
We now check from the focus widget (if any) for any widget heirarchy bindings, and try to use them.
Next use the "top level" bindings passed in (top level is quoted because they may be owned by a tab,
rather than a window).
Finally, if the event is still not handled, try the global bindings
This model more closely matches what I think a reasonable programmer with experience of other
GUI toolkits would expect, and allows us to have multiple bindings present (though not
simultaneously used) in a given window
As soon as we ripple drag the selected region out of the original track,
::remove_unselected_from_views() is called and the rippled regions on the
original track are not covered when ::remove_selected_from_views() is called
again in ::finished(). Therefore we need to shift the regions remaining on the
original track back and forth again, in order to have them properly in the undo
history.
Previously only drag/drop to existing tracks used the target
time-position and files imported as new tracks using the drop-zone
were placed at 00:00:00:00.
This also fixes a logic error when "get_only_copy_imported_files"
was unset.
The condition under which "copy" was mandatory was rather convoluted,
so this also provides a more consistent user-experience.
Man new users drag/drop files onto the canvas without being aware
that Ardour only references external files. This can break sessions
when those files [re]moved.
RegionMoveDrag::finished_no_copy() calls ::clear_changes() on every selected
Region and then sets their positions again before committing the command to the
UndoHistory. By doing that no changes from the previous transaction spill over
into the current transaction.
This needs to be done in a similar way by in RegionRippleDrag::finished()
because otherwise a following undo action would also undo the changes of the
previous transaction for all the non selected rippled regions.
RegionRippleDrags across tracks are still borked, though.
Under some circumstances the transport FSM is still in stopping state when
::non_realtime_stop() already emits TransportStatechange. In that case the rec
boxes are not removed if we consider transport stopping == rolling.
7434478a35 introduced a race, IOchange triggers updating the
GUI and re-configuring processors. The latter needs to complete
first, otherwise Track::n_channels() returns the previous
channel count.
... on Ardour5.
On MacOS g_dir_make_tmp() does not return the canonical path. Thus, exported
template archives end up with wrong entry paths. This has been fixed by
e52bdc55ad for exporting templates. However, template archives that have been
exported on Ardour5 are not affected by the fix. Therefor we need a workaround
for the case we are importing legacy template archives from Ardour5.
This reverts commit fdf0db02a0.
Even though `gdk_pixmap_unref` is deprecated, it is the correct way
to free `gdk_pixmap_new` objects.
This fixes a memory leak and glib warning:
GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
PS. Eventually this pixmap should be replaced by a cairo surface.
By default Apple uses a private TMP folder.
g_dir_make_tmp() returns `/var/folders/...` while the real
absolute path is `/private/var/folders/...`.
This caused a problem when the tmp-prefix is chopped off when building
the archive.
This removes various duplicate code-paths leading to midi-model
updates, and expensive context-menu rebuilds. This significantly
speeds up MIDI track creation.
The previous version had various issues, in particular
when creating Tracks with an instrument, the RouteUI was not
available when the signal was emitted (likely caused by recent
ee-work of Audio+MIDI and Tape track removal).
However as side-effect fanned-out tracks/busses may now
be ordered before the new instrument route.
This also fixes an edge case of multiple fan-out in case
there is more than one RouteUI instance (mixer, editor-mixer,
meter-bridge).
