| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
canvas to the editor, during a drag
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
|
|
remove debug output
|
|
|
|
|
|
See: https://docs.google.com/document/d/1sI7p9RoRVZtNx2n67RvBa0_16fuZblV_lNkkKN2g93s/edit?usp=sharing
|
|
|
|
|
|
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
|
|
|
|
|
|
methods which add a new track/bus
|
|
remote control ID and "order keys" have been removed.
|
|
constraint modifier dilates previous tempo.
|
|
Moving the mouse over another region's gain line changed
clicked_regionview. clicked_regionview is used along with range-time
when initiating an AutomationRangeDrag.
|
|
This had become incoherent over time, and posed a development hazard and burden going forward
|
|
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.
|
|
on scroll
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.
|
|
|
|
Keep the same scrolling distance per event as when scroll left/right is used.
Scrolling in the ruler area is different than the track canvas area which I'm
not sure is a great idea as there is not much delineation between the two areas
but as the ruler area has some other different behaviour it is probably
acceptable/useful.
|
|
|
|
|
|
|
|
|
|
|
|
Paul Davis was responsible for introducing almost all of this.
|
|
This removes the direct dependence on ardour_ui.h from 39 files
|
|
- Also fixes new AutomationLine points having huge offsets
on creation via line click (window vs canvas event sample).
|
|
Classes are in the global namespace.
OSX has a flat namespace and OSX32bit/Carbon has a Marker too.
|
|
|
|
|
|
|
|
My apologies to translators.
|
|
fixes #6195 #6205
|
