Extract USB MIDI message handling into own crate

[kleinesfilmroellchen]

Is your feature request related to a problem? Please describe.

This crate seems to have robust and sophisticated handling for the USB MIDI transport format which wraps actual MIDI messages. However, it’s currently tied to the non-async usb-device stack. Many applications instead want to use the async embassy-usb stack, some boards only have support for USB through that. embassy-usb already has built-in support for setting up USB MIDI devices, but after that, you have to send and receive raw packets.

Describe the solution you'd like

Most of the message module could be provided as a separate crate – from a first look, it seems like it implements independent parsing and serialization functionality that’s separate from USB driver concerns. Then, it would be easy to use that crate for parsing and serializing packets in any embedded application, no matter the USB stack.

Describe alternatives you've considered

I could duplicate all of the code into my own project :)

[sourcebox]

There are already crates that provide these functionality. Examples are midi-convert and wmidi.

You can have a look at the ESP32-S3 for an example how to use them. It should be easy to also connect them to embassy-usb.

[kleinesfilmroellchen]

USB MIDI transport != regular MIDI packet format. See embassy-rs/embassy#4537

[kleinesfilmroellchen]

The correct terminology would be the “USB MIDI Event Packet format”, which is not the MIDI message/packet format used in SMF and by normal operating system transports (and therefore exposed through most crates like midir)

[sourcebox]

What you are referring to is provided by the packet module. This is where the conversion between the regular MIDI messages and the 4-byte USB MIDI packets takes place.

embassy-usb seems to be missing a similar module, so you don't have to deal with the addtional header byte that contains the cable number and the code index number.

[kleinesfilmroellchen]

I mean, I tested sending and receiving (decoding) regular MIDI packets with similar crates and it didn't work. Which packet module (of which crate) do you mean?

[sourcebox]

I'm talking about the packet module of this crate. It contains the UsbMidiEventPacket struct, which represents what you call the "USB MIDI Event Packet format”.

This struct offers methods to get the regular MIDI message payload via payload_bytes() (decoding) and also creating a packet from the regular message via try_from_payload_bytes() encoding.

Therefore, it is the bridge between regular messages and the representation used by USB.

[kleinesfilmroellchen]

Yes, that’s true; still, the marshalling provided by UsbMidiEventPacket is not available anywhere else.

[sourcebox]

It would be best for embassy-usb to also take over this module. A lot of the code in their MIDI class is based on this crate anyway. Maybe you can just open an issue at their repo with a request.

[kleinesfilmroellchen]

This crate is for non-async USB MIDI communications. Embassy only concerns itself with async HALs. For example, smoltcp is a non-async (but agnostic) embedded network stack. embassy-net is an async layer on top of smoltcp. There’s no reason for embassy to take over smoltcp, and the same applies here. If people want to use usb-device, i.e. no async, that should always be possible.

[sourcebox]

I think "take over" is not the right term here. What I meant is embassy-usb could just copy the code from UsbMidiEventPacket into their MIDI class. No transfer of ownership, of course.