A system exclusive message (sysex) is MIDI's way of allowing a manufacturer to send any kind of data to a device. Since there are a zillion different MIDI machines out there, it is impossible for the MIDI standard to cover every possible use of MIDI that anyone might come up with. Since sysex is specifically meant for transmission of vendor-specific information to hardware, there cannot be a standard, as any standard would defeat the purpose. And then... some synths have maybe 50 parameters, while others may have 500, and maybe some future machine has 10000 parameters -- and the sysex protocol has to allow for all these old, current and future possibilities. No standard could ever hope to achieve that. It is very important to understand this point: there is NO such thing as a sysex standard and there never will be.
So basically a Sysex message is a chunk of private lingo in the midst of a standardized (midi) language.
So how does such a sysex message look? Every sysex message starts with a status byte that has value (hex) F0, meaning "start of exclusive". (If you're not comfortable reading hexadecimal numbers, you might want to read my article on hexadecimal notation first, as dealing with hex is almost unavoidable when doing sysex -- and at least it makes life much more comfortable than the normal decimal notation.) Then after the F0 comes a series of data bytes, and the message ends with an end-of-exclusive status byte, F7. So we get:
F0 <data byte> <data byte> .... F7
The number of data bytes is, of course, machine dependent. Data bytes can contain any kind of information: from a simple parameter change to a complete dump of the entire memory of your synth.
Normally the first data byte is a manufacturer-ID which indicates the "brand" of the machine, like Moog, Korg, Roland, or whatever. The Usenet MIDI Primer has a section with a few manufacturer-IDs. Whatever follows next is totally manufacturer-dependent, but it's quite common to find a machinetype-specifier and a midichannel-specifier right after the first data byte.
The machinetype-specifier tells you that this is synth XY12, and not drummachine PQ34, and thus allows you to distinguish between various machines from the same manufacturer. The midichannel specifier tells you that this message is intended for a machine switched to e.g. channel 12, and thus similar machines on other channels should ignore this message. This way you can have a bunch of identical machines hooked up through MIDI, and still address them separately through their individual channels.
Example: the Korg M1 synthesizer sysex format is: F0 42 3n 19 ss xx xx ... F7. F0 is "start of exclusive". Then "42" means "I'm a machine from Korg". "3n" indicates the channel of the machine: 'n' can be anything from 0 - F (hex) (0 - 15 decimal) and thus can represent any from 16 midichannels. The '19' byte says that this is an M1 talking. The 'ss' byte tells which function is to be performed (parameter change, bulk dump, et cetera). Then follows the data ('xx'), closed by an end-of-exclusive byte F7.
Example: The Yamaha TX16W sampler sysex format is (simplified for educational purposes): F0 43 sn rr xx xx ... F7. F0 is again start of exclusive. 43 = Yamaha. In the third byte, the 'n' again is the midi channel, and the 's' depends on the function-group being called upon. Finally 'rr' specifies the function being called. 'xx - F7' are as before.
Example: the DigiTech DSP256 effects processor does it like this: F0 00 00 10 0n 06 pp xx xx ... F7. Here "00 00 10" is the DigiTech ID (3 bytes instead of 1!), "0n" is once more the midi channel, "06" specifies a DSP256 machine, "pp" is the function that should be performed. And it ends again with a bunch of data bytes (xx) and an end-of-exclusive.
You see that, despite the fact that these are 3 very different machines from different manufacturers, there are large similarities between the respective sysex implementations. So I would guess that there's a reasonable chance that your synth, drummachine, sampler or whatever gear you use follows a somewhat similar format. Study the sysex implementation chart in your machine's manual carefully to detect similarities and differences.
What follows might not apply to your machine at all, but is nevertheless not uncommon.
Often after all the introductory stuff is sent (see examples above) a sysex message will contain a "function selector byte". This tells you that the next data bytes are supposed to be an "all program dump", or a "parameter change", or a "reply to a status request". In the case of a parameter change, it's not uncommon to find two more 'sections' following the function-byte: a section that specifies which parameter should be changed, and a section that tells the value of the parameter.
So you could have something like "here's a parameter change", "the parameter to change is Filter Cutoff", "set it to 56 please". The (byte) size of the respective sections is of course machine dependent. Heck, your machine might have a different implementation altogether and not know any "function specifier bytes" at all. What I describe here is merely based on my own experience with sysex and things I think are rather common.
Since most sysex implementation charts are almost completely unintelligible (as if on purpose...), you might run into things like this: in one table you find "Filter Cutoff: parameter #60". In another table you might find "par. 3C: range 00-63". And in yet another table you find "sysex format: F0 11 22 0n pp pp vv vv F7" with a footnote telling that 'pp pp' is parameter LSB/MSB and 'vv vv' is value LSB/MSB. And poor you wants to change the Filter Cutoff to 14...
OK, so Filter Cutoff is parameter 60. From the chart you've concluded that these numbers are in decimal (since after 9 came 10 instead of A). But 60-decimal = 3C-hex (remember: 3*16 + 12 = 60,or take a look at the conversion table). Ah, so the "par. 3C" is also about Filter Cutoff -- it's just that this time they've decided to number things in hex instead of decimal. Now the second table says the range is 00-63. Since "3C' clearly is hex, probably 00-63 is hex too. Makes sense, since 63-hex = 99-dec and you know that indeed the parameter has a 0-99 range on the front panel display. Fine, we're getting somewhere. All that's left is to figure out the sysex string to send. The "F0 11 22 0n" part is easy: 'n' will be the midichannel of your device (numbering 0-15 instead of 1-16!), so you put the right number in. Then "pp pp" is parameter LSB/MSB. So here we should put the '3C', in a 2-byte format, with the Least Significant Byte first. Since 3C easily fits in one byte, the MSB will be all 0's, and we get "3C 00". A similar procedure holds for the value. You need a value=14 message. Now 14-dec is 0E in hex. With two bytes for the value, you would get "00 0E". Oh, but wait, we have LSB-MSB ordering, so that's "0E 00" instead. Supposing the midi channel is set to 3, the entire message would now become
"F0 11 22 02 (!) 3C 00 0E 00 F7".
Wow, we actually got it working!
As I said earlier: your machine might work very differently, but I know that quite a few machines out there follow a similar format. Carefully study the sysex implementation chart and don't give up too soon. It may seem daunting at first, but the rewards are big once you manage to make sense out of all those bits and bytes.
Since MIDI only allows 7-bit data bytes, you should take care not to use any 8-bit bytes. Sending a parameter change with value=128 would (in a MSB-LSB system) require you to send "01 00" instead of "00 80". For a more detailed description of this subject, please read my article "binary, hexadecimal and byte order".
(c) H.J. Veenstra 2001.