Add a control.ump port property. When true, the port wants UMP and the
mixer will convert to it. When false, the port supports both UMP and
Midi1 and no conversions will happen. When unset, the mixer will always
convert UMP to midi1.
Remove the CONTROL_types property from the filter. This causes problems
because this is the format negotiated with peers, which might not
support the types but can still be linked because the mixer will
convert.
The control.ump port property is supposed to be a temporary fix until we
can negotiate the mixer ports properly with the CONTROL_types.
Remove UMP handling from bluetooth midi, just use the raw Midi1 events
now that the mixer will give those and we are supposed to output our
unconverted format.
Fix midi events in-place in netjack because we can.
Update docs and pw-mididump to note that we are back to midi1 as the
default format.
With this, most of the midi<->UMP conversion should be gone again and we
should be able to avoid conversion problems in ALSA and PipeWire.
Fixes#5183
The current situation is:
- The ALSA sequencer produces and consumes raw UMP only. Legacy input
is converted with the control mixer to UMP.
- All apps and plugins are made to consume and produce UMP.
- The control mixer can convert between UMP and MIDI when required.
- Legacy apps (pw-filter) will still receive MIDI1 events (converted by
the control mixer).
- Helper functions to convert UMP to and from MIDI can be used to ease
implementation when legacy MIDI is still required.
Using UMP natively over raw MIDI has some advantages:
- Transparent support for MIDI2 hardware and the new MIDI2 features
such as increased resolution for events, microtonal support, etc..
- Easy to convert between legacy MIDI and UMP
- Large SysEx can be fragmented properly.
- Fixed size messages are easier to parse and handle.
