This was a leftover from changes made for Tracks Live, related to
the concept of an auto-return preference. We don't use this anywhere in Ardour
or Mixbus, and the concept should eventually be removed entirely.
PBD::IgnorableControllable() is no longer used.
It also was problematic, because in every case where a
Controllable is required, min/max range and usually also
get/set value are significant.
This cleans up various issues that have been accumulated over the past
and fixes bugs introduced in d4e023e1 and e31f5d99.
Previously GainControl as saved as part of the Amp, however the
automation was saved via Send (is-a Automatable).
In d4e023e1cb, the GainControl was changed a "BusSendLevel"
parameter, but AutomationList was not updated. This prevented
loading existing automation (control parameter was not found).
This fixes a crash: missing playlist due to missing .mid,
and retains regions for missing MIDI files.
As opposed to missing Audio, we cannot use a SilentFileSource,
because MIDI files are destructive.
This also adds an API to query missing files that have been replaced
with silence to report them to the user.
This fixes the following (loop-lennth > internal_playback_seek
length. Due to read-ahead on some cycles the following can happen
---
Loop From: 3528000 To: 3880800 (len: 352800)
start-sample: 3880971 playback_sample: 3528171 nframes: 96
start-sample: 3880875 playback_sample: 3528075 nframes: 192
---
which resulted in disk_samples_to_consume == 0;
* add an option to the controller configuration gui
to assign the 3x2 send banks in mixer mode
to either the upper (1-6) or lower (7-12) Mixbus sends
* This was a user request to better support the workflow
of the CoMondo Mix system
[Re]name sidechain port directly when a plugin is added.
Usually plugins are constructed without an Route (owner is unset).
PluginInsert c'tor may already create a side-chain port, at the
time of construction the sidechain port will be created using
the port-name "toBeRenamed".
Previously the plugin had to be added to a route using "add_processor",
in order to set a unique name, before a new plugin with sidechain
could be constructed.
ProcessorBox::use_plugins() did that in the correct sequence,
however there may have been cases where this didn't work, and
Route::add_processors() was called directly..
Exponential approach to zero:
1 / exp(t) == exp (-t)
we "stretch" it by a time-constant "c":
gain(t) = exp (-t * c)
To find the time t, at which the exponential approach reaches gain "g":
exp (-c * t) = g
take the log of both sides: log (exp (-c * t) = log (g)
since log (exp (x)) == x : -c t = log (g)
divide by -c : t = -log (g) / c
set g = 1e-5 and c = _a/sr and we get: t = -log (1e-5) / (_a/sr)
The iterative approach using g += c * (target_gain - g);
converges faster than the exact exp() calculation.
Except with 32-bit float, if target-gain is 1.0f and "c" is small.
With 32bit float (1.0 - 1e-5) = .9999900 is represented as
sign: +1 | mantissa: 0x7fff58 | exponent: 126
there are only 126 "steps" to 1.0. Rounding of the lowest
mantissa bit does matter. We have to assume worst-case,
and increase the required loop_fade_length buffersize.
vs. approaching 0, where there are over 2^110 steps between
zero and 1e-5.
If use_transport_fades() is false, then the declick_amp will have its gain always set to the current target (no declick).
Therefore only testing if it has reached zero is not enough, we need to check if we are declicking at all.
With 4MB RAM and 1.5MB locked base memory (C++ bindings),
TLSF has a better worst-case performance (-20% std-dev
execution time compared to realloc-pool).
Even though on average Realloc-Pool performs better (-9%
average time, compared to TLSF).
Since Lua function arguments are not typed, there is no
explicit "const", and a function can always modify the parameter.
When passing `ChanMapping const&` as argument, the object is
copy constructed. In this specific case the std::map<> members
of ChanMapping allocate memory.
Passing a pointer to the object works around this issue.
LuaBridge later dereferences the object as needed when calling
c++ methods, and copy-construction would only happen later.
ARDOUR::Session::remove_routes() explicitly calls
save_state (_current_snapshot_name)
Update assert() to treat an empty name
equivalently as explicitly specified _current_snapshot_name
undo may restore locations, which may trigger a state-save.
This can result in a deadlock:
Location::set_state () -> Locations::get_state()
both acquire a the same lock:
#2 0x000055a8421836d0 in Glib::Threads::Mutex::Lock::Lock(Glib::Threads::Mutex&) (this=0x7ffe38dcad40, mutex=...) at /usr/include/glibmm-2.4/glibmm/threads.h:687
#3 0x00007fc637731e9c in ARDOUR::Locations::get_state() (this=0x55a8466d4740) at ../libs/ardour/location.cc:1075
#4 0x00007fc637bf14b7 in ARDOUR::Session::state(bool, ARDOUR::Session::snapshot_t, bool)
(this=0x55a846d0f050, save_template=false, snapshot_type=ARDOUR::Session::NormalSave, only_used_assets=false) at ../libs/ardour/session_state.cc:1406
#5 0x00007fc637bed2c8 in ARDOUR::Session::save_state(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, bool, bool, bool, bool)
(this=0x55a846d0f050, snapshot_name="", pending=true, switch_to_snapshot=false, template_only=false, for_archive=false, only_used_assets=false) at ../libs/ardour/session_state.cc:815
#6 0x00007fc637b4d967 in ARDOUR::Session::auto_punch_start_changed(ARDOUR::Location*) (this=0x55a846d0f050, location=0x55a848fe11d0) at ../libs/ardour/session.cc:1395
#7 0x00007fc637b4da21 in ARDOUR::Session::auto_punch_end_changed(ARDOUR::Location*)
(this=0x7fc637b4da21 <ARDOUR::Session::auto_punch_end_changed(ARDOUR::Location*)+67>, location=0x7ffe38dcbf10) at ../libs/ardour/session.cc:1403
[..]
#14 0x00007fc637730a2a in ARDOUR::Location::set_state(XMLNode const&, int) (this=0x55a848fe11d0, node=..., version=6000) at ../libs/ardour/location.cc:715
#15 0x00007fc637732428 in ARDOUR::Locations::set_state(XMLNode const&, int) (this=0x55a8466d4740, node=..., version=6000) at ../libs/ardour/location.cc:1130
#16 0x000055a842388dd7 in MementoCommand<ARDOUR::Locations>::undo() (this=0x55a84d1e5f10) at ../libs/pbd/pbd/memento_command.h:141
#17 0x00007fc635b50707 in UndoTransaction::undo() (this=0x55a84d513b80) at ../libs/pbd/undo.cc:128
#18 0x00007fc635b50e1c in UndoHistory::undo(unsigned int) (this=0x55a846d11338, n=0) at ../libs/pbd/undo.cc:267
#19 0x00007fc637c0dfff in ARDOUR::Session::undo(unsigned int) (this=0x55a846d0f050, n=1) at ../libs/ardour/session_state.cc:5577
This is in preparation for saving state while the session is
record-arm'ed. Most notably config changes and undo/redo.
In case both normal and pending save happens, pending must be
last and is required to recover from crashes during recording.
This builds on top of 51d2bb:
* v6 routes templates/states have a version per <Route>
* older route-states are assumed to be from ardour-5
Stateful::loading_state_version 3002,
unless specified otherwise
Currently using Ardour-5 route templates (state version "3002")
with Ardour6 fails. As opposed to session-templates, Route
templates were not versioned.
This ensures future compatibility (and may allow to interpret
unversioned templates as "3002")
Loop recording creates a single long source, regions have to be
"split" from this source, using "start" as offset.
Since MIDI uses absolute timestamps, offsetting this by accumulating
buffer_position += (*ci)->samples;
like Track::use_captured_audio_sources() does, is not correct.
Furthermore, record_enabled() may be off when stopping recording,
MIDI needs to be flushed regardless.
DiskWriter::transport_looped() is called from the session
when engine loops. This does not take local disk-reader run()
latency offset into account.
finish_capture() needs to be postponed until the disk-writer
itself reaches the loop-position. This is achieved by
postponing loop() and calling it once loop-length of samples
has been captured.
This works because engaging loop always seeks to the loop-position
and first loop resets _capture_captured.
Ardour 5.x slave check was incorrectly ported to A6's TMM:
In Ardour 5 the comparison tested for *not* MTC:
```
if (!dynamic_cast<MTC_Slave*>(_slave)) { ..send MMC.. }
```
Other MMC messages (Record, Locate) are sent unconditionally.
This fixes an issue that after changing backends (::set_backend),
the session-transport was in inconsistent state. If it was rolling,
it continued to roll with "stop" being unavailable.
set_session_extents had a bug; it wasn't calling locations->add()
on the newly created location.
The correct implementation was in set_session_range_location,
but this was only called from one place.
This function was removed, and set_session_extents will be used in its place.
set_session_extents will create a session location if one no longer exists,
so there is no need for set_session_range_location.
* Windows: delete waf installed .dll.a files
* Windows: override waf's conf.env.LIBDIR = conf.env.BINDIR
with explicit --libdir
* Windows: fix asm (`x86_64-w64-mingw32-as` -D flag is for
debug messages, -D defines are not available)
* Mac: override waf adding -install_name (and
-Wl,-compatibility_version -Wl,-current_version)
by moving -dynamiclib from linkflags to ldflags
* Mac: Allow libs with compat version number suffix
(not needed anymore, but may help in the future)
Previously this was inherited via PBD.
On MacOS/X, this adds
"-undefined dynamic_lookup -flat_namespace"
and various "-framework .." options to linkflags
Without this flag, .dylibs fail to link usually because
of missing `-lintl` (Undefined symbols: "_libintl_dgettext")
On other systems this is a NO-OP:
CFLAGS_OSX, CXXFLAGS_OSX and LINKFLAGS_OSX
are only set on the darwin platform.
In prior versions: if Auto Input was enabled, the default behavior was
to monitor the Input of all tracks when stopped; even if they aren't armed.
Tape Machine Mode changed the behavior of Auto Input so that it doesn't
always monitor the track inputs when transport is stopped.
After some discussion on IRC, we determined that Tape mode is likely
more practical for a DAW user, and therefore a better default.
Rather than default an ambiguously-named preference "on", we decided
to invert the behavior, rename it sensibly(?), and default it OFF.
