This fixes an issue with "/route/eq/freq/0 S1":
When a newly select strip that does not have a EQ
(e.g. mixbus or master), the control from the previously
selected strip is used. -- Reported by tavasti on IRC.
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
