| Age | Commit message (Collapse) | Author |
|---|
|
When we create a new session and are using a template from an old version of
Ardour, we should not issue the VersionMismatch dialog and not make a copy of
the session file for the old version.
We need to extend the signature of Session::load_state() to tell it if we are
creating a session from a template. Session::_is_new cannot be used for it
because it has a the semantics if to auto connect the the master bus.
|
|
|
|
Old STL has an issue with ambiguity
reverse_iterator rend();
const_reverse_iterator rend() const;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Always use InstrumentInfo for lookups.
Remove name lookups that directly used gui_property()
* Use set/get_gui_property() only to save/restore state,
push custom selection to InstrumentInfo.
* Only store custom selection, use unset for "default"
default = plugin-provided (if available) otherwise general-midi
|
|
* Remove unused direct calls into plugin
* Assume empty model to mean plugin-provided MIDNAM (!)
The route owned Instrument-Info is the central access point used
by the GUI for MIDI name lookups.
At this point in time, custom settings are saved/restored by the
GUI (MidiTimeAxisView). InstrumentInfo provides a volatile store
for MIDNAM mode and model.
|
|
This reworking avoids some confusion caused by the use boost::optional here
|
|
|
|
|
|
|
|
misleading/confusing)
|
|
This is intended to be a no-op that makes the code easier to read/reason about
|
|
position in a DiskReader, pay attention to loop status
If the last read was not looped, but the new one should be, we need to ignore the heuristic. Ditto for vice-versa.
This isomorphic with the read-reversed case
|
|
Most of Ardour's GUI queries route->instrument_info() for MIDNAM.
This is a minimal invasive hotfix to update the PatchChange
dialog and patch-names on the timeline when the MIDNAM selection
changes.
This got lost in de74cca6b8.
|
|
Retain selection when showing context-menu.
|
|
This fixes another assert(), caused by configuring processors,
before set_processor_state() was called.
Route::configure_processors() will be called later.
---
#3 0x00007ffff2472102 in __GI___assert_fail at assert.c:101
#4 0x00007ffff7a8ca1f in ARDOUR::Route::setup_invisible_processors() at ../libs/ardour/route.cc:5013
#5 0x00007ffff7a7a665 in ARDOUR::Route::configure_processors_unlocked at ../libs/ardour/route.cc:1870
#6 0x00007ffff7a79377 in ARDOUR::Route::configure_processors at ../libs/ardour/route.cc:1719
#7 0x00007ffff7a902c0 in ARDOUR::Route::set_disk_io_point at ../libs/ardour/route.cc:6041
#8 0x00007ffff7a7ea0a in ARDOUR::Route::set_state at ../libs/ardour/route.cc:2679
|
|
When limiting the message count (e.g. for display in a dialog),
use reverse order, and only print errors.
When loading a session fails, the most recent error is
more likely the real cause.
|
|
If the user has an audio interface with 32 inputs, there is the danger, that
they click through the route template list and hit "Generic Audio Track" which
then sets the number of routes to be added to 32. When they click back to
e.g. "Audio Tracks" this number remains at 32. So they will accidentally add 32
audio tracks although they wanted just one. Somewhat inconvenient.
By this commit we remember the number of routes to be added, when it is set by
a lua template and thus can set it back when the user clicks back on a route
type that does not set it.
|
|
Amend c765079b2f, remove Mixbus special-case for Ardour
|
|
Detaching the editor would cause the inactive_name labels and
to mixer-strip elements to appear (due to show_all).
|
|
|
|
|
|
|
|
|
|
"last sample"
It makes no sense to every align a region start/sync point during a drag or alignment operation
with the last sample of another region. It only makes sense to align with the position immediately
after the last sample of the other region (e.g. directly sequencing regions).
|
|
Optimized builds of Ardour use various _finite math methods
(due to -ffast-math). Those functions have apparently been
removed, and replaced with macros and are no longer available
in libm/libc++.
see also
https://discourse.ardour.org/t/a-eq-and-a-comp-fail-on-manjaro-xfce/103122
https://lists.gnu.org/archive/html/info-gnu/2020-02/msg00001.html
|
|
|
|
Since rebuilding peaks does not call drop-references, the WaveView
is not explicitly released. and ArdourWaveView::WaveView
keeps a shared pointer reference to the AudioRegion.
This also fixes a memory leak, waves, tmp_waves store C++ pointers,
not shared pointers. Explicit delete is required
|
|
|
|
|
|
|
|
Previously set_state() -> set_meter_point() acquired the
process-lock to change meter-position, usually causing x-runs
when setting route-state.
This also fixes an issue introduced in fd414ec158. After
populating the processor list, force setting the meter-position
looks up the output streams of the processor before the meter.
However the processors are not configured. That will only happen
later from Session::post_engine_init().
---
#3 0x00007ff07b7d4102 in __GI___assert_fail at assert.c:101
#4 0x00007ff080d3224a in ARDOUR::PluginInsert::output_streams() const at ../libs/ardour/plugin_insert.cc:289
#5 0x00007ff080de8c30 in ARDOUR::Route::set_meter_point_unlocked() at ../libs/ardour/route.cc:4106
#6 0x00007ff080de8699 in ARDOUR::Route::set_meter_point(ARDOUR::MeterPoint, bool) at ../libs/ardour/route.cc:4037
#7 0x00007ff080ddfad3 in ARDOUR::Route::set_state(XMLNode const&, int) at ../libs/ardour/route.cc:269
|
|
This re-introduces 4262d701ebcf in a different manner.
|
|
|
|
|
|
|
|
This fixes the following issue:
On the master channel insert the waveform scope before the fader.
Then set the meter position to custom and move the meter to the
very beginning of the chain.
Before this change, when set_meter_point() was called the
processor list only contained the Fader (_amp) and no other
processor. _main_outs was not yet present in the list, and
Route::maybe_note_meter_position() triggered an
and assert(_processor_after_last_custom_meter.lock());
See also d0dca7daf0
|
|
This can help when running with very low latency and the
initial process callback is [indirectly] expensive.
E.g. load a heavy session the a RPi4, initial setup can pull
in a lot of data, which blocks the bus.
In particular with the ALSA backend this can lead to poll timeout
which effectively stops the backend.
|
|
|
|
|
|
|
|
|
