This is in preparation to subscribe to playhead cursor position
changes in the recorder-UI.
This change also clean up the API, replacing a public variable
with a const access method and follows #12 of
https://ardour.org/styleguide.html
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 is work in progress towards fixing stacked region's region-gain
and multiple discontinuous regions spanning multiple tracks.
AutomationRangeDrag::setup() still does not collect all AutomationLine
points for certain overlap scenarios. There's more to come...
We no longer assume that Snap always uses the visible ruler lines.
If you want to snap to the grid, and ignore the users zoom scale, use SnapPref::SnapToGrid_Unscaled
This fixes 2 (known) oversights: "snap region(s) to grid" and "regions whose start are left of the canvas edge".
- remove trailing whitespace
- remove space after opening brackets and before closing brackets
- add space around operators
- do not use '//' for multi-line comments, do not use "//" on line-start
to comment-out code breaking indenting (-Wmisleading-indent)
- do add a single space after comment-start /*{SPACE}... or //{SPACE}...
- reserve duplicate whitespace " " for alignment, remove other duplicate
whitespace
- use established "TODO" and "XXX" (highlighted keywords)
- remove equal-sign series "====" (those indicate merge conflicts)
Separate Snap from Grid. Lots of naming changes.
Multiple simultaneous snap options allowed. Grid is one of the possible Snap options.
Grid uses the same data as the rulers. Replace complicated tempo_lines with simple grid_lines.
The Grid is zoom-scale-sensitive along with the rulers. If you are zoomed out, grid becomes coarser.
Snapped Cursor is a line that follows the edit point, and indicates where the operation will occur.
This replaces and extends the line that appears with the Cut tool.
New associated preferences: snap_threshold and show_snap_cursor.
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
- holding down shift before initiating a tempo mark drag
alters the end tempo of the previous one as before, but
this is now a separate drag.
- restore vertical dragging of the tempo mark to alter start/
end tempo. shift during the makrker drag alters start tempo.
xontrol + shift during the drag alters end tempo.
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)
snap now fills in a struct (MusicFrame) which contins a snapped frame
along with a music divisor.
this gives useful information wrt magnetic snap which may or may not
have rounded to an exact musical position.
region position may now be set musically (using quarter notes for now).
this patch fixes several problems in the current code:
- dragging a list of music-locked regions now maintains correct
musical offsets within the list.
- splitting regions using magnetic snap works correctly (#7192)
- cut drag should now work correctly with magnetic snap.
- musical length of split midi regions is no longer frame based.
* "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.
Currently implemented for Region and Range selections.
The new option is false/off by default to maintain existing behaviour. I'm not
sure it should require another option, perhaps Zoom to Selection should be the
default and accessing the region properties dialog can be via Modifier+double
click, but further changes can be made on user feedback etc.
Related: #7112
- for those not in the know, this series provides a way to
remove the temporal distortion introduced when using an
audio frame-based gui for music-locked objects.
In short, the gui uses an audio frame representation to move
objects. It displays the object using frame_at_beat(), quantizing
the time value to audio frames. This is fine until the user selects
that frame but expects it to be interpreted as a beat.
Thus beat_at_frame() would not produce the user-expected beat
(temporal quantization error of up to 0.5 audio samples).
This is one method of mapping audio time to music time accurately.
- a meter can be dragged using the constraint modifier, which
sets the previous tempo accordingly.
This could be added to the bbt ruler to allow direct dragging
of beats and bars, but the exact behavior of that is still
undecided. comments?
- also preliminary work on the necessary tempos locked to
audio-locked meters.
This functor/closure is responsible for stealing focus from any existing text entry (or whatever else may have focus)
when clicking on a CairoWidget or derived class.
The old implementation just gave focus back to the editor canvas. The new version walks up the widget packing
heirarchy to find a focusable parent (from the CairoWidget for which it is invoked). If no focusable parent
is found, it cancels keyboard focus in the toplevel window containing the CairoWidget
Each MidiRegionView(MRV) is connected to the Selection::ClearMidiNoteSelection
signal that is used to notify the all MRV instances to clear their note
selection.
The MRV class also has a private static SelectionCleared signal that is used to
signal other MRV instances when their selection has been cleared. When the
Selection::ClearMidiNoteSelection signal is emitted it causes each MRV to also
emit the SelectionCleared signal. So the emission takes quadratic time.
With 1500 MRV instances emission takes about 2.2 seconds on my machine, and
some operations like track selection cause it to be emitted 3 times(another
issue).
The Selection class in the Editor knows which MRV instances have note
selections, as it is notified by MidiRegionView whenever the selection count
becomes zero or becomes non-zero. Clearing the Note selection should then just
be O(N) and direct calls can be used rather than signals.
This change removes both the signals and uses the existing references between
Selection and MRV class to control note selection. There should be no
behavioural changes in Midi note selection with this change.
- disallow simultaneous events via ControlList::editor_add ()
- clicking on an automation line selects the points that define it.
- don't 'flash' a region selection when using mousedraw mode.
- cp click selection resembles region selection.
- region gain points respect snap modifier (a la automation points).
- display selected comtrol points in region gain lines
- display selected points in internal edit mode
- allow dragging of region gain lines in MouseContent mode
- also allow moving of automation lines in internal mouse mode.
- this is also a first pass at ensuring that if an operation does
nothing, avoid an undo entry.
switching to Grab should show the fade handles...
...switching away from grab should hide them.
Also, change "always show gain" preference to show lines, but not control points.
Range select rect sticks around now after switching to the draw tool, but
disappears if a note selection is made. Not sure if draw is really the most
appropriate tool here (particularly if we ever implement actual pencil-like
drawing); edit contents seems more appropriate but that would probably cause
more selection issues, so here we are.
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.
For some reason, grabbing the magic keyboard focus makes scroll stop working
regardless of what MRV::canvas_group_event() returns. I can't figure out any
reason to grab the keyboard in this case anyway, so I just removed it.
Also simlify MRV event handling code in general.
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.
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)
Fix crash with midi-regions (they have a frame-handle but no x-fade).
fixes 2nd part of #5992 (backtrace 20141021-B)
This is nicer in one way: When the cursor is "trim" the x-fade
context menu is no longer accessible.
And a bit worse: The x-fade context menu is only accessible on the
small fade-handles (boxes) and on the x-fade itself.
Problem: mouse-scrolling over a MIDI region in internal edit mode
never released “magic widget focus” (mod keys and global scrolls after
that were ignored). -> added to leave_notify.
Also, the MouseModeChanged signal needs to be emitted when internal edit,
mode changes in order to trigger MidiRegionView::mouse_mode_changed(),
which in turn releases the magic focus while still hovering over a MIDI
region.
TODO: needs undo. only works in top quarter of automation lane. selection model feels weird sometimes. needs to show gain curve when you are using Range tool
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.
