* 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.
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).
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
When a user first connected a port to the Timecode master
input and then disconnected a previous port, the Timecode
master assumed it was not connected.
Previously the port-engine was a LIFO. Changes were pushed back
and then popped-back. This causes issues when re-connecting
Transport Masters.
The GUI does the following when changing connections:
1. disconnect all
2. connect to new port
which lead to TransportMaster::connection_handler being called
in reverse order: connect, disconnect, and the transport
master was assumed to not be connected.
--
Now connections queue is a FIFO and code was consolidated.
(Note, we cannot use a std::deque because it does not support
memory pre-allocation with ::reserve)
The former was incorrectly implemented, and the latter has already been tested more
in real life.
We should likely remove ::remove_time also and use shift() there too, but that
requires testing negative shifts more broadly.
Ardour accidentally removed nascent source-files during cleanup.
This can lead to missing files when recording directly after a
cleanup.
This also ensures that there are no duplicates in the
dead-sources (file sources unused in the current snapshot) list.
parens were in the wrong place - we need to add the ::magnitude() of
the tick-based duration AFTER conversion of audio-time position to beats, not
before.
we control the CC number sent by launchpad faders, and 0x20 is too large
because it causes the faders to overlap with some of the CC values
sent by RHS pads. Parametize the first fader and use it everywhere
This was causing issues with cues when clips were set to gate triggering. A pad
long press was causing the clip to release. Additionally, remove an extra timer
that was being set.
This is not complete, because the symol names are identical, and there's no way (yet)
to ensure which versions Ardour will use if both are dynamically loaded.
This can happen with snapshots or after save-as with
.ardour session files having different "Names" in the same path.
Or simply by saving a session on macOS in /tmp (which is really
/private/tmp).
This likely needs checking for all surfaces that inherit from MidiSurface. It is clearly
the correct thing to have in the code, but existing behavior might be predicated on
the former incorrect connection
