Depend on Changed() signals alone, which are usually much less frequent
than rapid-timer events.
As side-effect we now need to make the widgets insensitive when
playing automation. Previously the user could not change the value because
the Timer periodically reset it.
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.
`.config/ardour5/(templates|route_templates)`.
We put as toplevel directory of the archive `templates` or
`route_templates`. Then no matter if the user imports a session template or a
route template archives, we always put them into the correct folder.
As now the user can also import route templates while the
SessionTemplateManager is visible and vice versa, we need to signal the
successful import to the corresponding template manager. Therfor we introduce
the signal TemplatesImported.
Instead of and-ing the first byte to extract the event type, it is
simpler and easier to understand to bitwise-shift it, so that we don't
get the result as a multiple of 2^4, but as values corresponding to the
MIDI specification.
Currently, a guard is put against events with completely empty data,
though maybe ardour discards those earlier on since that would not be
valid MIDI.
Don't use this now, except for testing as the archive format will change.
TBD:
* error handling
* check template would be overwritten by import
* dinstinguish between session and track templates
This concernes:
* LV2 states:
LV2 states are stored in the template directories and their paths are stored
int the template files using absolute paths. Therefore we have to adjust the
template-dir property of every lv2 node referring to a state dir.
* Names of route templates.
The name of the route template is stored in the first child of the xml root
node in the property `name`. This needs to be adjusted when renaming the
template.
By now we rely on that only lv2 states and the route template name need to be
adjusted on renaming a template.
Following measures:
* Split up into two classes
* TemplateDialog: the general dialog
* TemplateManager: A widget to rename and remove templates
* Make TemplateManager abstract and derive a class for session templates and
one for route templates. This is needed, as session templates and route
templates are stored in a different way. Thus we need different methods to
rename and remove them.
Goal is to a simple dialog that can rename and remove templates. This is
helpful in order to keep the template list tidy.
So far it works for session templates. Track templates tbd.
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.
When tracks in a gain-sharing group are selected, stepping gain
up/down affected the tracks N times:
for-each selected track inc/dec gain w/grouping.
When a mix of grouped and un-grouped tracks is selected, this lead to
inconsistent gain changes.
The new approach expands the groups first. Ignoring groups is not correct
either for single selection.
_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.
