Rule #89: The *owner* of each automation-control is responsible to
evaluate automation of automated automation-controls (and emit Changed()
signals to notify the GUI and slaved controls).
This can happen during run(), when the Processor evaluates automation
(eg. PluginInsert does that), but needs to regardless, every cycle.
Emit Changed signal for GainControl
This follow the same concept as PluginInsert: The Changed signal
is called on demand when evaluating automation.
Note: MuteControl already implemented this,
This removes the special case of boolean_automation_run().
Likewise this removes special-cases for actually_set_value() during
automation playback.
Template files reside in
.config/ardour5/templates/$(template_name)/$(template_name).template
We run through .config/ardour5/templates/ and find there the names of the
directories the .template-files are located in. These directory names don't
have a .template extension. So we shouldn't try to chop the non existing
extension of, because then we only modify template names with a '.' in them.
_processors = new_list; may drop the last shared-ptr reference.
This may deadlock in ~IO() for I/O processors or plugins with sidechain
inputs. It's been mostly a non-issues since the GUI usually holds a last
shared-ptr reference for a processor to be deleted, but that is
not always the case.
AudioRegion::set_fade_in() freezes the original ControlList, then
assigns a new one and thaws that.
Frozen state needs to be retained during assignment.
Related: The overloaded assignment operator in AutomationList
performed duplicate signal emission and didn't freeze the list.
And it's actually mostly moot. interface_to_internal maps
any range to 0..1.
The GUI could just hardcode min/max 0, 1 and steps 1/30, 1/300.
Except for controls that have explicit range-steps & ctrl surfaces.
Ardour may have ignored log-scale for parameters 0..N and allowed
writing '0'. Force those values into the valid range on session load.
Also mark the list as "needs sorting" which removes potential duplicates.
This reverts commit e9ee454ced.
This needs more work to preserve non-customized panners in existing
sessions. "user-panner" is only set if a user explicitly selects a
panner.
The midi_input_handler for the AsyncMIDIPort is connected to the
main event-loop. Events may still be delivered after the surface was
destroyed.
That by itself is not harmful, unless a given message produces a reply:
The _output_port is already gone, FaderPort8::tx_midi crashes.
When triggering Session::undo() or Session::redo() from a
non-GUI-thread (e.g. from a surface protocol) Ardour crashes if setting a
CairoWidget dirty due to a ENSURE_GUI_THREAD assertion. (see #7371)
By triggering undo by BasicUI::access_action() rather than by Session::undo()
we ensure that the GUI thread will finally call Session::undo().
So more like a workaround ... but better than crashing :)
