We now use a stack allocator when making a copy of current connection state at
the start of the signal emission process, and when collecting results from
signal handlers in the case of a non-void return type.
These changes also include a functionally neutral reworking of how the connection
state copy is made and then used to check that a connection/handler is still
valid mid-emission.
Heap allocation will still happen if a signal has more than (currently) 512
connections. A little experimentation reveals that the maximum number of
connections is typically nroutes+1, so 512 seems like a reasonable choice
for this.
~LocationMarkers() emits CatchDeletion, which calls
Selection::remove(ArdourMarker*) which in turn calls
Editor::marker_selection_changed(), which can cause a
heap-use-after-free.
So we first need to clear the location_markers map,
before deleting the markers.
`gtk_add_grab()` is preferred to `gdk_pointer_grab()`, since
GTK releases the modal grab when a popup window is presented
(f.i. engine disconnected) or other grab breaking events occur.
`gdk_pointer_grab()` can lock the user out, in such events.
Beware of using float as loop/while variable.
When moving the mouse over the tilted port-label area the position p
is set to ` p - (_height - o) * tan (angle ())`.
In optimized (fast math) builds this can be come negative (-0.0).
`::type_channel_to_overall()` then returns a negative channel count,
leading to a crash.
And in some edge-cases (literally moving the mouse to the edge after
resizing the window on Intel Mac), PortMatrixColumnLabels::motion is
called and the port corresponding to the mouse-position is also
computed to be negative.
This fixes "delete" keyboard shortcut when the mouse.
Previously moving the mouse from the box to the selected
processor unset the `current_rfx_box` pointer.
For some reason the action prefix before the slash is
irrelevant. The "RegionFxMenu/delete" action overrides
the earlier registered "ProcessorMenu/delete".
Processor Box context menu called `RegionFxBox::static_delete`.
trim_front_(starting|ending) must be in a class derived from RegionView,
which MidiView is not.
This ensures that Carl's original design for this (with these two methods
called at the start and end of a front-trim drag) is still operational, and we
do not end up with MIDI regions that have a negative start value.
