Age | Commit message (Collapse) | Author |
|
The motivation is to allow a Processor (here Lua) to get a pointer
to the owning Route without resorting to iterative lookup.
|
|
Monitor outs cannot be muted by other soloing. Duh.
|
|
Route::no_roll(), Route::roll(), Track::no_roll(), AudioTrack::roll()
and MidiTrack::roll() all had the exact same loop for flushing buffers
of their Delivery processors. That was a lot of replicated code that had
to be kept synchronised by hand. Put that code into a protected method
Route::flush_processor_buffers_locked() which is called instead.
|
|
this fixes an issue with jack1 and jack_latency_recompute() since must not
send a server request from inside the server callback.
|
|
|
|
luaBridge implicit inheritance uses a single direct parent
(other parents object need casts). This motivates
Route -> Stripable -> SessionObject
|
|
|
|
remote control ID and "order keys" have been removed.
|
|
Share assign code via Slavable; add visibility tags to Slavable+SlavableAutomationControl
|
|
|
|
This is better tested with direct use of the solo_control and
Config->get_solo_controls_are_listen_controls()
|
|
|
|
VCA solo+mute (BUT ARE NOT DONE YET)
|
|
and used. The controls now own their own state, rather than proxy for state in their owners.
Massive changes all over the code to accomodate this. Many things are not finished. Consider this a backup safety commit
|
|
control is enabled/disabled. Add AutomationControl::master_changed() as a virtual method to handle ... master value changes
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
* extend plugin API (query IO ports)
* collect possible variable plugin configurations (AU, Lua)
* prepare semi-automatic configuration (presets: mono, stereo, N)
|
|
|
|
Since headers only provide the declaration, function
parameters need to be documented.
|
|
|
|
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.
|
|
overall the PluginInsert API is complete.
many implementation details remain.
|
|
|
|
|
|
phase control if there is none.
|
|
significance of ParameterDescriptor
|
|
|
|
ParameterDescriptor
|
|
access to a mixbus-centric control
|
|
Route::nth_send() has the wrong semantics in Mixbus for this purpose. Probably
need to revisit this at some point
|
|
|
|
|
|
a shortcut
|
|
|
|
Executive decisions were necessary in a couple of places about the correct group disposition
behaviour, notably faderport and OSC surfaces
|
|
|
|
It used to be owned by Amp. Now it is owned by Amp's owner
|