MIDI monitor only accepted midi data and output that same data. That was
logical for a MIDI plugin, but a consequence is that automatic pin
configuration makes MIDI monitors opaque to audio data, which means
drag'n'dropping a MIDI monitor for debugging purposes can suddenly cut
audio, or even change the channel count if strict I/O is enabled.
Improve the MIDI monitor so that it passes through all incoming data
unchanged.
Ardour takes the closest pin/port match yet still offers a plugin with
variable i/o access to all port-buffers.
the "reported" (user visible) pin-count now defaults to the actual
selected configuration (precise) and lua_dsp_configure() can
override it.
This plugin lets through all incoming MIDI events, and also shows the
latest ones in a human-readable format directly on the mixer strip. The
user can choose the font size and the number of recent events displayed,
as well as whether to print values in decimal or hexadecimal, and
whether to print system events.
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.
