Midi receive message chunking

[ghost]

I'm not sure you will or should do anything about this. Note i'm a bit of a newbie to Midi.

I send the following SysEx cmd to a Roland D50 "F0 41 00 14 11 00 00 00 00 03 25 58 F7" ... current patch memory please.

I then receive two messages back, yah perfect!
Cmd Type [0xf0] Data len [266] [F0 41 00 14 12 00 00 .... 68 F7]
Cmd Type [0xf0] Data len [175] [F0 41 00 14 12 00 00 .... 6A F7]

I am debugging on my iPad using MusicIO for Midi connectivity i.e. nice and fast

But with I repeat this using the "Network Session 1" connectivity option i.e. nice and slow I get the following:

RECV [MIKMIDISystemExclusiveCommand] Cmd Type [0xf0] Data len [4] [F0 41 00 F7]
RECV [MIKMIDICommand] Cmd Type [0x14] Data len [3] [14 12 00]
RECV [MIKMIDICommand] Cmd Type [0x00] Data len [3] [00 00 18]
RECV [MIKMIDICommand] Cmd Type [0x37] Data len [3] [37 0B 01]
RECV [MIKMIDICommand] Cmd Type [0x00] Data len [3] [00 01 01]
RECV [MIKMIDICommand] Cmd Type [0x00] Data len [3] [00 00 07]
RECV [MIKMIDICommand] Cmd Type [0x02] Data len [3] [02 00 04]
RECV [MIKMIDICommand] Cmd Type [0x34] Data len [3] [34 00 09]
RECV [MIKMIDICommand] Cmd Type [0x1b] Data len [3] [1B 07 05]
etc etc

Stepping through this in the debugger, Core Midi is returning the data in small chucks rather than the whole message which is what it appears MIKMIDI is expecting. The EOM "F7" you see in the first line is being added by MIKMIDI because it didn't see one for the SysEx start message "F0". Then the following 263 bytes are returned as effectively corrupt MIKMIDICommand 3 byte messages.

I don't have much choice about having to deal with this.

[armadsen]

Thanks for reporting this as well. I'd consider this an MIKMIDI bug, or if not an MIKMIDI bug at the very least a quirk of CoreMIDI that we should improve upon. I think it makes sense for MIKMIDI to buffer and coalesce incoming data if the first byte indicates that it's a SysEx but it doesn't see the EOM terminator in that message.

I'm not in a good position to work on this anytime soon, but a pull request would be most welcome if it's something you're interested in tackling.

[ghost]

I agree. I have sitting here pondering my shitty code used to partly deal with this situation ... its a horror.

The problem is your code is somewhat above my pay grade. But now that I have my "iPhone Simulator" back I'll give it a crack. So sit back and wait for some shitty code coming your way real soon now!

[armadsen]

Hi @ClayApps

Don't worry about your code. I'm happy to take a look at what you come up with and provide feedback and iterate with you.

There's already support for coalescing two message into a single one for 14-bit control change messages. See -commandsByCoalescingCommands: and related code in MIKMIDIInputPort. I think that code could be generalized just a little bit then extended to coalesce multiple incomplete packets that make up a whole SysEx message. Anyway, that's where I'd recommend starting.

Looking forward to seeing what you come up with.

[ghost]

Hi Andrew,

So I've had my hack attack running now for a while now without issue and came across another NOOP bug, well as long as Apple doesn't change the behaviour of core midi, the creatures.

The code as it currently stands assumes a midi packet contains at least one valid midi message. Apple vaguely enforces this by never sending less than 3 bytes packets. In the end it turned out to be pretty easy to generate "slow" midi such that chunking occured.

I tried to create a branch and a pull-request so you can review all this but GitHub Desktop for the Mac keeps generating Authentication Fail errors. Do you have to grant me access? I don't think this should be necessary but again I'm no GitHub master.

Thanks
Clay

[ghost]

Sorted out my Github issue.

All your code assumes it has enough bytes for at least one message, hence the route I took.

If you have some pointers or a preferred approach I'd be happy to have another crack at it.

[armadsen]

Fixed by #200.