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 reverts commit b2bc934e21.
The commit does causes issues when a user manually removes channels:
The disk-reader's ::can_support_io_configuration() at first ignores
the user's request, forcing the output channel count to match the
DR's current channel config.
However, when configuring the DiskReader after that, channels is updated
to match the new input-count.
Even though the DR itself only plays back using the confgured I/O,
all processors after it still use the old channel count.
Only a later, second re-configuration step will apply the actual removal
to plugins and port.
PS. the original commit was mainly intended to fix a crash when
adding an instrument plugin *between* disk-writer and disk-reader
on a MIDI track.
DiskReader::refill_audio and DR::run() do check if a given playlist
is available. This is required for upcoming changes to set
DR channels to unconditionally match DiskWriter.
This was a leftover from changes made for Tracks Live, related to
the concept of an auto-return preference. We don't use this anywhere in Ardour
or Mixbus, and the concept should eventually be removed entirely.
PBD::IgnorableControllable() is no longer used.
It also was problematic, because in every case where a
Controllable is required, min/max range and usually also
get/set value are significant.
This cleans up various issues that have been accumulated over the past
and fixes bugs introduced in d4e023e1 and e31f5d99.
Previously GainControl as saved as part of the Amp, however the
automation was saved via Send (is-a Automatable).
In d4e023e1cb, the GainControl was changed a "BusSendLevel"
parameter, but AutomationList was not updated. This prevented
loading existing automation (control parameter was not found).
So far this is only used for MIDI, missing audio files are
already handled by asking a user to locate them.
The same approach doesn't work for MIDI, since there cannot be
externally referenced (embedded) .mid files (since MIDI is destructive).
This fixes a crash: missing playlist due to missing .mid,
and retains regions for missing MIDI files.
As opposed to missing Audio, we cannot use a SilentFileSource,
because MIDI files are destructive.
This also adds an API to query missing files that have been replaced
with silence to report them to the user.
This API is not official, and the upcoming official API differs.
The source-code is left in-place since most of it will be
re-usable as-is, regardless.
This fixes the following (loop-lennth > internal_playback_seek
length. Due to read-ahead on some cycles the following can happen
---
Loop From: 3528000 To: 3880800 (len: 352800)
start-sample: 3880971 playback_sample: 3528171 nframes: 96
start-sample: 3880875 playback_sample: 3528075 nframes: 192
---
which resulted in disk_samples_to_consume == 0;
This is required to toggle the strip to revert from aux-view
to the main route using the aux-send processor itself.
Discuss:
Perhaps this should be reverted, and ProcessorBox::edit_aux_send()
be removed: It is currently possible to create various
inconsistent mixer-states.
* use "Aux" on a Bus, then double-click some Internal-Send to
revert strips. But Aux remains active
* Removing sends while "Aux" is active does not disable Aux.
If the processor box was insensitive those issues won't be present.
However it is convenient to use double-click on the editor-mixer to
access a send's panner ...
* add an option to the controller configuration gui
to assign the 3x2 send banks in mixer mode
to either the upper (1-6) or lower (7-12) Mixbus sends
* This was a user request to better support the workflow
of the CoMondo Mix system
[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..
Exponential approach to zero:
1 / exp(t) == exp (-t)
we "stretch" it by a time-constant "c":
gain(t) = exp (-t * c)
To find the time t, at which the exponential approach reaches gain "g":
exp (-c * t) = g
take the log of both sides: log (exp (-c * t) = log (g)
since log (exp (x)) == x : -c t = log (g)
divide by -c : t = -log (g) / c
set g = 1e-5 and c = _a/sr and we get: t = -log (1e-5) / (_a/sr)
The iterative approach using g += c * (target_gain - g);
converges faster than the exact exp() calculation.
Except with 32-bit float, if target-gain is 1.0f and "c" is small.
With 32bit float (1.0 - 1e-5) = .9999900 is represented as
sign: +1 | mantissa: 0x7fff58 | exponent: 126
there are only 126 "steps" to 1.0. Rounding of the lowest
mantissa bit does matter. We have to assume worst-case,
and increase the required loop_fade_length buffersize.
vs. approaching 0, where there are over 2^110 steps between
zero and 1e-5.
If use_transport_fades() is false, then the declick_amp will have its gain always set to the current target (no declick).
Therefore only testing if it has reached zero is not enough, we need to check if we are declicking at all.
