Age | Commit message (Collapse) | Author |
|
method, rather than Route::set_name()
Without this, nothing in Track::set_name() is called, which means that tracks created from templates
do not get their name set appropriately
|
|
|
|
This handles some special cases where a plugin is added after
the disk-writer but before the disk-reader.
The plugin may add/remove ports (e.g. an instrument: MIDI to audio,
or some stereo to mono processors). However we need to ensure
that any data that is recorded will be played back.
This is a new take replacing b2bc934e2.
|
|
|
|
This is in a Route method, so it is obvious that dynamic_cast<Route*>(this) will return true
|
|
|
|
[Re]name sidechain port directly when a plugin is added.
Usually plugins are constructed without an Route (owner is unset).
PluginInsert c'tor may already create a side-chain port, at the
time of construction the sidechain port will be created using
the port-name "toBeRenamed".
Previously the plugin had to be added to a route using "add_processor",
in order to set a unique name, before a new plugin with sidechain
could be constructed.
ProcessorBox::use_plugins() did that in the correct sequence,
however there may have been cases where this didn't work, and
Route::add_processors() was called directly..
|
|
comment for details)
|
|
Stateful::loading_state_version vs.
Stateful::current_state_version
See also 0a5837ec7111
|
|
This builds on top of 51d2bb:
* v6 routes templates/states have a version per <Route>
* older route-states are assumed to be from ardour-5
Stateful::loading_state_version 3002,
unless specified otherwise
|
|
Currently using Ardour-5 route templates (state version "3002")
with Ardour6 fails. As opposed to session-templates, Route
templates were not versioned.
This ensures future compatibility (and may allow to interpret
unversioned templates as "3002")
|
|
* update AFL position when preference changes
* "after post-fader processors (before pan)" is before
the main-out (not at the end).
* Fix "immediately post-fader":
The amp, when added was the last element. ++after_end then
made the iterator point to .end()
This likely worked in the past when the monitor send was added
immediately after adding the fader/amp before any other processors.
|
|
|
|
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.
|
|
This also solves bi-stable automation for plugins where latency
can change due to automation. e.g.
cycle 1: run (t): automation (t) = on: -> increase latency
cycle 2: run (t-latency): automation (t-latency) = off -> decrease latency
repeat.
|
|
|
|
|
|
get_value_or() has been deprecated since boost 1.56
|
|
|
|
|
|
This precludes issues with multi-out-plugins adding an excessive
number of ports and changing master-panning.
|
|
|
|
When re-ordering processors, the route's own latency does not
change (at first).
But it might if sends or plugins with side-chains a involved.
|
|
|
|
being called as part of a callback from the backend.
If it is, do not call AudioEngine::update_latencies() to avoid JACK1-style deadlock
|
|
Plugins may override strict-i/o, and in order to know do this
the plugin needs to be instantiate first.
|
|
|
|
|
|
* Add new common strip controls (inspired from Mixbus)
* Remove duplicate documentation, document virtual API only.
* "azimuth" not "azi"
|
|
|
|
This is in preparation for MixbusSends that are not derived from
Delivery : IOProcessor.
|
|
|
|
|
|
|
|
|
|
|
|
This only affects the meter-bridge, toolbar and editor track-header
(Mixbus' mixer is always using DPM, which is always enabled).
|
|
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.
|
|
|
|
|
|
|
|
Note Presentation-Info bits used by Mixbus to prevent conflicts
when sharing sessions.
|
|
|
|
|
|
|
|
This fixes a bug when shift() creates automation for parameters that
can not have any automation (hidden parameters, Mixbus PRE).
The GUI (RTAV) aborts() when it finds an automation lane for
a hidden parameter.
This also cleans up shift() operations in general. Empty automation
lanes should be left alone, no guard-point at zero should be added.
|
|
We no longer find playlists by name when constructing tracks, so
the name of the playlist is not relevant
|
|
Those are superseded by b890cf73ad, which is done after
all IOChanges have been processed.
|
|
This fixes a potential silent master-bus when re-loading a session
("mains_out" may be skipped).
|
|
Delaylines are not saved in the XML and internal-return is an
invisible processor not explicitly re-added when the state is restored.
They are [re]inserted during Route::setup_invisible_processors().
So this method need to be called after restoring processor state
(indirectly via configure_processors_unlocked as needed).
PS. During route creation this call happens explicitly and on session load
hookup_io() -> Route::output_change_handler() implicitly sets this up.
|