[alsa-devel] Must MIDI SysEx data contain the start byte 0xf0 and the end byte 0xf7?

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

Clemens,

>Just put the partial chunks into separate events.
>The first must begin with the F0 byte, the last end with F7.
Thank you.
So the F7 continuation event / status byte solely exists in MIDI files,
but not as an intermediate sub-packet starter on the wire.


>For that matter, when the sequencer receives from the hardware a SysEx that
>is too large for its internal buffer, it will split it into pieces.
I already knew about split packets while recording, but I'm surprised that
you talk about recording since I solely mentioned sending via ALSA.


Well, I came across the May 2007 thread "midiOutLongMsg Splitting Sysex Messages??"
https://groups.google.com/forum/?fromgroups=#!topic/mididev/1AKG62CGaP0

D>For example, if midiOutLongMsg is called with the data
D><F0 00 11 22 33 44 55 66 77 F7> and if some driver cannot allocate
D>memory in chunks larger than 8 bytes, the result will be two blocks of
D>data, i.e., <F0 00 11 22 33 44 55 66> and <77 F7>.

A>To send such large [150kB] messages with midiOutLongMsg, the
A>application has to split it up into several buffers.

As you may know, my context is implementing audio in Wine, and I'm precisely
wondering whether Wine's auto-adding F0/F7 around SysEx messages (when missing)
is TRT.  Now I seriously doubt it.

I interpret your sentence A to imply that midiOutLongMsg will not add such
bounds, expecting the app to correctly manage F0/F7 such that precisely, the
app has the freedom to insert as many pauses and split into packets as small
as it wants, i.e. call midiOutLongMSg(lpData=F0 00 11 22 33 44 55 66) and
midiOutLongMsg(77 F7), to keep your 2007 example.

Regards,
	Jörg Höhle