During drag-motion callbacks the data to be dragged is n/a.
However we like to discriminate if drop is possible.
When dragging regions, the data-type of the region to be dragged
is unknown, so different `x-ardour/region` targets are not an
option, either.
Until a better option is presented, a static global is used
to set the data-type for region.pbdid drags.
This is in preparation for allowing to drag trigger-regions
or trigger-slots. Those will not use a static singleton
PublicEditor API.
Additionally this constrains Ardour-internal drags to Ardour
(via Gtk::TARGET_SAME_APP).
Unconditionally use the mouse-cursor as zoom-focus when holding
<ctrl> while scrolling on the canvas.
This is consistent with using ctrl + scroll in the ruler area.
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.
The drag code expects coordinates in canvas coordinates, but we were not translating them at the editor level (canvas event handling
does do this, but cannot affect the situation if the event falls through to the editor)
Copyright-holder and year information is extracted from git log.
git history begins in 2005. So (C) from 1998..2005 is lost. Also some
(C) assignment of commits where the committer didn't use --author.
This preserves the stereo-ness of files that were imported or recorded in stereo.
ToDo (maybe someday): provide a disclosure triangle that exposes the individual channels in a multichannel region
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
* If the use-time-rulers-to-zoom option is enabled, -all- cursor drags can zoom.
* Behavior has been tweaked so it is easy to scroll without zooming, if you want to.
GTK events are still handled while un/loading a session (e.g display
"Loading" message or showing the splash triggers an event-loop run).
Global canvas elements (e.g. Rulers) may respond to session-specific
actions.
most changes are due to a new design where tempo discontinuities at the
beginning of a ramped section may be set.
this allows easier mapping of live performance, especially in
the common case of a ramped ritard before the beginning of a new section.
feature summary:
holding constraint modifier (shift) while dragging the BBT ruler area
drags the tempo lines by changing the start tempo (as before)
holding copy modifier (control) while dragging the BBT ruler area
drags the tempo lines by changing the end tempo (ahem. not quite there)
dragging a tempo mark while holding constraint (shift) will change the
previous end tempo to match the marker position *worth trying*.
holding constraint and copy modifier (control + shift) while dragging
the BBT ruler area attempts to'pinch' or twist the surrounding tempi
sp that later ones are not repositioned (currently suffereng from
rounding errors)
- its still a fake event, but we can at least get the snap correct.
- playlist->add_region() parameters were whacky
(for Playlist::add_region_internal()?)
* "Follow Edits" button had several behaviors that confused users.
* "Follow Range" only has 2 behaviors:
** Click anywhere in Range mode (or Smart mode) to locate the playhead.
** When you select a Range, "Play" will play the selected range.
This is a common operation used for zooming in other DAWs like Ableton Live and
Cubase. To support such a usage pattern without changing the existing behaviour
of the ruler area I've made it an option that is false by default.
The behaviour of RulerDragZoom is intentionally different than a CursorDrag
that occurs in the rest of the ruler area in that it doesn't follow the snap to
grid setting and no locate related stuff occurs until button release.
There are some issues with responsiveness with more than a few hundred regions
or a large amount of MIDI events/notes.
Implements feature #6768
Moving the mouse over another region's gain line changed
clicked_regionview. clicked_regionview is used along with range-time
when initiating an AutomationRangeDrag.
In response to a comment in #6722, as there is little delineation between the
ruler and track canvas areas it makes sense to keep the scrolling step the same
to avoid unintended jumps in scrolling if mouse cursor moves between areas.
This means that mouse zoom scrolling behaviour is consistent on the ruler
canvas area and track canvas area.
The config option defaults to true so this means the behaviour of Mixbus will
be unchanged but in Ardour the ruler area will now follow the option so by
default will use the mouse position as zoom focus when zooming rather than the
zoom focus setting.
