This means that we actually explicitly reposition all regions as part of the drag, and do not need to call
Editor::do_ripple(). We do still need to call Editor::ripple_marks() though
*now that you can grab "anywhere" in the region, trim edges are inferior because they are hard to hit
*modifier had to change anyway (since CTRL is used as a copy-drag on both mac and win), so that invalidates prior muscle memory
*potentially frees up modifier on the trim edge for some other purpose (anchored_trim)
Control Points should ignore x_constraint which is set in Drag::motion and potentially other places.
The only thing that should prevent CP sliding is can_slide which is false for the points at the ends of a region.
Ripple edit undo/redo needs a "recursive diff" of all regions
in the playlist. To work properly owned changes have to be
cleared first, previously unrelated edits were be collected too.
This includes a more consistent version of
7a89d56009 using rdiff() instead of explicitly
saving region diffs.
Previously x-axis threshold was in samples. This is
useless unless zoomed in to the max. So in most cases
the first-move was always in x-direction, making constrained
y-axis drags near impossible.
Furthermore the threshold for copy-drags was increased
as per #8686
Region positions were updated in the GUI, before the playlist
was catching up.
The butler thread reads a region using the region's new position,
but the playlist's old range.
Thread 1 (GUI)
```
#22 ARDOUR::Playlist::notify_layering_changed()
#26 ARDOUR::AudioPlaylist::region_changed
#27 ARDOUR::Playlist::region_changed_proxy
#35 ARDOUR::Region::send_change
#36 ARDOUR::Region::set_position
#37 RegionRippleDrag::remove_unselected_from_views
#38 RegionRippleDrag::finished
```
LayeringChanged() also triggers DiskIOProcessor::playlist_modified
which schedules a pending-override and summons the butler.
Note that when moving only a few regions the butler starts after all
updates have been completed.
Butler thread:
```
#4 ARDOUR::AudioRegion::read_at
#5 ARDOUR::AudioPlaylist::read
#6 ARDOUR::DiskReader::audio_read
#7 ARDOUR::DiskReader::overwrite_existing_audio
#8 ARDOUR::DiskReader::overwrite_existing_buffers
#9 ARDOUR::Track::overwrite_existing_buffers
#10 ARDOUR::Session::non_realtime_overwrite
```
Region read fails:
```
libs/ardour/audioregion.cc:503 assert (position >= _position);
(gdb) p position
$1 = 1312000
(gdb) p _position
$2 = {<PBD::PropertyTemplate<long>> = {_have_old = true,
_current = 1336000, _old = 1312000} }
```
The DraggingView's time_axis_view (index) is set to the size of _time_axis_views
in ::motion() near line 1149. This makes it invalid as index into the vector.
Playlist changes do not include region-property changes.
When inserting a region, position(s) of other Regions may
change and those changes have to be recorded explicitly (for now).
see also RegionRippleDrag.
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
When ripple moving a region all the subsequent regions will be moved, next
region in the playlist after the dragged one first, last region of the playlist
last.
Thus, when an automation point is ripple moved along a region past the starting
point of the next region, it will be moved again along with the next region as
the move of the next region occurs after moving the automation point.
This fix reverses the sequence of the ripple moves, last region in the playlist
will be moved first, the next after the dragged one, last. So no temporary
overlap of regions will occur.
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.
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.
Previously adding percussive-hits created sustained notes
using the current grid as duration. This allowed to create
overlapping notes with the overlap not being visible.
Most hardware MIDI drumkits do send an immediate note-off event
after each hit (if they send note-offs at all).
Ardour now follows suit and does the same when using the draw/edit tool.
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...
* Both the session-start and session-end point should follow the is-free option
* Rename the end-is-free option to session-range-is-free, to reflect that change
* This fixes the problem: recording before the start marker would move the Start,
even if the user had already fixed the End marker.
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".
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
It was assumed that the drag takes place within an area of musical time.
This is not true for the space before any non-initial
meter-locked tempo.
In the case of the initial tempo, there is no previous section
to perform an end-drag on.
If we've clicked on a tempo bar before the initial tempo,
don't allow anything to happen.
If it was just a click, ensure the tempo curve colour is restored.
* 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.
This multiplier really should be based on the "responsiveness" of the
canvas..or something. I think this is an improvement for more complex sessions
with many regions.
- a tempo marker may now be set to always continue (clamped)
this means that the end tempo of the previous section will
track the start tempo during tempo ops.
it mimics the behaviour in 5.8, with the gui indicating
the curves to be changed.
- 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.
- this implements in the intention behind the previous commit.
a tempo mark is constant until its end has been changed by a
shift-drag on the next marker.
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)
- wysiwyg (during drag) when dragging more than one note across
a tempo change.
- introduces a muscal equivalent of snap_delta (only used for
note drags atm)
- split earliest note in selection into a separate function
- MRV::copy_selection() returns the equivalent _primary note
to avoid offset hell.
- RV::snap_frame_to_frame returns a MusicFrame
- prevent note drag moving before region start.
- 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()?)
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.
If a track is selected during the drag (by moving the mouse pointer into a new track), but it was not
selected at the start, and is then de-selected (by moving the mouse back out of it), then remove
it from the selection.
* "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.
- music-locked regions are moved by drag beat distance
(will conform to tempo changes over the drag distance)
audio-locked regions are moved by frame distance.
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
- this allows a midi region drag to update the visible notes
correctly while crossing MIDI streamviews with a differing
note range.
as a side effect, fixes a bug where changing
note range on a track did not draw some notes
(apply_note_range redisplays the model).
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
- adds quarter_notes_per_minute(), note_divisions_per_minute (double)
pulses_per_minute() and frames_per_quarter_note()
- this should be a no-op except for the use of tempo by
the vst callback which definitely uses quarter notes per minute.
- the XML node for TempoSection named 'beats-per-minute'
has been renamed.
- add more debugging output detecting regions whose
beat and frame position do not align on a playlist.
this is required as a check as we have never used
frame rounding on constant tempi before 8884a5723dc
- moves frame rounding up to TempoMap, which is needed
in order to calculate pulse distance without frame rounding.
- the time unit for tempo is still minute, but this now also
applies to meter sections. (new audio locked meter sections no
longer require a frame position).
- there is no longer a discontinuity
in the pulse for audio-locked meter/tempi.
- temporarily add debugging output in Region::set_position()
to test for region beat not matching region frame.
