Fix a bug in writing SysEx messages.

[mzero]

At the start of a new USB packet (4 bytes), while in the middle of a SysEx, the code mistakenly
set the buffer length to 4, not the target length. As a consequence, the 3rd and 4th bytes from
the last packet were included, after every byte of the SysEx after the first packet of three.

The fix is simple, as it was just a typo, as can bee seen from the other branches in the same
section of if/else statements: At the start of a new packet, the code should set up the target
length... the buffer length should be left at 2 (as set on line 180).

Describe the PR
SysEx messages are garbled by the current code.
See issue #511 for full details.

This fixes #511

[hathach]

Thank you very much for the PR, give me a few days to ask for review help. Hi @kaysievers do you have a minute to review the changes, It is probably simple enough to you but is out of my expertise.

[hathach]

Thank you for PR, I was bit busy lately and didn't test it out, but it looks great to be merged.

[henrix]

I'm still having issues when receiving more than 3 bytes at once with the MIDI class.
I'm using a STM32F746-Discovery board.

Example code for loopback:

uint32_t num_bytes = 0;
uint8_t buf[64] = {0};
if ((num_bytes = tud_midi_available())){
    tud_midi_read(buf, num_bytes);
    tud_midi_write(0, buf, num_bytes);
}

When sending a SysEx message from host with 4 bytes (i.e. {0xF0, 0x0, 0x1, 0xF7}), I receive:
{240, 0, 1, 0, 0, 0, 0, 0, 247}

Sending SysEx messages with more than 3 bytes works fine though.
Any idea, why this is happening?

[hathach]

@henrix this PR is merged, if you still have issue with it, please open the new issue with detail on your set-up and how to reproduce the issue.