This is mainly for the benefit of CoreMIDI where MIDI
ports are identified by kMIDIPropertyUniqueID and ALSA
where Ardour uses a unique hash for persistent names.
In livetrax, where RF64 is one of two file formats, people frequently end up
with files named .rf64 that are actually .wav due to the libsndfile
header file downgrade. We want to avoid this, and this seems like
a more common case than people generating actual RF64 files that
(now) will be named .wav
see also 2e23ec4422. This fixes a bug where some ports
remain in used (shared_ptr<Port>) by the RCUManager, even
after the port is removed from the port_map.
This can lead to issues when the port is re-registered later.
Prevent interaction with main window while creating a new
route group. This fixes an edge-case: one can currently
delete route that is going to be part of the new group.
- select a single track
- click and drag the left bar to create a group that includes
the selected track, but don't click "new" yet
- delete the selected track
- click new on the track group window
The group retains a reference to the route.
GCC 14 educates us:
In file included from ../libs/ardour/ardour/io.h:44,
from ../libs/ardour/ardour/route.h:50,
from ../libs/ardour/ardour/session.h:92,
from ../libs/ctrl-interface/midi_surface/midi_surface.cc:30:
../libs/ardour/ardour/port_set.h:92:37: warning: template-id not allowed for constructor in C++20 [-Wtemplate-id-cdtor]
92 | iterator_base<PS,P>(PS& list, DataType type, size_t index)
| ^~
../libs/ardour/ardour/port_set.h:92:37: note: remove the ‘< >’
This prevents a crash on Windows (and optimized mac builds) in
~PortGroup() when a ctrl surface is disabled. Despite the bundle being a
shared_ptr, unloading the ctrl surface module (.dll, dylib), destroys
the shared_ptr<> (or rather the memory are where the shared_ptr is
stored). This later causes a segfault in ~shared_ptr<Bundle>
when the PortGroup is released.
It is also much nicer to have all the ctrl surface grouped into a common
Bundle, rather than having a lot of bundles each with a single unnamed
port.
This works around an issue with some embedded plugin windows not being
properly restored when the window is restored after being minimized. It
also prevents zooming (full-screen) display of dialog windows.
Also recent macOS allows to maximize Windows even if they are not
supposed to be resizable (also causing issues with some plugins).
1. do more to ensure that we do not call MidiSurface::begin_using_device()
multiple times without ::stop_using_device() in between. This reduces the risk
of duplicate signal handler connections being made (it might even eliminate it).
2. Notify all control surfaces when MIDI connectivity is established AND
disestablished. This gives them a chance to update their notion of their
current connection state. This can be important with JACK across zombification,
but also likely across backend stop&start.
These changes currntly only impact classes derived from MidiSurface but
something equivalent is required for all control surfaces
