System Real-time messages with Arcore

[fvsr]

I used the exemples and they work fine, but I notice in the examples that MIDIEvent is 4 number array.
Is there a way to receive one byte Midi messages (system real-time messages), or two bytes Midi messages (program change, channel pressure) with Arcore? Can you give some examples?

[rkistner]

I haven't tried this myself yet, but it should be simple.

According to the spec (http://www.usb.org/developers/docs/devclass_docs/midi10.pdf, page 16 and the examples on page 17), a message in MIDI-USB is always 4 bytes long. However, that does not mean all the bytes are used - the last ones may just be padding.

If you already have a source sending you the data, I recommend just trying to read it and see what you get.

[FrankBrook]

If I may, I'd like to bring some greater clarity to bridge the gap between tfsvr's question and rkistner's answer.

As fvsr says, MIDI messages can indeed be 1 or 2 bytes. As an extreme example in the opposite direction, my old Korg M1 can be returned to "factory condition" by transmitting a single system exclusive message of 49791 bytes.

Looking more closely at page 16 of the midi10.pdf document I see a truism that "Most typical parsed MIDI events are two or three bytes in length." which is arguably incorrect because most MIDI devices spent most of their time not being used and are therefore more likely to be sending single-byte Active Sensing bytes. I could also get argumentative over Note 1 that follows table 4-1 as well. Although these points are not the issue here, they do give an impression that the transport of MIDI data over USB has not been defined by people who are particularly expert in the field of MIDI.

Back to the issue at hand. Look at figure 8 and then table 4-1. The figure explains why it is a 4 byte event packet and the table shows that when CIN=0x5 the event packet relates to single byte MIDI message and when CIN=0x02 it relates to two byte MIDI messages. So, the CIN value tells you how many of the remaining three bytes are meaningful and by implication how many are undefined chaff.

Something else worthy of note is how SysEx messages require several kinds of packet to transfer a bulk dump. And notice also CIN=0xF which can circumvent the parsing of MIDI data, thereby leaving the parsing of MIDI data to your own application code and/or potentially reduce latency issues.

As an aside, I'm now beginning to understand why my 30 year old Serial-MIDI adapter works faultlessly on an ancient computer whereas the last two USB-MIDI interfaces I recently bought don't work reliably with SysEx bulk dumps. It's down to the USB overheads.

[rkistner]

@FrankBrook Thanks for the explanation. The CIN=0xF is an interesting case - it seems like each byte in the MIDI stream is packaged in a separate 4-byte MIDI-USB event.

I would expect that with fast enough USB transfer speeds, the USB overhead could be negligible. However, it's quite possible that USB-MIDI adapter can't actually achieve the high transfer speeds (and it may also be the case with Arduino, I haven't actually tested at what speed we can transfer data).