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