Pan-automation is evaluated directly from the control-list.
::distribute_automated() does not update the controls.
However, 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 follow the same concept as PluginInsert: The Changed signal
is called on demand when evaluating automation.
This fixes pan-automation-sliders (automation-lane header) not updating.
This properly sets the port-latencies of PluginInsert owned ports as well
as handles external sends (send-target playback latency).
NB. This needs more work to ensure that Sidechain input port playback
latency is set before the feeding send queries it the connected latency.
Re-ordering process may change sidechain or external-send latencies,
but since re-ordering does not change the route's latency,
engine.update_latency() may not be called.
The processors will becomes responsible to know about loop-positions
and map latency-compensated start_sample, end_sample into the loop-range
as needed.
* Processor implement get_state(), classes derived from Processor
implement protected ::state() -- as documented in processor.h
* likewise for Route, Track: make ::state() a protected interface
* removal of "full_state", use explicit "template_save"
* use RAII/Unwind to skip saving automation-state
Immediate events are used for MIDI-Panic and to inject GUI generated
events e.g. patch-changes, note-events from the track-header
(scroomer-keyboard) and patch-change audition.
Current behavior:
- snapshot copy immediate events from ringbuffer into a buffer at
the beginning of each the cycle.
- Inject immediate events into input-buffer directly after reading the input
- process "normally"
- pass immediate event-buffer to disk-writer, so it can skip them
(don't write immediate events to disk)
- if the Route is not monitoring input: clear buffer before disk-reader
and re-inject (original) immediate events after the disk-reader
- immediate events process normally and are also sent to outputs.
This moves common code (get and fill buffers) into ::passthru()
and renames ::passthru() to ::run_route().
passthru_silence() is no longer used (it was only needed A5 style
Track::no_roll_unlocked for no-roll + disk-monitoring)
Currently ::roll() may actually be a ::no_roll() under some circumstances.
This can also happen during count-in:
transport_stopped () == transport_rolling()
and during latency-preroll:
Global session-transport speed != 0, some tracks already roll,
read data from disk and feed latent plugins.
but other non-latent tracks or busses don't roll and still have to
behave like the switch from no_roll() to roll() has not yet happened.
This changes the game WRT to monitoring as well, previously, Route:roll()
called Route::no_roll_unlocked () for conditions outlined above.
Now Track::no_roll_unlocked is called and in some cases wrongly clears
the buffers before the signal hits the disk-writer. (more work is needed
related to 61f8e53b)
On the upside this also fixes an issue with MidiTrack::no_roll not keeping
a lock while pushing data into the step-edit-ringbuffer.
This is also a step towards consolidating all entry points:
::roll(), ::no_roll(), ::silent_roll() in the Route class.
Individual Routes cannot split the process-cycle in no_roll(); roll()
by themselves. Each of the calls will flush output buffers (and offset
port-buffers). If a route feeds another route the inputs of the other
route will only see partial data.
The general goal is to align transport-sample to be the audible frame
and use that as "anchor" for all processing.
transport_sample cannot become negative (00:00:00:00 is the first audible
frame).
Internally transport pre-rolls (read-ahead) before the transport starts
to move. This allows inputs and disk to prefill the pipeline.
When starting to roll, the session counts down a global "remaning preroll"
counter, which is the worst-latency from in-to-out.
Each route in turn will start processing at its own output-latency.
Route::process_output_buffers() - which does the actual processing
incl disk i/o - begins by offsetting the "current sample" by the
route's process-latency and decrements the offset for each latent
processor. At the end of the function the output will be aligned
and match transport-sample - downstream-playback-latency (if any).
PS. This commit is a first step only: transport looping & vari-speed have
not yet been implemented/updated.
If disk-monitoring is disabled: disk-reader position is not relevant.
If Rec-arm is off: disk-writer position is not relevant.
But...
Play -> [plugins] -> Record
is basically a bounce and best done using the bounce operation.
(faster than realtime).
Input + Play -> Record -> Output
Ardour would need to align playback with the Input to be recorded
and at the same time align it with output, so that a player can play
along on the same track. That's not possible without a time-machine (or
a 2nd play processor).
While it can work in theory under some special circumstances, allowing
the disk-reader before the disk-writer is really just confusing,
error prone and valid uses cases are better handled by dedicated
operations.
We want Track to shrink, and logic consolidation is always good. Route already knew about
disk_reader and disk_writer, now it knows about _monitoring_control too
* centralize signal_latency_at_***_position to processors
* update initial-delay/roll-delay when processor order changes
* consolidate signal-latency calculation: use the same method
for processor-changes and session's post_playback_latency.
* include relative output-delay in roll-delay
* fix capture processor position & optimize stem-export latency
(roll-delay fixes pending Route:roll() update)
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
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.
_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.
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.
* consistent hpf/lpf controllables (actually hi/lo bell in 32C)
* HPT, LPF frequencies are exposed as EQ band
* don't expose filter ctrl for mixbuses/master
In the past, we skipped processing if the routes had no inputs or outputs.
But:
A route with a generator plugin should work even if it has no inputs.
A route with "sends" should work even if it has no outputs.
(flush reverb tails etc)
PS. That comment "from RT audio thread" was wrong.
Route::flush_processors () is called from flush_all_inserts()
from Session::non_realtime_stop() which is not in rt-context.
Besides, the processor-lock regardless of the process_lock.
This prevents a scenario where the route has had its solo control's state set from
XML, but then we configure the route's output, and invoke output_change_handler().
Without the new conditional, this would check which downstream routes are soloed,
find none, and then unset the soloed-by-downstream state of the solo control.
Moves global update of solo state and emission of Session::SoloChanged to
a single point after 1 to N solo controls are changed.
Also avoid unnecessarily emitted Activated() signal for listen controls,
though Process::{activate,deactive}() should probably be redesigned to
avoid this in a "deeper" way
This should be the final part of a fix for bug #7025, which means the id
property of PBD::Controllable is restored and a new id is not generated at
first save.
I'm assuming this was a typo, comparing with the wrong name meant the state of
the MuteControl was never being restored. This also fixes restoring bindings
associated MuteControl instances.
This [hopefully] fixes jack1 zombification on session-load with large
plugin-states. Previously it was possible to block
Route::process_output_buffers().
The trim processor was moved to the front after the internal return was,
so the trim setting was applied before the signal coming from other
tracks/busses sends was mixed in. Change the order so that trim applies
to audio from internal sends as well.
When flushing the buffers of Delivery processors owned by a Route/Track,
inner deliveries of PortInsert processors were missed since PortInsert
is not a Delivery subclass, but rather owns a Delivery as a private
member. Expose a flush_buffers() for PortInsert and call it too.
This is correct since (external) Send is a Delivery subclass, so that
just makes the send part of inserts behave as external sends do.
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.
If a route has strict I/O then the main delivery follows the output of
the last processor, but libardour ensures it has at least as many
outputs as inputs in the master strip. A good consequence is that mono
tracks get their expected panner.
An akward side-effect is that MIDI-only routes (e.g. midi tracks or busses
without a synth) get two audio channels that have no use (and indeed no
panner is added because there is nothing to pan).
Skip the completion of audio outs if there was no audio out to begin
with.
Pass current (latency compensated) cycle times to plugin.
This fixes time-reporting to plugins and also fixes automation
and when bouncing (the session->transport* is not valid) etc.
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
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.
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.
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).
This also removes Route::group_gain_control() and associated machinery.
Not yet tested with Mackie or other surfaces. More work to done to
start using the group capabilities, and also potentially to add
or derive more controls as RouteAutomationControls
The EQ and compression parts do nothing for Ardour, where there is no identifiable and understood plugin to perform their
roles. They do work on mixbus, which also serves as a model for how to do this.
Classes derived from AutomationControl now check ::writable() in their ::set_value() methods to ensure that they
do not attempt to overwrite data sent to them while automation playback is underway.
- don't attempt to insert two points on toggle.
- remove forced touch->write mode change on toggle
- initial state still wrong, but works much better overall.
Ben Loftis
Robin Gareus
John Emmas
Paul Davis
Johannes Mueller
Tim Mayberry
Julien "_FrnchFrgg_" RIVAUD
Len Ovens
nick_m