Does rtmidi support midi 2.0? about rtmidi HOT 16 OPEN

from rtmidi.

For anyone interested I've started trying to migrate step by step https://github.com/jcelerier/libremidi , my fork (pretty much a rewrite by now) of rtmidi to midi 2, first by providing the ability to midi_in and midi_out to speak UMP for when someone simply wants higher resolution CCs aha ; the next step will be to work on an interface that will model the "endpoint" concept of MIDI 2 ; any input and feedback is very welcome!

from rtmidi.

The current API transfers a packeted byte stream. This means that you can send an UMP to RtMidi. It will be handed over to Windows or MacOS unchanged. This should work with the WinMM backend as it has exclusive access to the MIDI devices. The corresponding feature (raw MIDI device access) is not used with ALSA (Linux). Instead the Linux implementation uses the ALSA sequencer, which tries to keep MIDI messages intact even when several streams are merged. If ALSA mixes UMP and MIDI1.0 messages it is very likely to confuse the receiving device. Also other backends like macOS or JACK allow to merge MIDI streams, so they have the same problem. That's why RtMidi has to wait for the backends to support MIDI 2.0.

from rtmidi.

People interested in this subject should check out the MIDI 2.0 specification updates announced in Nov 2022.

https://www.midi.org/midi-articles/details-about-midi-2-0-midi-ci-profiles-and-property-exchange

There are some serious implications as to how operating systems will be managing MIDI 2.0 devices, specifically with regards to "Endpoints" and "Function Blocks".

Currently with USB MIDI 1.0, a device may connect with several input and output ports, and all the operating system does is report these ports and names. With USB MIDI 2.0, there is an "endpoint" with input and output ports, and function blocks that describe the bidirectional nature and uses for these ports.

from rtmidi.

Thanks, this is all helpful! I need to do some further learning to understand what to do with this.

from rtmidi.

FYI - microsoft just opened up the repository for their new open source Windows MIDI Services. In addition to MIDI 2.0 support and backwards compatibility with MIDI 1.0, there will also be support for virtual midi ports and multi-client access.

from rtmidi.

from rtmidi.

What's the reasoning for a MIDI-2.0 protocol when virtually everyone has moved or is moving to OSC as the replacement for MIDI?

from rtmidi.

from rtmidi.

TY for the detailed explanation, Eric.
I'd like to continue this conversation if you are willing. This subject is quite interesting to me, but Instead of clogging up GitHub I could send an email, let me know if that would be ok.

from rtmidi.

Sure thing

eric atsymbol keithmcmillen dot com

from rtmidi.

regarding "Microsoft, Google, Apple, and the lead maintainer of ALSA have been meeting once or twice a month as midi.org members to develop a whitepaper on guidelines for developers and their midi 2.0 APIs. The operating systems are going to be managing some/most of the “endpoints” and reporting metadata within the api. Before you go too far down the road of writing an endpoint interface (or even handling UMP) you should take a look at the current implementations. Microsoft is last to have official support, but just opened up their repos for developers. Andrew Mee from Yamaha also has a library out there, but the public version is way behind the fork that the midi.org is currently using in development (the fork is not public yet because it implements spec updates that haven't been released)"

my implementation is based on the current APIs provided by macOS and Linux for MIDI 2 (windows one still not final as we know, looked at it a few times) which provide access to UMP just like MIDI 1 APIs provide MIDI 1 bytestreams.
It's imho much more convenient to use than MIDI 1, the only sad thing is that it requires very recent OS kernels, macOS 11+ and linux 6.5+

I really wouldn't want to go through the "ump-over-midi1-sysex" route when OS APIs provide clean and beautiful APIs that return uint32's:

• https://github.com/alsa-project/alsa-lib/blob/master/include/ump.h
• https://developer.apple.com/documentation/coremidi/midieventpacket?language=objc

from rtmidi.

UMP also provides better methods for sysex (8bit data!).

A unified cross platform library that reports back if the OS supports MIDI 2.0 is the goal. Translating MIDI 1.0 to UMP is pretty much baked into UMP in any case.

from rtmidi.

For OS support it's not too simple : from what I can see in macOS it has to be a compile-time choice:

• either you set -mmacosx-min-required 11 and you can call the MIDI 2 functions, but the library won't run on <= 10.15
• or you set -mmacosx-min-required below but then you cannot call the MIDI 2 functions

if anyone knows how to do a run-time check instead I'll gladly implement it but I'm not sure this is possible as it stands, short of having per-backend .dylibs: dlopen will fail for the ones which are too recent for the OS version.

For Linux it's already done: I load all the ALSA symbols through dlopen / dlsym and check for the availability of the UMP ones. If they are not available the library on the user's system, then the UMP backends simply will not be available:

• https://github.com/celtera/libremidi/blob/master/include/libremidi/backends/alsa_seq_ump.hpp#L59
• https://github.com/celtera/libremidi/blob/master/include/libremidi/backends/linux/alsa.hpp for the libasound dylib loading

from rtmidi.

And over time for sure I think it'd make sense to just drop the MIDI 1 back-ends and just focus on UMP, as the OS will translate MIDI 1 -> UMP in all cases and UMP is just so much easier to work with.

from rtmidi.

from rtmidi.