This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
Extra "other" ("External") ports were already being grouped by their
common prefix into bundles to better display ports coming from different
jack clients. This commit factors out that logic into a separate method
to also apply this logic to extra "system" ("Hardware") ports. This way
hardware ports from different devices/clients (for example when using
pipewire as jack backend) are grouped by device rather than all being
listed as one bundle.
Program-name is not required to indicate "Tracks", "Busses", etc
Those are always by provided by PROGRAM_NAME.
"Other" really indicates external JACK (or Pipewire) applications.
Here "External" is a better label.
"Misc" can potentially be interpreted ambiguously, hence keeping
PROGRAM_NAME is useful.
This should fix a long-standing issue with interleaved display
of clients since jack_get_ports() does not return a well defined order.
(Internal backends based on Ardour::PortEngine keep ports sorted)
PortGroupList::gather() first adds UserBundle ports to
`system->add_bundle (*i, allow_dups);`
That can include ports that are already associated with the
current bundle. The port in this case has the Bundle's name.
Those ports are later removed in BundleEditorMatrix::setup_ports
`_ports[OTHER].remove_bundle (_bundle);`
However we do need to show physical ports by their name, even
if they're identical to the already associated bundle to allow
disassociating them.
Copyright-holder and year information is extracted from git log.
git history begins in 2005. So (C) from 1998..2005 is lost. Also some
(C) assignment of commits where the committer didn't use --author.
PortMatrix is able to filter out ports that have an unwanted datatype, but
if a Bundle is added that has no port at all with a wanted datatype then
it is not weeded out correctly (and even if it were, there's no chance
that it will legitimately appear in the UI). Don't add that kind of
Bundle in the first place.
maybe this should be an option? So far it’s
the matrix only.. gotta start somewhere.
PS. No, this is not a new feature. Ardour not doing this
is a major bug that severely reduces usability:
system:midi_capture_47 WTF? ;-)
This makes the responsibilities and ownership of non-Route related MIDI ports
more clear, and removes a few wierd bits of code. It also ensures that open/close/open
on the same session will retain connections for those MIDI ports
Separate port-bundles for each jack client in the connection manager.
Previously, apps were only listed as separate bundles if the
ports were gathered at different times. ie one app shows up after
the other (and if no complete re-scan was triggered)
Fixes issue reported by Fons Adriaensen.
Paul Davis
Krzysztof Gajdemski
Marijn Kruisselbrink
Todd Naugle
Johannes Mueller
Thomas Brand
Julien "_FrnchFrgg_" RIVAUD
nick_m