Age | Commit message (Collapse) | Author |
|
GroupControlDisposition)
This allows the signal to convey more information, which may be required by some handlers of a control's Changed signal
|
|
Route now calls back into Session when solo/mute/listen state changes. All other interested
parties must use the Route::{solo,mute,...}_control()->Changed() to be notified of changes.
The Session requires more information than the Changed signal can provide, in order to
propagate solo/mute changes across the entire Session correctly.
Note that this uses an experimental use of CRTP to isolate a public API within Session
|
|
logic and consistent master/slave behaviour
|
|
AutomationControl
|
|
|
|
|
|
|
|
This allows sane state save/restore
|
|
|
|
|
|
|
|
|
|
* fixes drag/copy'ing sidechain sends (autodestruct)
* reduce duplicated code
* prepare for instrument replacement
|
|
|
|
|
|
..to prevent switching forth and back during individual
::state(), ::set_state() when loading/saving the session or locating.
|
|
This reverts commit 2b7a047e92bc5ebe3287860ff9c9f2fb0acb193c.
|
|
|
|
|
|
|
|
Fixes an issue with Mixbus where set_active() is a NO-OP for mixbusses.
|
|
|
|
|
|
When adding a processor, the processor may add ports leading to
a call to jack_port_register(). while Ardour holds a WritertLock on the
processor-list (this commit removes this WriterLock).
with jack2 that results in a graph-reorder callback (WHY?)
jack2 issues that graph-reorder in a separate thread BUT
port-registration does not return until the graph-reorder is complete.
On Ardour's side, graph_reordered() calls Session::resort_routes ()
which eventually checks Route::direct_feeds_according_to_reality()
which needs a ReadLock on the processor-list to check I/O.
Since jack_port_register() does not return, this constitutes a deadlock.
THE ACTUAL PROBLEM IS JACK2's THREAD DESIGN!
Why does jack_port_register() trigger a graph-order in jack2?
No connections are made.
..and why does it block jack_port_register() from returning if
that graph-order callback is in a different thread?
http://pastebin.com/DZANXJLz
|
|
|
|
|
|
The idea is to dynamically add/remove sends for feeding a sidechain
and re-use all existing "External Send" infrastructure in particular
latency compensation.
|
|
monitor follows the master bus outs,
auditioner is fixed stereo and synth dependent.
(fixes crash when adding/removing the monitor section)
|
|
* extend plugin API (query IO ports)
* collect possible variable plugin configurations (AU, Lua)
* prepare semi-automatic configuration (presets: mono, stereo, N)
|
|
|
|
try_configure_processors_unlocked() needs process lock
|
|
Ardour features N in -> M out panners. It can make sense that
the last processor has fewer outputs than the route.
In Mixbus this is not the case.
|
|
|
|
|
|
|
|
|
|
|
|
Prevent class descriptions inheriting the doc from PBD:Stateful by
adding some specific doc.
|
|
|
|
|
|
|
|
When building the process graph. Ardour usess
Route::direct_feeds_according_to_reality()
This function only tests if the current route (or any ioprocessors)
is feeding another route's *input*.
Inserts, Return and now Sidechains are ignored as destinations on the
destination route are not taken into account.
This is now resolved by adding an IOVector, a collection of all inputs
of the destination route.
|
|
|
|
Processor and Process lock are needed, and the plugin chain needs to be
reconfigured, so this cannot be directly performed by the plugin.
|
|
|
|
|
|
|
|
This allows a user to override strict-i/o per processor.
The downside (currently): all downstream effects will be clamped to
the customized outputs (not the actual track's inputs)
This also introduces an new issue with re-config on session-load (missing
code to handle this).
|
|
* fix MIDI-bypass
* prepare combined channel-map report (for GUI)
* fix route failed config return
|
|
|