Age | Commit message (Collapse) | Author |
|
Replacement to follow in subsequent commit
|
|
So far internal-sends were explicitly special-cased, and implicit
solo-state only was only forwarded for direct up/down-stream
connections. ...and nobody can remember why :)
This restriction is removed, so far mainly with commenting-out
code, as experiment.
Internal sends are not only more convenient, but also required
in cases where direct connections result in ambiguous latency.
|
|
This fixed a false-positive "ambiguous latency" warning for
MIDI busses:
MIDI track -midi-> MIDI Bus w/instrument -audio|midi-> master
The master-bus only has audio inputs, so the MIDI Bus'
MIDI out is left unconnected. Its latency does not matter,
it can float freely.
Previously it was assumed to be zero. So the MIDI Bus' input
playback latency range was [0, master-bus playback-latency].
|
|
|
|
-DLatency now triggers all four:
* LatencyCompensation (entry-points, overall flow)
* LatencyIO (Port/IO query, set/get private/public)
* LatencyDelayLine (Delaylines for internal sends and alignment)
* LatencyRoute (route processor latency)
|
|
|
|
|
|
Various backends have different strategies for updating latencies,
and different thread semantics for latency update callbacks.
With jack2 it is possible that processing happens concurrently
while port latencies are being changed.
Ardour internal backends emit the latency callback from the
main process thread, serializing latency changes with processing.
Various user actions can also trigger latency changes. e.g.
with a stopped engine it is possible to re-order plugins.
|
|
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.
|
|
|
|
|
|
Session::listen_position_changed() calls Route::listen_position_changed()
for every route in the session. Each call tool the process-lock
in turn.
|
|
* 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)
|
|
* Remove unused direct calls into plugin
* Assume empty model to mean plugin-provided MIDNAM (!)
The route owned Instrument-Info is the central access point used
by the GUI for MIDI name lookups.
At this point in time, custom settings are saved/restored by the
GUI (MidiTimeAxisView). InstrumentInfo provides a volatile store
for MIDNAM mode and model.
|
|
This fixes another assert(), caused by configuring processors,
before set_processor_state() was called.
Route::configure_processors() will be called later.
---
#3 0x00007ffff2472102 in __GI___assert_fail at assert.c:101
#4 0x00007ffff7a8ca1f in ARDOUR::Route::setup_invisible_processors() at ../libs/ardour/route.cc:5013
#5 0x00007ffff7a7a665 in ARDOUR::Route::configure_processors_unlocked at ../libs/ardour/route.cc:1870
#6 0x00007ffff7a79377 in ARDOUR::Route::configure_processors at ../libs/ardour/route.cc:1719
#7 0x00007ffff7a902c0 in ARDOUR::Route::set_disk_io_point at ../libs/ardour/route.cc:6041
#8 0x00007ffff7a7ea0a in ARDOUR::Route::set_state at ../libs/ardour/route.cc:2679
|
|
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
|
|
This fixes the following issue:
On the master channel insert the waveform scope before the fader.
Then set the meter position to custom and move the meter to the
very beginning of the chain.
Before this change, when set_meter_point() was called the
processor list only contained the Fader (_amp) and no other
processor. _main_outs was not yet present in the list, and
Route::maybe_note_meter_position() triggered an
and assert(_processor_after_last_custom_meter.lock());
See also d0dca7daf0
|
|
|
|
|
|
This also consolidates code to test if a processor can be frozen
from various places.
|
|
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"
|
|
|