| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
|
|
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.
|
|
Do not use AutomationType to identify parameters, use complete
Evoral::Parameter and Automatable.
For "batch connections", a Slavables needs to implement an API to return
the relevant controls.
This is only a first step towards a more generic Master/Slave framework.
|
|
|
|
|
|
|
|
* The UI and ctrl-surface controls use and display the combined value,
including control-masters.
* The Automation lane of a control is the raw value of the control
without masters.
When touching (or writing) automation, the control-master needs to be
factored out (or subtracted). e.g press+hold a control -> write inverse
master automation.
|
|
|
|
* remember master-ctrl value on assignment & save with session
* Control/AutomationCtrl only stores ctrl's own value (w/o master)
* virtual AutomationControl::get_value () -> use SlavableAC method
* MasterRecord uses weak-ptr (fixes recursive ~Controllable() deadlock)
|
|
|
|
The crashed previously because:
A VCA is-a Automatable is-a Evoral::ControlSet
After VCA's d'tor completes ~Automatable runs and emits signal to
DropReferences of all master-controls.
This in turn calls SlavableAutomationControl::master_going_away()
for slaved parameters for the given master-control
In ::master_going_away() the weak-pointer reference to the master's
AutomationControl (owned by the destroyed VCA) is still valid.
Execution is in the d'tor of Automatable which is-a ControlSet and
the ContolSet keeps a reference to the Control and hence also to the
AutomationControl which is-a Evoral::Control.
So master_going_away() locks a boost::shared_ptr<ARDOUR::AutomationControl>
which is actually the MuteControl owned by the VCA.
It calls SlavableAutomationControl::remove_master() which
in turn calls MuteControl::pre_remove_master() which uses the
MuteMaster API to retrieve the value. The MuteMaster however is the
VCA that has just been destroyed.
The solution is twofold:
1) emit "drop_references" from the VCA d'tor itself,
before the VCA is destroyed.
2) disconnect a slaved control from the master's drop_references signal
when un-assigning a master-control.
|
|
|
|
|
|
Basic infrastructure to allow VCA automation and Trim automation:
look up events during automation playback.
|
|
master(s) value now just scales the control's own value; a trivial
bit of math at assign/deassign ensures that values do not change
during add/remove master operations
|
|
up back in the same state
|
|
void to bool, to indicate if value was changed."
This reverts commit c104c9d4726f3ba1ecd352d13b88a57f2f964510.
|
|
bool, to indicate if value was changed.
Don't call Session::set_dirty() when no change occurs
|
|
|
|
Share assign code via Slavable; add visibility tags to Slavable+SlavableAutomationControl
|
|
|
|
it usefl
|
|
|
