MIDI 2 support in Ardour

Getting Stuff Done How do I .... ?
#1

Hi @x42 @paul!
I’m now working on PipeWire support and found out that PipeWire actively forces to use MIDI 2 protocol and deprecated MIDI 1 protocol.
I just want to ask the state of Ardour related to MIDI 2.0 support. Do you have some LV2 extension files provided for that and/or any examples of serializing/deserializing MIDI 2 messages into LV2 Atoms?

#2

Neither of us is working on LV2. That is an independent standard. LV2 MIDI 2.0 support would be something to ask the LV2 maintainer @drobilla.

In any case pipewire’s JACK implementation supports MIDI 1 compatibility as does ALSA. So far ardour does not support MIDI 2.0 to begin with.

#3

I doubt it is even possible to deprecate MIDI 1 in favor of MIDI 2, as MIDI 2 is built over the original MIDI and thus is backwards-compatible.

1 Like
#4

Maybe I was incorrect in definitions but PipeWire forces us to use MIDI2 ports and deprecates MIDI1 ports. That’s why modern applications need to incapsulate MIDI1 messages into MIDI2 packets. From my side I decided that if I start to deal with MIDI 2, then I probably need to add the support of MIDI 2 for all plugin formats supported by LSP plugins. That’s why I’m asking about does Ardour already support MIDI 2 or not because there is still no specification of MIDI2 messages provided by LV2 and maybe there are some custom LV2 extensions used by Adrour.

1 Like
#5

I wonder if there is a single application on Linux that does this at present, so I am not sure what you mean by “modern applications”.

#6

I can’t find anything on the PW MIDI page suggesting that MIDI1 is deprecated.
https://docs.pipewire.org/page_midi.html
It talks about (for SPA) : “As of 1.7 the prefered format is Midi1 again because most devices and applications are still Midi1” and for JACK “Normally, all MIDI and UMP input messages are converted to MIDI1 jack events” and “For output ports, the JACK events are assumed to be MIDI1”

#7

In <spa/control/control.h> the enumeration constant SPA_CONTROL_Midi is marked as deprecated:

enum spa_control_type {
	SPA_CONTROL_Invalid,
	SPA_CONTROL_Properties,		/**< SPA_TYPE_OBJECT_Props */
	SPA_CONTROL_Midi,		/**< spa_pod_bytes with raw midi data (deprecated, use SPA_CONTROL_UMP) */
	SPA_CONTROL_OSC,		/**< spa_pod_bytes with an OSC packet */
	SPA_CONTROL_UMP,		/**< spa_pod_bytes with raw UMP (universal MIDI packet)
					  *  data. The UMP 32 bit words are stored in native endian
					  *  format. */

	_SPA_CONTROL_LAST,		/**< not part of ABI */
};
#8

I’m guessing the idea was for a transparent conversion from _UMP to _Midi for clients that needed the latter, according to “As of 1.4, SPA_CONTROL_UMP (Universal Midi Packet) is the prefered format for the MIDI 1.0 and 2.0 messages in the spa_pod_sequence. Conversion to SPA_CONTROL_Midi is performed for legacy applications.”

But that seems to be reverted in the upcoming PW 1.7 :
“As of 1.7 the prefered format is Midi1 again because most devices and
applications are still Midi1 and conversions between Midi1 and UMP are not
completely transparent in ALSA and PipeWire”

The above was added in commit fd867cf655, with the message
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

#9

Yep, always keep in mind IP-V5.9979987 was not achieved in one life :wink:

#10

OK, nice to see people who are better aware about things going around the PipeWire. Seems that I still can introduce MIDI1 ports for it and add possible support of MIDI2 in the future.