Playlist::add_region, Playlist::add_region_internal always
adds the region to the top of the playlist, ignoring the
region's layer.
Note that there is also difference between
Region::layer and Region::layering_index.
This solves several issues related to splitting or pasting regions, when
there is more than one layer.
Rather than assign a new group-id for "all the regions on the right of a
split", only ions that had a *prior* group-relationship should be
propagated into the new group.
Signed-off-by: Robin Gareus <robin@gareus.org>
* Use an atomic reference count since the freeze-thread
can call use_playlist.
* Remove explicit argument to construct unused playlist
because playlists are unused by default. This also
lead to use-count becoming negative (or rather UINT32_MAX)
This fixes the following issue:
1. Import a file to a new track
2. Delete the track
3. Editor Source list: select imported file,
-> Remove the selected source
-> Yes, remove the Regions and Sources
The Track and Region no longer exist in the Editor,
only the playlist still exists!
The sources to be deleted are found when iterating over whole-file
regions in `EditorSources::remove_selected_sources`. Also
RegionFactory::get_regions_using_source correctly returns
regions, _editor->remove_regions does nothing since there
is no RegionView for the given region(s). This then cashes in
```
libs/ardour/playlist.cc:2400: virtual XMLNode& ARDOUR::Playlist::state(bool) const: Assertion `r->sources ().size () > 0 && r->master_sources ().size () > 0' failed.
```
The eventual goal is to keep the set of used regions
in sync, and allow to remove explicit calls to
`sync_all_regions_with_regions`.
This prevents `all_regions` to retain a reference to
a region that has been destroyed.
Despite the names suggesting otherwise
`block_notifications` and `ignore_state_changes` are used
for the same purpose.
The only difference is that ::freeze ::thaw explicitly
modified `ignore_state_changes` **in addition** to
`block_notifications`.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
Due to rounding (r->position_sample() - start.samples())
can become negative even if (r->position () >= start).
with k = start_division and start_division < 0 this
caused an invalid vector access `layers[j-1][k]`.
This is never for inline references to parameters, only for starting parameter
documentation blocks. The "@p" command is for this, although unfortunately
Doxygen doesn't actually do anything with it and it's just an alias for code
text.
Various operations, notably time-stretch and other filters, directly
added the generated whole-file region to the playlist.
The editor has not listed the generated Region in the RegionList.
This effectively triggers a Session::request_overwrite_buffer
via Playlist::notify_contents_changed when the time-domain of a
Region changes.
When the time domain of a MIDI region changes, Region boundaries
and events positions change ever so slightly. The playlist has
to be rendered again to take this into account.
When MIDI regions with different time-domains are layered, notes
may not be resolved in correct order. Previously changing time-domains
to address this did not result in the playlist being reread.
Constructing a playlist from another playlist plus an offset used the wrong
RegionFactory::create method. By failing to pass in the offset to the region
constructor, the newly created region gets its envelope (and possibly other
automation data) from the start of the existing region, not its own start.
* when you copy a Range into a playlist, the playlist's 'timeline' should
begin at the start of the selected Range. Regions should retain the
offset they had from the Range's start.
Since cc6c0f1263 there is no Properties::position event
when a region is moved. So notify_region_moved() or
notify_region_start_trimmed() was never emitted and
Session::maybe_update_session_range() was not called.