When loading the state of a Route fails (here
"unknown enumerator SurroundMaster in PBD::EnumWriter"), the
routes which have already been loaded are not added to the
Session's routelist.
Already existing routes that have an InternalSend or have
a circular reference:
The Send's `_send_from` holds a shared pointer
`<Route>(shared_from_this())` to the Route, and the
Route's ProcessorList contains the InternalSend.
This leads to various
"SessionHandleRef exists across session deletion" of
IO, Ports, GraphNode, Graph, etc
which causes issues when loading another session.
Session::destroy() cleans calls drop_references for
each route in the RouteList, which breaks the circular
dependency (InternalSend drops reference to Route).
But here the RouteList is empty.
Crash fixed:
* Load a session that fails to load a Route
(here a session created on with the vapor branch, on master)
* Then load another session without restarting Ardour.
* add spaces around "->"
* consistently use "time domain" (instead of "timebase")
* remove "Edit ->" from "Preferences" (on macOS Prefs
are not in the edit menu
When copying a mono LV2 plugin to a stereo track, the
state of the copied mono plugin is copied to the replicated
instance.
However at this point in time PBD::Stateful::ForceIDRegeneration
is still enabled, and the state ID has not been set.
This used to not be an issue. Older versions of liblilv
handle non-existent paths just fine.
However in lilv v0.24.20-10-gdd5e851 `lilv_path_absolute`
was replaced with `zix_canonical_path` which returns NULL
if a state file does not [yet] exist. This lead to a segfault
due to strlen(NULL) in `serd_node_new_file_uri`:
#0 strlen -- SEGV on unknown address 0x000000000000
#1 serd_node_new_file_uri () at /lib/x86_64-linux-gnu/libserd-0.so.0
#2 lilv_state_new_from_file () at /lib/x86_64-linux-gnu/liblilv-0.so.0
#3 ARDOUR::LV2Plugin::set_state(XMLNode const&, int) at ../libs/ardour/lv2_plugin.cc:2320
LUA EditorAction script to chronologically reverse MIDI notes
of selected MIDI regions, alongside MIDI region positions.
* The positions of the MIDI regions are reversed as well, meaning regions
at the end appear at the beginning and so on.
* Individual notes are reversed so the ending of a note corresponds to its
beginning. Thus notes should be quantized for this effect to yield good
results.
* Note that only MIDI notes are reversed. Other MIDI events such as CC or
SYSEX are left unchanged.
* yabridge runs the plugin's process function in a dedicated
bridged thread. Ardour's process thread is not (it just waits)
* When a plugin calls `restartComponent` from the realtime
thread. yabridge uses a host notification thread to perform
the callback.
Unlike other VST3 implementations that use a notification thread
(eg. JUCE), yabridge blocks and waits for the notification to
complete before the realtime thread can continue.
This leads to a deadlock.
However, we know that yabridge always synchronizes the
callback and concurrent calls are prevented by yabridge's design.
https://github.com/robbert-vdh/yabridge/issues/266
Locations::ripple can never add/remove markers, hence
Locations::changed is not applicable.
That signal is to indicate when more than one location is
added or removed from the location list.
Undo sets the state of ALL Locations, which resulted in
at least two signals for each Location (name changed,
start+end changed), even if there was no change.
Now that Location signal(s) are only emitted when the
drag ended, the list can be kept in sync.
This also adds a further optimization to only update the
list once, even when multiple locations have been changed.
This is in preparation to reduce signals during
Location Drag motion (which operates on a copied
Location, that causes [static] signal emissions,
but the location itself is not in any list).
Section Markers only need to be updated when an actual
section-marker is modified OR flags change.
This also removes duplicate signal subscriptions and
caches sorted Location list when iterating over section markers.
Every call to ::next_section() copies the location list
and sorts all the regions.
If the session has a significant amount of Locations and
Section Marker (#9568 has 300+) sorting them each time
when iterating over sections is significant.
Exporting a dedicated Range should not be constrained by
session markers. This fixes at least 2 issues:
* export could be cut short when using latent plugins
* exporting a range crossing the session end marker was cut short
