The Transformer object in the Environment is one of the most powerful tools Logic has to offer. With a little bit of MIDI know-how, it can become an incredibly powerful creative tool. In the second part of this Environment series we’re going to look at the basic concept of how the Transformer interprets and manipulates MIDI messages. Even if you don’t have Logic, there’s some useful information about MIDI as well.

Before we start I’d recommend you read the article first — before watching the screencast!

Screencast

Introduction

In Logic ‘transforming’ is the process of altering MIDI messages. It can either be used to modify incoming MIDI messages via the Transformer object (which can be found in the Environment) or to modify prerecorded MIDI parts via the Transform window (Command+4). The object version can be used for more creative purposes while the window version can be used for batch processing MIDI data in your arrangement and save you heaps of manual labor. Although we’re not going to cover the Transform window in this tutorial once you understand the concept it’s pretty much the same as the object.

But first to use these powerful features it’s vitally important to understand how a MIDI message is constructed as both transformers use this structure as the basis for tasks. Without knowing this it just looks scary!

The Anatomy of MIDI

MIDI is without a doubt one of the most important technological developments in music production of the last 25 years, even crossing over into our everyday lives — just think mobile phone ringtones. It even controls games like Guitar Hero! We all use it in music production, but mostly on a very superficial level through a UI. So what is MIDI and how does it work?

MIDI (short for Musical Instrument Digital Interface) is an 8 bit binary language that was developed in the early 80’s by Dave Smith and Chet Wood in an attempt to standardize communication protocols between different manufacturer’s evolving digital synthesizer technologies. In 1983, the MIDI 1.0 specification was released to the world and despite a couple of enhancements remains pretty much the same to this day. It allows all manner of musical devices from synths, sequencers, hardware effects and even stage lighting to speak to each other in a cross-platform, universal language.

MIDI data is sent inside a MIDI ‘message’. There are three kinds of MIDI messages.

• Voice – Used to control things that relate to performance like notes, pitchbend and other controller data. These are the most common types of MIDI messages and the most basic.
• Channel Mode – Voice controller numbers 120-127 are reserved for Channel messages that affect how the MIDI channel operates. Is it Monophonic or Polyphonic? Others include Reset for notes and controllers and Local On/Off that unlinks the keyboard from the synth engine.
• System Exclusive – These messages are used to reach parameters that MIDI wasn’t designed to get to. They are usually manufacturer specific and transmitted in Hexidecimal format. They can relate to internal parameters like chorus speed or reverb time. Every manufacturers device has a unique SysEx ID that has to be transmitted in order to access these types of parameters. They also access MIDI timecode and MIDI Machine Control data and System Dumps for downloading a sound’s parameters onto a sequencer track for later recall. This is not light reading folks, proceed with caution!

Luckily we’re interested in voice messages as they control the basic performance data.

Breaking the Code

A basic MIDI message is made up of two or more bytes. Bytes are made up of 8 bits. Each bit is like a switch — either OFF (0) or ON (1). Binary code like this allows us to make big numbers with less code and MIDI was designed to be as small as possible to overcome latency issues as MIDI is transmitted in series (one message follows another).

A byte can have a maximum decimal value of 255 (adding all the ON values). I don’t want to get into a lesson in counting in binary but here’s a very quick example.

There are two kinds of byte types associated with MIDI messages.

Status Bytes – The Status Byte is delivered first. It tells the device receiving it what kind of MIDI message it is. They always start with a 1. This gives them a potential value somewhere between 0-255 — in binary that’s 00000000 – 11111111. Typical voice message Status Bytes are note, pitchbend, control, aftertouch and program change.

More often than not the status byte is split into two four bit messages called ‘nibbles’. In voice messages one nibble holds the type of voice message (status) while the other holds the MIDI channel data. Interestingly the highest decimal value of a nibble is 16, which is why we have only 16 MIDI channels.

Data Bytes – The Data Byte holds the value of the status byte. They always start with a 0 giving them a potential value between 0-127, in binary that’s 00000000 – 01111111.

This value of 0-127 is probably something your very familiar with. Note numbers go from 0-127. Same for velocity, modulation data and so on. One exception to this is pitchbend which uses two bytes giving it 14 bit resolution to avoid ’stepping’. Why 14 bit? Because Data Bytes only have seven bit resolution — don’t forget they start with a 0 which defines them as a Data Byte, and two times seven is 14. This 14 bit message gives pitchbend a resolution of 16,384 steps over all 128 note numbers. Meaning each note has 128 steps before it gets to the next note, producing a smooth transition.

Below is a diagram of a basic Note On message. You get the picture of how bytes are put together to make a MIDI message.

The Transformer Structure

So let’s have a look at our Transformer object. The Transformer object can be found in the environment menus by selecting New > Transformer. Double click the Transformer object and a window will open.

