Note that the Delivery::set_name() method worked correctly, but
the Route::set_name() method would return false incorrectly. This
appears to have no consequences.
The GUI `RouteUI::verify_new_route_name` checks for colons.
This left the session vulnerable, from calling set_name
from other places (e.g. ctrl surfaces).
We simply ignore the direct out sends from trax.
Note `DEFINE_ENUM_CONVERT` for Role is defined in delivery.cc
so we need a static method to directly read the send's role.
The diskreader uses the route's monitoring state when deciding whether or not
to fetch MIDI data for playback. Route::monitoring_state() would determine
whether or not we were already rolling to affect its return value. However,
using Session::transport_rolling() is affected by pre-roll and consequently
returns the wrong value during transport startup. Instead, we now use
::transport_state_rolling() which ignores preroll conditions. This leads to the
DR actually reading MIDI data from the initial playback position, which fixes
this issue.
Note that the bug only occured if the track or the session was rec-enabled. The
monitoring state value was always correct for non-rec-enabled conditions.
In case there are any unconnected tracks, the track's output is
assumed to align to the master bus (see Route::update_signal_latency).
For this to work correctly the master bus port's public latency
has to be set first.
This fixes e.g. the following issue: add a latent plugin to
the monitor section. Then toggle its bypass or remove it.
Previously the worst-case latency remained unchanged.
This lead to potentially silent stem-exports. It
should not be possible to hold a shared-ptr reference
of a processor that is not part of the processor chain.
This is better provided by Plugin::print_parameter, which
is called by PluginControl::get_user_string(). This removes
special cases for the mode enums.
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.
This is relevant when bouncing track -> track -> n/c.
It also helps to balance send latency route [send to bus] -> n/c
when the bus is connected to master or outputs.
This is in preparation to allow to skip adding sidechain ports
by default. When a user later adds the SC input ports, it is
convenient to connect the pins just like they are when they
are connected when instantiating the plugin (via reset_map).
Previously only adding an aux-send triggered a graph-reorder but copying
or deleting sends did nothing.
Adding/removing an aux-send may not even change the graph, but
both upstream/downstream latency can change and delaylines need to be
configured (which is done by calling update_latency_compensation with
force_whole_graph = true).
This fixes an issue with incorrect initial latency compensation after
copying a send (any later change to connections will correctly
recalculate it).
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.
This moves the _amp from send to delivery (which already
applies gain for the master-bus normalization). This generalizes
the use of a gain stage for use in port-inserts.
This change still runs the triggerbox during latency-preroll, but as with the disk reader,
the transport speed argument is set to zero. The triggerbox notices this and behaves
appropriately (I think !)