sending sysex messages hangs the whole midi interconnection

[kshoji]

sending sysex messages hangs the whole midi interconnection

[kshoji]

Thanks for using this library!

The sysex data must be start with 'F0', and end with 'F7'.
for example,
byte[] data = new byte[] {(byte) 0xF0, 0x00, 0x01, 0x0C, 0x01, 0x00, 0x01, (byte) 0xF7};

Please try adding '0xF0' to the head of 'data', and call the sendMidiSystemExclusive() method.

[brudywr]

Frankly sending with sendMidiSystemExclusive makes the app to freeze regardless to passed data. I've managed to get some response from my midi device splitting the original sysex message into 3 pieces and sending 3-byte parts via sendMidiSystemCommonMessage. In that case the app continues working and catches sysex message = '2 0 2 0 -9'. May the usb host driver be the trouble maker? Or some exact version of Android SDK (my android device runs 4.2)

[kshoji]

I tried to debug with the MIDI monitor, and found the data-loss bug in sendMidiSystemExclusive method.
It was fixed(maybe), so please pull and test the code.

With the long message data, sending sysex still fails... (my environment only...?)

[brudywr]

thanks a lot - now it can send sysex messages without freezes. But I found that there's a bug in MidiMessageCallback class - line 78 - while assembling long sysex response it's supposed to concatenate it but now you clears it every for-cycle. I mean:
systemExclusive = new ByteArrayOutputStream();

should be replaced with something like:
if (systemExclusive == null) systemExclusive = new ByteArrayOutputStream();

I checked this fix with my device - it can now get the whole sysex message longer than 3 bytes.

At the moment I finally can receive the preset names from my line 6 pocket pod.

[kshoji]

Thanks. I have confirmed the bug, and fixed.
Now, I'll close this issue.