The four rows of dropdowns at the top are labeled Status, Channel, Data Byte 1 and Data Byte 2 just like the structure of the MIDI message in the diagram above. The structure of MIDI messages does vary slightly from one to another. Here’s a quick break down of how voice messages differ. All these will be transmitted over MIDI channel 1 (the second nibble of the status byte). It’s important to add that you don’t need to learn the binary assignments of the Status Bytes, since your DAW will translate them into English.

The only curious thing in this list are the values MSB and LSB. These stand for Most Significant Byte and Least Significant Byte. This is just a binary thing expressing which byte holds the highest value.

Here’s how the voice message structures look when applied to the Transformer.

Conditions

The Conditions section is where you define the parameters you want to transform. The dropdown menus contain various ‘Conditional Statements’. These are similar to the kind of conditionals you find in programming languages like Javascript or PHP in web design. If X = Y, then perform an action on it. Choosing a condition from the drop down will open up a parameter box where you can add the value for your condition. For example choosing ‘Equal’ will bring up one value choice, the number you want your choice to be equal to. Choosing ‘Inside’ will bring up two value choices where you can set the range of your condition. Leaving the dropdown set to ‘All’ allows you to effect the full range, or all values in any given byte.

In the picture above, I’ve set a condition that looks for any MIDI message equal to Control Data (Status Nibble 1) on all MIDI channels (Status Nibble 2) with a controller number of 12 (Data Byte 1) and only effect the values of that controller number between 10 and 50 (Data Byte 2).

Operators

The Operations section is where you apply the formula for your transformations. These can be simple mathematical operations like add and subtract or more complex scenarios using the Map. ‘Fix’ is a very common value here, especially when dealing with the status of the message. To change controller values to note values you would select ‘Control’ in the status column in Conditions and ‘Fix’ it to ‘Note’ in the Operations column. This simply restructures the binary code in the first nibble from 1011 which is Control Change to a different value of 1001, which is Note On. Simple! The ‘Thru’ setting allows data to pass through untouched.

In this example I’ve added 6 to the number in Data Byte 1. This simple operation turns Modulation (Controller No 1) into Volume (Controller No 7). 1+6=7.

Routing

The three lines that separate Conditions and Operations are used to route values from one byte to another during a transformation. This is because most messages have a different structure. For instance if you wanted to convert note numbers to pan values you might think this is okay.

There is a problem here, though. The note numbers are stored in Data Byte 1 in the note message and in the control message the pan value is stored in Data Byte 2. At the moment the pan value is being controlled by note velocity from Data Byte 2 of the note message. To get round this, click twice on the line that connects Data Byte 2. This now reroutes the Note number value into Data Byte 2 of the control message. Problem solved! This makes a good case for knowing the structure of MIDI messages.

Transformer Modes

Transformer Modes allow you perform various tasks dealing with filtering certain messages and how the Transformer actually outputs its data.

A good example is the Condition splitter (true > top cable) Mode. This outputs the transformed message via the top output cable and any MIDI messages that don’t meet the Conditions specified (i.e. Control No 1) are passed out of the bottom cables. This is very useful when you want to redirect just the transformed data to a different destination. Below you can see that the Note messages ( which don’t meet the Condition ) are passed out the bottom cable. The manual has full details of the modes so check them out.

There are some cases when modes are the only way to solve a problem. The screencast has a good example of this using the Alternating Split mode to separate Note On and Note Off messages.

Maps

The Map is available in both Conditions and Operations, although you can only use one Map at any given time. Think of it like an XY graph.

It basically allows you to map any number between 0 – 127 along the X axis to a different value using the Y axis. This is done by using the mouse to draw in the new value or using the input boxes at the bottom.

There are many applications for the map like creating velocity curves and random numbers. In the Operations dropdown list there are several operations that use the map as a base but use parameters to modify it. These include Random, Crescendo, and Reverse. Only the option called ‘Use Map’ allows you to input your own custom map.

Below you can see by pressing the ‘Initialize’ button the values along the bottom (X axis) are the same as the values on the Y axis.

By pressing the ‘Reverse’ button at the bottom the values along the bottom are now inverted. What was 0-127 is now 127-0.

This is a very simple example and it’s possible to create very complex and specific maps if you want. One thing to look out for is drawing in the map can be very tedious due to its size, so patience is required!

Using Monitor Objects

Monitor objects allow you to see the information passing through a cable. These are essential for troubleshooting MIDI. The data is represented in four columns just like the structure of the transformer. Just insert them between objects to keep track of your MIDI messages.

MIDI Resources

If you’d like to learn more about MIDI there are plenty of resources out there. Here are some good starting points.

• A list of Controller Number assignments
• MIDI Note numbers
• MIDI on Wikipedia
• MIDI Manufacturers Association

Conclusion

After reading this you should have a pretty fair grasp of how the Transformer works and maybe learned a thing or two about MIDI. Like all things, the more you practice and experiment the better you’ll get at using the Transformer. Of course the key is thinking up some clever uses for it! The manual is a good place to start to understand things like the Modes and Conditional Statements. Next time we’re going to put it all together and build some performance related stuff in the Environment. I hope this has been useful, and see you next time.