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 "stransf.lso".
This article supposes you're able to read hexadecimal numbers and have some basic knowledge w.r.t. sysex. You might first want to read my article dealing with hex notation, or the general sysex article.
As I pointed out in the tutorial on the use of the sysex fader, the sysex fader has its shortcomings. The most important is that it's not possible to manipulate several bytes in the message at once. And even though there are several provisions for sending multi-byte messages (like negative numbers or values over 127) by means of the "value" popup in the sysex fader's event list, these options are rather limited. I you need to change both the 6th and 8th byte of a message, for example, then there's no way to achieve this. This is where the "Sysex Mapper" mode of the transformer shines. It allows you to manipulate every individual byte of a sysex message on the fly. On the other hand, we also saw in the sysex fader tutorial, that sysex faders can accomplish neat tricks, like sending 16 volume controller messages at once. That is something the transformer can't do. So today we'll be dealing with pure sysex and nothing else.
We'll start out by simply trying to create the exact same message we created in the tutorial on sysex faders, only this time with the help of a transformer. So we want a patch that ultimately sends out a message like
F0 18 08 00 03 VAL 00 F7
where "VAL" is the value as controlled by a fader.
Create a new transformer, double click to open its window, and set its mode of operation to "Sysex mapper" (in the top popup menu). Since our sysex message will be 8 bytes long (counting F0 and F7), change the "sysex length" parameter to 8. Now edit all values, until it looks like
F0 18 08 00 03 00 00 F7
We now want to be able to dynamically change the 5th byte (somewhat inconsistently counting now ignores the first byte F0 (start of exclusive)). Easy: the trick with sysex mappers is that any controller arriving at the input will change the byte corresponding to the controller number. The value of the byte is determined by the controller value. That means that by just changing controller number and value we have full control over the entire sysex message!
So what we do is: create a new fader, and set it's 'In' and 'Out' definitions to be "control 5". Connect this fader to the sysex mapper transformer. Since the controller number is '5', the fader will affect the 5th byte in the message -- just like we wanted. In principle we're already done. Lets check if it all works:
Open the transformer window and position it such that you can see the sysex message and the fader at the same time. Drag the fader and watch the message: presto. Try changing the fader's out definition to controller 6, and see what happens: the next byte will be modified. Et cetera. If only life was as simple...
Automation might seem straightforward at first sight: simply record the movements of the fader and put them on a track. Then assign the track to that same fader, and you're done. Well, if you have just one fader and this is all you want to do, then indeed automation can be that simple.
However, if you're changing a sysex message's 7th byte, then recording the fader will record CC7 data, which normally is 'volume'. This might be confusing. And, worse, you might have a bunch of sysex transformers with faders, all modifying the 7th byte (all modifying the value of a different synth-parameter but the value byte is always in the 7th position), and thus all faders would send out CC7 data. In order to automate those, you would have to use one separate track for each fader, which is messy and clumsy.
The solution is similar to the solution in the sysex fader case (see the tutorial on sysex faders): if you have e.g. 10 such fader / Sysex Mapper combinations, set the fader's in-definitions to e.g. CC's 100 to 109 respectively. Create 10 new faders, whose "In" and "Out" definitions are set to CC's 100-109 respectively, and cable them into the 10 old faders. Connect a (default) transformer to the 10 new faders. Use the 10 new faders for recording. Assign a track to the transformer, and put your automation data on that track (the accompanying environment shows an example of this technique). So it looks like this:
+-> fader in=100, out=100 --> fader in=100, out=7 --> sysex mapper
transformer -+-> fader in=101, out=101 --> fader in=101, out=7 --> sysex mapper
+-> fader in=102, out=102 --> fader in=102, out=7 --> sysex mapper
It's clear that the second set of faders (the ones we originally used to control the sysex mapper) now only play the role of a transformer: they translate CC100+ messages into CC7 messages. It would therefore be much cleaner to actually use transformers here instead of faders (as is indeed done in the accompanying environment). Replace the faders by transformers set to "Apply operation and filter non-matching events" (top popup in the transformer's window). Set their Conditions to: Status = Control, -1- = 100 (101, etc.). Set Operations to: -1- Fix: 7.
We can still improve on the above scheme. Suppose we have five Sysex Mappers which need to have both their 5th and 6th byte modified. The above strategy would require us to use 10 different controllers to control those 5*2 bytes. This is very unclear: how do you ever remember which controller is supposed to do what?
What we can do instead is to use the MIDI channel as a "Sysex Mapper selector", so that only messages on channel 1 get sent to the first Sysex Mapper, messages on channel 2 go to the second Sysex Mapper, and so on. We could then use e.g. CC100 to control the 5th byte of each message, and CC101 to control the 6th byte.
To achieve this we modify the above scheme as follows: replace the 'input' transformer by a Channel Splitter, and connect output-1 of the Channel Splitter to the top fader (the one that will control byte 5 of Sysex Mapper 1), connect output-2 to the second fader (the one that will control byte 5 of Sysex Mapper 2), etc., until you reach output-5. Now we create 5 new faders, which will control the 6th byte of all Sysex Mappers. The first 5 faders need to be adjusted: set their channels to 1-5 respectively (input and output) and their In and Out definitions to CC100. Do the same for the new set of 5 faders, now setting them to controller 101.
Now cable the faders serially. I.e. cable the channel 1, CC100 fader into the channel 1, CC101 fader. Repeat for the other channels. Finally hook up transformers to all faders that transform CC100 to CC5, or CC101 to CC6. Now each set of 2 transformers can be cabled into the Sysex Mapper belonging to that channel and you're done.
Important. The transformers that transform CC100/101 to CC5/6 should now have an additional setting: in the "Operations" section of the transformers, the Channel should be fixed to 1, otherwise it won't work. Why? Well, the channel has a special meaning for messages used to modify a Sysex Mapper. A controller on channel 1 means "send the modified sysex message now". Channel 2 means "don't send the modified sysex message" -- i.e. the message is modified, but sending is postponed. Channel 3 means "send the unchanged message". All other channels have no meaning and are reserved for future use. See the Logic Manual, version 4, page 5-45.
It is therefore a good idea to always "fix" the channel to 1. That way your patch will continue working, even if you change the input controller to a different channel. The only exception to this rule is when you definitely need to postpone sending the message, as is the case with multi-byte messages (on which there is a separate tutorial).
Sounds complicated? Well, it is a bit of work, true, although you can save yourself quite some time by smart copying and pasting. Set up stuff for one channel first and make sure it works. Then copy, and paste 4 times. Now all that's left is to adjust the channels on the faders and do some cabling. Take a look at the environment that comes with this tutorial to see a setup that implements this idea for 2 Sysex Mappers.
A disadvantage of the previous approach is that after 16 Sysex Mappers you run out of channels. So for every 16 parameters you would have to use a separate automation channel. In such cases the first scenario of using a separate controller for each parameter (Sysex Mapper) might be preferred. It all depends on your specific needs.
The environment's "Standard" section shows how you can use one automation track to control 320 or more (maximum 128 * 16) separate Sysex Mappers by using a combination of the previous strategies.. The trick here is to use both MIDI channels and controller numbers: every channel/CC pair controls exactly one Sysex Mapper. Probably this is the most flexible way to go about automating sysex messages. Hence I named it "standard": not because it is standard, but because it should be.
The obvious advantage of using a Sysex Mapper instead of a fader, is that a Sysex Mapper allows you to determine 'on the fly' which byte to modify, whereas a fader requires you to determine this while setting up the fader. And, even more importantly, a Sysex Mapper allows you to modify more than one byte, which is not possible with a sysex fader. Or at least, not as straightforward and flexible.
This last point is especially important when dealing with multi-byte messages. Often a sysex parameter change will require you to control two bytes (MSB and LSB) instead of one. This will particularly be the case as soon as you need to control values that exceed the 0-127 value range (like 0-200, or -99 - +99). Those are quite common, as you will realize, so it might be a good idea to use Sysex Mappers instead of faders from the onset.
Multi-byte sysex messages are treated in a separate tutorial.
(c) H.J. Veenstra 2001.