Age | Commit message (Collapse) | Author |
|
Stripables and AutomationControls
|
|
It looks like MonitorControl::_monitoring is unused and should be removed.
The actual value is Evoral::Control::_user_value
|
|
|
|
|
|
|
|
Fixes warning during session loading
|
|
|
|
* rename: indicate that recording happens after preroll, punch-in
* move API into libardour: rec+roll (no separate setup, seek, roll APIs)
|
|
|
|
|
|
|
|
|
|
So that MIDI in the ports is really made silent.
|
|
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.
|
|
|
|
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.
|
|
|
|
remote control ID and "order keys" have been removed.
|
|
Make it be based on the ParameterDescriptor, which indicates toggle status anyway
|
|
|
|
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
|
|
GroupControlDisposition)
This allows the signal to convey more information, which may be required by some handlers of a control's Changed signal
|
|
|
|
|
|
significance of ParameterDescriptor
|
|
AutomationControl for track monitoring choice
|
|
|
|
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
|
|
AutomationControl::writable() and use them.
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.
|
|
|
|
Paul Davis was responsible for introducing almost all of this.
|
|
This drastically-stripped down version of the Ardour original is used only when USE_TRACKS_CODE_FEATURES
is defined. It doesn't respond to many aspects/features of libardour.
|
|
|
|
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
|
|
Work towards ParameterDescriptor being used more universally to describe control characteristics.
|
|
using auto-input
|
|
user pressed stopped (2) captured regions should end where the playhead ends
|
|
|
|
non-capture driven MIDI region creation operations).
See comments in Session::new_midi_source_name() for details.
|
|
|
|
fixes
* http://tracker.ardour.org/view.php?id=5628
* http://tracker.ardour.org/view.php?id=5561
|
|
"scratch buffers are by definition scratch and their contents are undefined at all times"
"silent buffers are by definition all-zero and should not be used for real data"
But track & route were using those for actual data; plugins (which may run
in the same thread and may get the same buffers) use them for scratch thereby
overwriting real data.
In particular get_silent_buffers() (used by LadspaPlugin::connect_and_run)
clears the buffer which can holds real data:
e.g. via Route::passthru_silence() -> plugin1 -> plugin2 (clears output of plugin1)
|
|
|
|
..and continue to calculate fall-off in
audio-cycle (rather than UI thread)
TODO: check if this works properly when switching
between audio/midi meter modes on a midi-track.
One of the motivations to always reset meters when the
meter-point changes was to resolve peak-hold & fall-off
issues when a midi-meter replaces an audio-meter and vice
versa.
|
|
|
|
|
|
|
|
"explicit Monitor DISK" + "Transport Stop" + "not track rec-en"
-> meter is always zero
|
|
for state descriptions see
http://www.oofus.co.uk/ardour/Ardour3MonitorModesV3.pdf
|
|
|