This tutorial comes with an environment that illustrates some of the things described here. You need Stuffit Expander to unpack it. Stuffit Expander is free, for Mac and PC, and can be downloaded here.
Download the environment "sfader.lso".
Usually the worst way to handle system exclusive in Logic Audio (LA, or Logic for short) is to use sysex faders. However, since it is possible and has some uses, it deserves separate treatment.
We'll tackle the relatively simple problem of sending a message that looks like this:
F0 18 08 00 03 XX 17 F7
where XX is the value as it should be determined by the fader.
Aside: if you have trouble reading hexadecimal numbers, first read the article that deals with that. If you have trouble figuring out sysex in general (because your synth's sysex implementation chart is, uhh..., not too clear, read the general sysex article first.
In LA open an environment window, and go to the "Click and Ports" layer -- the one containing the Physical Input object and the "to Sequencer" object (or whatever it's called in your version)
Now first you have to create a fader, obviously. In the window's "new" menu, pick a "Vertical 4" fader and enlarge it a bit. Select the fader and in the parameter box (left side of window) change it's "out" definition to "Sysex...". Now an empty window will automatically open that looks suspiciously like an event list. Well, it is.
As an exercise, first close this window. Now double-click the word "Sysex..." in the parameter box: the window opens again. With the window open, command-click (control on PC?) the green sysex button. A new sysex message will be inserted which looks like this:
Sysex 4 0 0 0 0 0 0 VAL <EOX>
The word "SysEx" actually is the "start of exclusive" byte F0. Likewise the EOX at the end is the "end of exclusive" byte F7. The VAL-thing also is a byte (we'll get to that). So, counting all bytes the empty message has 10 bytes, whereas we only need 8. Click on the "<" sign left of the EOX twice to get rid of 2 bytes. You now have
Sysex 4 0 0 0 0 0 <EOX>
In the window's View menu, select "Sysex in Hex Format" first. Then change the first few bytes by click-dragging until the message looks like
$F0 $18 $08 $00 $03 $00 VAL <$F7>
Wow, now there's a problem: you want to change the last data byte to $17, but you can't since there's this VAL thing in the way. The VAL byte is the byte that will be affected by the slider, but clearly it's in the wrong place. At the bottom left of the window you'll see a "Position" popup. Pick "Last - 1" from this popup -- since our "value to be affected" is in the one but last position of the data bytes (remember: F7 is not a data byte so doesn't count). The end of the message will now show "VAL 00 F7" and you can adjust the last 00 to become 17 instead. We now have
F0 18 08 00 03 VAL 00 F7
(leaving the $'s out for readability). If the message is selected, you'll see the above. Now click above the message on the "Start of List" line to deselect it, and you'll see it change to
F0 18 08 00 03 00 17 F7
I.e. the VAL has disappeared and changed to 00. This means that the slider will NO LONGER affect this message! This is of crucial importance and perhaps one of the biggest causes for problems with sysex faders. If you would now close the window, then dragging the fader would merely send out the same (identical) message over and over again. Therefore you have to select the message before closing the window. OK, after this warning, re-select the message so the VAL re-appears.
Now with the message still selected close the window. You're done: dragging the fader from 0 - 127 should send out sysex messages from
F0 18 08 00 03 00 00 F7
to
F0 18 08 00 03 7F 00 F7
For many machines, you should keep the checksum popup to "off", except when your manual explicitly tells you that sysex messages should be closed with a checksum message. Consult your synth's manual and the LA manual for details.
The idea is that you could include e.g. 3 messages in the fader, and have only the second and third be affected by dragging, while the first remains constant (achieved by selecting the 2nd and 3rd, while deselecting the 1st, before closing the window).
This gives a whole bunch of new applications for the sysex fader. You could e.g. insert 16 "volume = 127" messages on 16 midi channels in the fader. Deselect them all, and close the window. Now any fader movement will send out 16 "volume = max" messages, instantly resetting all your gear's volume to maximum (in this case it would be useful that change the fader's appearance to a button type, and change the range from 0-127 to 0-0). No sysex is used here, despite the fact that it's a sysex fader :-). Alternatively you could instead select all 16 volume messages before closing the window. The fader would now control the volume on all 16 MIDI channels simultaneously. Thinking this example through, you'll see that this indeed is a potentially very useful and flexible application of sysex faders -- something you would not be able to achieve conveniently in any other fashion.
If you require two data bytes to be modified by the fader instead of one (because you need values > 127, or because you need to send negative values in a 2-byte system), pick one of the options from the "Value" popup. I won't go into details her (see the LA manual for that, page 5-90 in the 4.0 manual). Since sysex can often better be manipulated by using a transformer set to "Sysex Mapper" mode, going into all possible details regarding the sysex fader seems a bit pointless. The Sysex Mapper is treated in another article.
If you ever want to automate these sysex faders directly: no-go. Normally you would set the fader's In-definition to match it's Out-definition, record the fader output on a track, and then assign the track to the fader when playing back. This works perfectly for continuous controllers and such, but not for sysex faders. The problem is that Logic only "looks" at the first 6 bytes of a sysex message. As soon as "the interesting stuff" happens after the 6th byte (which is almost always the case), you're basically lost. Therefore you should never try to automate sysex faders directly. There is a workaround however...
The work around for sysex fader automation is as follows: change the sysex fader's in-definition to something little used, like controller-100. Now create a fader whose in & out definitions are CC100. Connect its output to your sysex fader. Move the sysex fader off-screen (you don't use it for dragging anymore, but just for transforming CC100 to sysex), and use the CC100 fader for sending sysex, recording and playback. If you have 20 sysex faders, do something similar: every sysex fader should have it's own in-definition (e.g. CC-100 to CC-119), and should be connected to a controller fader with corresponding in/out definitions. Then connect one (default, i.e. no settings applied) transformer or monitor object to all 20 CC faders, and assign that one to a track. Now recorded data in the CC100 - CC119 range on that track will, through the transformer / monitor, reach your controller faders, which in turn will forward the message to the off screen sysex faders. Setup & idea are similar to the channel splitter trick used on audio objects. The order of connection is thus: transformer -> 20 controller faders -> 20 sysex faders.
This may sound very complicated, but it really is not. Take a look at the environment that comes with this tutorial for an example.
The foregoing was written when Logic v4.x was the current version. The Sysex fader has somewhat beeen fixed since Logic version 5: the fader a.o. "looks" at more than 6 bytes now, although there still is an upper limit. This means that in some cases you can now use the Sysex Fader to correctly transform incoming sysex to e.g controller messages.The details:
SysEx messages of 15 bytes (including StartOfExc and EndOfExc) are correctly recognised. You can thus use a message like
F0 02 03 04 05 06 07 08 09 10 11 12 13 VAL F7
It doesn't seem to matter what position the VAL byte occupies.
Longer messages are not recognised at all, regardless of the position of the VAL byte. Unrecognised messages (i.e. messages that are too long) are passed through a fader unaltered, as one would expect.
For the rest the following buggy behaviour seems present:
Setting a fader to SysEx 'In' and either Meta or Fader 'Out' doesn't work properly: the incoming sysex is recognised, and a value is sent out based on the *third* byte of the message (counting all bytes -- so that would be value "3" in the example message above). An obvious workaround is to have the fader convert incoming sysex to some controller, and use a transformer to make the controller into either a Meta or Fader event.
(c) H.J. Veenstra 2001.