Steve,
thank you very much for your time and effort. Let me add some thoughts to it.
2014/1/14 steve_the_composer <smw-mail@...>
I suspect it's just send raw. As you can see here: http://www.ccarh.org/courses/253/handout/smf/ - the MIDI file starts with a header chunk - "the literal string MThd, or in hexadecimal notation: 0x4d546864. These four characters at the start of the MIDI file indicate that this is a MIDI file."
In your case, the dump starts with "F0 7E 00 07 02 00 7F", which is the E-mu SysEx header, then there's 00, and... 4D 54 68 64! The dump ends with F7, which is the End Of SysEx byte. All chunks - except for the one have 137 bytes, 7 of which are the header, one is the stop byte, and then it's 00 (coming after 7F), which may be the control sum (not likely, as it should be coming AFTER the message). Last chunk specifies 64, which means there are only 100 bytes of content, while the block is 110 bytes long. This makes everything correct - 137 is 127 (7F) + 10, so we know the size of the overhead. As stated, seven initial bytes are header, last byte F7 is stop byte, most likely one byte for control sum - which leaves us with the secret of the initial byte.
Any clue?
Initial block, quoted for convenience.
0000283A 10 -- F0 Buffer: 137 Bytes System Exclusive
Cheers,
Bruno
thank you very much for your time and effort. Let me add some thoughts to it.
2014/1/14 steve_the_composer <smw-mail@...>
More complicated would be assembling the song as sysex into a *.mid file and converting a *.mid file to sysex format.
I suspect it's just send raw. As you can see here: http://www.ccarh.org/courses/253/handout/smf/ - the MIDI file starts with a header chunk - "the literal string MThd, or in hexadecimal notation: 0x4d546864. These four characters at the start of the MIDI file indicate that this is a MIDI file."
In your case, the dump starts with "F0 7E 00 07 02 00 7F", which is the E-mu SysEx header, then there's 00, and... 4D 54 68 64! The dump ends with F7, which is the End Of SysEx byte. All chunks - except for the one have 137 bytes, 7 of which are the header, one is the stop byte, and then it's 00 (coming after 7F), which may be the control sum (not likely, as it should be coming AFTER the message). Last chunk specifies 64, which means there are only 100 bytes of content, while the block is 110 bytes long. This makes everything correct - 137 is 127 (7F) + 10, so we know the size of the overhead. As stated, seven initial bytes are header, last byte F7 is stop byte, most likely one byte for control sum - which leaves us with the secret of the initial byte.
Any clue?
Initial block, quoted for convenience.
0000283A 10 -- F0 Buffer: 137 Bytes System Exclusive
SYSX: F0 7E 00 07 02 00 7F 00 4D 54 68 64 00 00 00 01 06 00
SYSX: 01 00 10 01 00 00 4D 54 72 6B 00 00 00 10 75 00 70 47
SYSX: 18 0F 7F 00 55 01 20 01 04 19 00 00 02 04 50 00 03 04
SYSX: 00 00 00 04 04 00 00 05 04 00 03 00 06 04 04 00 07 00
SYSX: 04 03 00 08 04 19 00 00 09 04 20 00 0A 04 00 00 00 0B
SYSX: 04 59 00 0C 04 00 00 00 0D 04 21 00 0E 00 04 02 00 0F
SYSX: 04 02 00 05 10 04 00 00 77 00 7F 00 03 0A 53 74 61 72
SYSX: 53 01 65 65 6B 65 72 00 7F 35 F7
Cheers,
Bruno