This allows to move or copy whole sections of the timline (everything
you hear) to a differnt position on the timeline.
NB. Markers and tempo-map are not yet moved, and interpolated MIDI
events are lost.
A route may be processed before latency-compensation callback
sets the route's output_latency. In this case a random offset
was added to the start/end position (via latency_offset).
The process-graph should only be concerned with GraphNodes,
which may or may not be Routes.
This also removes intrinsic connection information from
the graph-node. Connection information is to be kept separate
from the nodes.
When the graph is re-calculated in the background, old information
has to be retained until the new graph becomes active.
Previously *new* information was already stored in the nodes
while the graph is sorted, even though the new graph was not
active.
This is mainly relevant for Mixbus, which allows cyclic-connections
to record Master-out on a Track (which unconditionally has Mixbus send
and feeds master).
In Ardour it may also cause issues when creating loopback connections,
however latency is not usually updated with invalid graphs (old
process graph remains in use).
Otherwise it fixes a crash connecting Track 1 -> Track 2 -> Track 1.
This also optimizes Route::output_effectively_connected by caching
any prior lookup. This helps e.g. Track 1 -> Track 2 -> Master.
The connection "Track 2 -> Master" now only need to be looked up once.
See also 7958031287 and a556e96ed0
When a track's output is not connected, we assume
its output playback latency matches that of the master-bus.
This is to prevent the track's output latency to float
freely (see also a556e96ed0).
This failed if a track is connected to another track which is
not connected.
In order to detect if route delaylines need to be updated,
aux-send delaylines need to be updated first. This was previously
done directly in the latency-callback, which may be concurrent
with processing.
Now only the information (pending_delay) is set, and the actual
change happens later at the end of process().
Previously Ardour only announced processor latency.
Routes that had additional latency to compensate for those
have not published this delay.
This is of no concern with internal backends, however with JACK,
Ardour reported incorrect *individual* port-latencies of
routes that perform PDC.
Since public port latency now includes delay-compensation,
some extra work is required to unset it before recalculating
latency of paths that include external ports.
"While 'atomic' has a volatile qualifier, this is a historical
artifact and the pointer passed to it should not be volatile."
Furthermore "It is very important that all accesses to a
particular integer or pointer be performed using only this API"
(from https://developer.gnome.org/glib/2.68/glib-Atomic-Operations.html)
Hence initialization of atomic variables is changed to also use
this API, instead of directly initializing the value.
This also fixes a few cases where atomic variables were
accessed directly.
see also libs/pbd/pbd/g_atomic_compat.h
This slowly un/mutes the direct monitor signal when listen state
changes.
Listen sends already fade in as well. However un-soloing still
hard-removes the listen send path.
Since fan-out happens (interactively) in the GUI thread,
we need to keep track of this, in order to prevent later
auto-connection of the track to the master-bus.
This partially reverts 208c781248
in order to fix monitoring when using punch-in/out.
This also allows to revert to Ardour 5 style MIDI exclusive
Input or Disk monitoring when not using layered-recording.
IO::latency iterates over the port-set retrieving the
private_latency_range of each port. Since it can only change
when connections and latency changes, we can instead cache the value.
This is also in preparation to allow the auditioner to override it.
* Signals use camelcase.
* use a static signal, independent of the route
Previously the signal was handled by RouteUI, which
caused various issues:
* the RouteUI may not yet be available
* There may be many RouteUIs for a single Route
(mixer, editor-mixer, meter-bridge strips)
Previously set_state() -> set_meter_point() acquired the
process-lock to change meter-position, usually causing x-runs
when setting route-state.
This also fixes an issue introduced in fd414ec158. After
populating the processor list, force setting the meter-position
looks up the output streams of the processor before the meter.
However the processors are not configured. That will only happen
later from Session::post_engine_init().
---
#3 0x00007ff07b7d4102 in __GI___assert_fail at assert.c:101
#4 0x00007ff080d3224a in ARDOUR::PluginInsert::output_streams() const at ../libs/ardour/plugin_insert.cc:289
#5 0x00007ff080de8c30 in ARDOUR::Route::set_meter_point_unlocked() at ../libs/ardour/route.cc:4106
#6 0x00007ff080de8699 in ARDOUR::Route::set_meter_point(ARDOUR::MeterPoint, bool) at ../libs/ardour/route.cc:4037
#7 0x00007ff080ddfad3 in ARDOUR::Route::set_state(XMLNode const&, int) at ../libs/ardour/route.cc:269
While loading a session XML state, set_state must use
`Stateful::loading_state_version`.
When later copying processor state,
`Stateful::current_state_version` is correct.
When looping, we do not want to resolve notes at the end of the loop via ::realtime_locate() -
::get_midi_playback() has already taken care of this. But when not looping, we need this. So,
add an argument to tell all interested parties whether the locate is for a loop end or not
In theory different UIs can show different meter-types, so it
can make sense to maintain the type in different places.
MeterType is a bit-set and PeakMeter implementation provides for this.
However, this is not being used, and the current implementation
was rather fragmented, cross-connected signals to keep types in sync,
allowed inconsistent meter-types in GUI and backend.
MeterType is now kept by meter itself, however it is still
saved/restored as part of the Route state.
N.B. This change breaks the API, various methods have been renamed
for consistency.
Robin Gareus
Paul Davis
Ben Loftis
Len Ovens