when Session emits RouteAdded, each handler (editor, mixer, trigger pages etc) will
execute their callbacks in order. But Editor::add_routes() selects the routes too,
which triggers a PresentationInfo::Change signal. This is received by e.g. the Mixer
before it has even found out about the newly added stripables. This in turn
leads to severe confusion regarding the state of the selection in the mixer,
and potentially elsewhere.
So, just add a PresentationInfo::ChangeSuspender for the scope of the RouteAdde
signal emission
Initially thew new region has a length of zero (0:0). When
merging Notes from a truncated region (no explicit note-off)
those notes are lost:
"Stuck note resolution - end time @ 0:0 is before note on: @ 0:0"
Truncate (or split) a region so that a note is cut short:
```
Region [{<--Note-------->}]
```
becomes
```
Region [{<--Note--]
^ implicit note-off at region boundary
```
When combining this region with an empty Region after gap,
```
Region [{<--Note--] [ ]
```
the result should be
```
Region [{<--Note->} ]
```
For this reason, even without a gap between the regions,
the original note length must not be restored.
The result MUST NOT be the same as the original:
```
Region [{<--Note-------->}]
```
Playlist::split can result in removal of a region
(adding two others instead). In this case the state
of the removed region (if modified) is not saved.
I/O plugin Controls are destroyed with ~IOPlug, however
Session::destroy()'s call to drop_references() still
triggers AutomationControl::session_going_away() on the
binding proxy.
This is even properly documented in session_object.h:
> A named object associated with a Session. Objects derived
> from this class are expected to be destroyed before the
> session calls drop_references().
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.
Previously creating a new preset first attempted to load
it from disk, before creating it. This resulted in a
`XML error: failed to load external entity`.
Track::use_captured_midi_sources is called from use_captured_sources().
which is only called from DiskWriter::transport_stopped_wallclock(),
which is only called from Session::non_realtime_stop().
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>
The alias was only used when it was exposed in lua. It was without any
indication that it was a deprecated alias, but let's just bite the
bullet and get rid of it.
Make sure all code paths that use Temporal will initialize and reset it
properly. Some code paths (in tet runners) doesn't use Sessions, so
Temporal::reset() has to be invoked directly.
Just set the static superclock variable to 0 as initial value.
TempoMap will still be initialized early as a singleton, but we
introduce a new constructor so it is created empty (and thus not really
usable until Temporal::reset() or similar has populated it).
We can thus drop the static initialization of superclock. The default
superclock rate of 282240000 will now only live in Temporal::reset().
With this change there should no longer be any uninitialized use of
superclock_ticks_per_second(), and there should not be any problems for
DEBUG_EARLY_SCTS_USE to catch. (It is however broken in other ways -
that will be fixed next.)
Ardour uses some global variables and singletons. These global variables
can be initialized with a value prior to program execution (especially
if they are const), but some of the static variables are modified, and
it is crucial that they always are reset when switching to another
session. To keep things simple and explicit and consistent, we thus
introduce Temporal::reset() to reset TempoMap (and later on also the
superclock rate). This is somewhat similar to Temporal::init(), which
usually only is invoked once (on program start) to initialize singletons
(such as the TempoMap).
9964f20c added TempoMap initialization to Session::create() ... but only
when not using a template. This create method is mainly preparing the
filesystem for a new session, and TempoMap initialization doesn't seem
like a perfect fit for it. It also seemed odd that it only initialized
TempoMap for clean new sessions, while existing sessions and templates
initialized it elsewhere.
Instead, invoke the TempoMap initialization early in the Session
creation process. This might introduce an extra and unnecessary TempoMap
initialization when loading an existing session or using a template, but
that will be cheap and do no harm, while providing a guarantee that we
always use the same default value.
