my MidiInputCallback is getting 2 1/2 packets of a sysex chunk instead of the full block. On the windows version I’m getting the full sysex packet. I’m not sure what’s going on. Is this a Core Midi issue?
just verified this using Midi Manager. The sysex data I’m receiving is one message, but Juce seems to split it into 2.
hrmm, ok, looks like midiInputProc is getting it broken up into 2 chunks already.
I’m guessing I’ll have to wait until I receive a F7 before I can assume the midi packet complete?
that’s annoying - it’s probably being split up by your midi card driver, as I’ve not seen it happen like that myself.
Do both packets arrive in the midiInputProc as part of the same packet list? If so, we could patch the logic in there to stitch them back together before sending the message to the application…
unfortunately no, it’s 2 seperate packets.
I just made a method that compiles sysex messages by checking for F0 and F7.
Might be because this is a USB based Midi Device.
I am facing the same problem…
I’m trying to receive device inquiry messages. Here are two results from different ports… (dump printed by SampleTools in the Apple’s example codes)
KORG microKONTROL (External MIDI IN) / EDIROL UM-1
F0 7E 00
06 02 42
58 00 08
00 06 01
01 00 F7
CoreMIDI sends splitted 5 messages.
KORG microKONTROL(Interenal) / MOTU 828mkII
F0 7E 00 06 02 42 58 00 08 00 06 01 01 00 F7
CoreMIDI sends 1 message.
*Note that microKONTROL is driven by Apple’s class compliant driver.
The speed of USB transmitting/receiving is happen each 1ms. This is the minimum duration of USB spec. And real MIDI messages take 1ms to send/receive 3bytes. I guess if the driver receive a packet from USB-MIDI device, the driver call the CoreMIDI function soon. But this behavior probably depends on the driver. I guess MOTU 828mkII driver waits till the 0xf7 is coming. KORG microKONTROL, it has two different ports, one is external (slow) and the other is internal (fast), so the result is different by port.
hmm… so I have to wait till 0xf7 is coming.
However there is a good point, we can show the progress bar while receiving a long SysEx data. But if we have to deal with a lot of ports, it is complicated…
Regarding this results, MidiInput::isSysEx() method does not work properly if the messages are divided.