The instrument dropdown can be very wide (depending on available synths)
and combined with other dropdowns and the copy-checkbox in a single row,
the min. width was well above 1400px.
In order to choose which port name to display (if any) in the button,
MixerStrip::update_io_button() first chose a primary type for the input
or output. It was AUDIO in all cases, except if the route was a
MidiTrack where the primary type was MIDI.
In the latter case, it enabled the following code of update_io_button()
to show the MIDI sources feeding the MidiTrack rather than showing an
unhelpful dash.
But this simple heuristic has several shortcommings:
- Going further, tracks and busses will probably loose strong types so
the approach is not future-proof;
- It doesn't take midi busses into account, yet there is no reason for
them to be handled differently than midi tracks;
- It falls short when the midi track contains a synthesiser and is
meant to output audio.
Improve the heuristics by choosing the data type as follows:
A) If there are connected audio ports, consider audio as primary type.
B) Else, if there are connected midi ports, consider midi as primary type.
C) If there are audio ports, consider audio as primary type.
D) Else, if there are midi ports, consider midi as primary type.
These new heuristics give the same results for audio tracks and busses
(whose audio inputs have not been removed), and the same result for the
input of midi tracks (again, provided the inputs have not been tampered
with). It improves the situation for inputs of midi busses, and output
of midi tracks and busses, especially when synthesisers are in use.
- cleanup audio-locked meter removal code
- recompute and warn if map is left unsolved due to adding a metric
- handle corner case wrt overlapping audio-locked musical sections.
