Truncate MIDI SysEx messages after termination byte

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

Although I wouldn't mind inclusion of Christian's F0/F7 patch in upcoming Wine
(barring decent formatting), I beg and urge Johannes Kroll to nevertheless submit
a bug report about F0/F7 handling *and* provide a log of all SysEx messages sent
submitted by the app to Wine.

There's code to dump the data contents in another library that he could copy
to winealsa to produce the SysEx dump:
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winmm/winmm.c#l1066

What becomes clear from below documents is that at least our mciseq .mid file parser
does not handle SysEx continuations aka. divided SysEx,
nor encapsulated SysEx aka. encapsulated events at all.
https://www.allegro.cc/forums/thread/607445
http://www.sonicspot.com/guide/midifiles.html

You could argue that .mid file parsing has no influence on winealsa.
However, as midiOutLongMsg and midiOutShortMsg are the only low-level API
calls available, the question is whether native is able to send such partial
SysEx to external HW devices.  Obviously, automatically padding with F0/F7
(which winealsa would like to do and wineoss does) prevents that.

Should one expect the native low-level drivers to split large SysEx and insert
pauses during transmission, or should the apps be able to split and send themselves?
The existence of SysEx continuations in MIDI files causes me to believe that the
same splitting should be possible on the output side, under control of the app.

It's also unclear how the backends would react to missing F0/F7 delimiters.
ALSA says: "the sysex data must contain the start byte 0xf0 and the end byte 0xf7."
http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#ga104862c436dcc8f23892be44f50bc90f

Regards,
	Jörg Höhle