Using Mixermaps In Steinberg's Cubase Sequencer

The facility to construct sophisticated arrangements of virtual faders, knobs and buttons, and use them to control studio equipment via MIDI, is one of Cubase's most powerful features — but also one of its most under‑used. Paul Sellars explains how to make Mixermaps work for you.

Steinberg's Cubase is perhaps the most widely used sequencing package on the planet, and Mixermaps are an integral part of it. However, I suspect that many of us have really not explored their full potential — perhaps preferring actually making music to struggling through the second half of the Cubase manual! This article aims to show you how you can edit or create Mixermaps to best complement your MIDI hardware and working methods. It will deal specifically with MIDI Mixermaps as implemented in all versions of Cubase, right back to early versions on the Atari ST. It will not cover the audio mixing capabilities of Cubase Audio or VST, as these represent a quite different ball game.

The Basics

Before we get on to looking at the finer points, let's be sure we know the basics. What is a 'Mixermap' anyway? Well, a Mixermap is a customisable graphical representation of a control surface, which often resembles a mixer, and is used to record data on one or more dedicated Mix tracks within a Cubase Arrangement or Song. When played back through the Mixermap, this data generates MIDI messages which are output to whatever devices are connected. This MIDI data is typically not of the 'note on' or 'note off' variety, but instead consists of things like controller data (such as changes in the volume or panning of an instrument) or more esoteric stuff like System Exclusive data (more on this later).

Data is generated by moving the 'objects' (graphical faders, knobs and so on) that make up a Mixermap, either with the mouse pointer or by using a hardware controller that has been assigned to one or more of the objects. Movements can be written in real time (a 'dynamic' mix) or in step time (a 'static' mix), depending on the kind of results you want to achieve. 'Snapshots' (which are records of the positions of every object in a Mixermap) can be taken and recalled at will, thereby allowing for extremely complex and precise mixes. Of course, as many other data types than just volume and pan controllers can be sent from a Mixermap, the end results can be considerably more interesting than just 'a mix' in the conventional sense. It is quite possible, for instance, to create Mixermaps which act as patch editors for synths, and then use them to record and edit voice parameter tweaks within your song (consult your Cubase manual for a more in‑depth guide to the actual process of recording and editing a mix).

How Does It Work?

Mixermap objects are used to send various different kinds of MIDI messages. There are some very common kinds of MIDI messages (such as Note On and Note Off messages) which will be recognised by practically every MIDI device you will ever come across. On the other hand, there are some kinds of MIDI messages which will only make sense to a particular machine built by a particular manufacturer. These latter messages are extensions of the standard MIDI protocol, and are called 'System Exclusive' messages

The data within messages of either kind always takes the same form: a series of hexadecimal bytes. In English this means that a MIDI message is just a series of numbers — but numbers that are written down strangely. It's the writing‑them‑down‑strangely bit which can seem confusing, but it's really not difficult. You just have to remember that our normal (decimal) method of counting is only one possible way of representing numbers. For example, although it seems very natural for us to use the characters 8, 9, 10 and 11 to represent the numbers eight, nine, ten and eleven, we could equally use the characters 8, 9, A and B to represent the same numbers. By adding the extra characters A, B, C, D, E and F to the standard set of numerals from 1 to 9 it is possible use a 16‑based (hexadecimal), rather than a 10‑based (decimal) counting system.

A byte is composed of eight 'bits', each of which can represent one or zero; it can store values between 0 and 255 (decimal), equivalent to 0 and FF (hexadecimal). The hexadecimal values are used simply because they're more convenient in many computer‑related situations.

Although a total range of 0‑255 is possible, the vast majority of data transmitted via MIDI falls within the range of 0‑127 (0‑7F in hexadecimal). Table 1 on page 182 shows how decimal numbers between 0‑127 are converted to hexadecimal 'MIDI bytes'.

In Practice

So, how do we put these MIDI bytes to work in a Mixermap object? Well, first we must create the object, then we can see about 'programming' it. In the MIDI mixer window, choose the 'Create' tool from the mouse toolbox and select an area of empty space. The 'Object Definition' dialogue box will be called. Here you can choose the object's name, appearance (see page 184 for the different types) and range — and, more importantly, in the 'input line', you can enter the MIDI message which will determine what the object actually does.

Just above the input line there are two drop‑down menus, the first of which is marked 'Status'. The function of the second menu varies according to the setting of the first. This first 'Status' menu contains seven options, each of which represent different preset message types. The options are 'Note', 'Poly‑Press', 'CtrlChange', 'ProgChange', 'Aftertouch', 'Pitch‑Bend' and 'SysEx'. As you select each of the different options, different message bytes will appear in the input line. The bytes that are initially displayed will not always make up a complete message, but should at least give you a sense of the structure of the different kinds of messages.

The Structure Of MIDI Messages

The most important byte in any MIDI message — whether sent from a Mixermap, a synth keyboard, or anywhere else — is the first one, which is known as the 'Status Byte'. This byte determines what kind of message is to be sent. It also usually contains information about the MIDI channel the message is sent on, although in the case of Mixermaps this is over‑ruled by the channel setting in the Object Definition dialogue box. Status Bytes can be selected from the 'Status' drop‑down menu above the input line, or entered manually. Table 2 on page 184 shows what they mean.

Status Bytes, with their respective required successive bytes, can be thought of as making up the 'header' of a MIDI message. The header gives a detailed description of the function or parameter that should be effected, but does not describe the extent or amount of the effect. Typically the header of a MIDI message will be followed by a data portion which contains this information. For example, the following two messages describe a pitch‑bend:

E0, 10, 76 followed by E0, 00, 40.

You can see that both messages begin with the Pitch‑Bend Status Byte, E0, and are followed by two data bytes. The data in the first message describes a pitch‑bend with a fine value of 16 summed with a coarse value of 118 (10 and 76 respectively in hexadecimal). The data in the second message describes a bend with a fine value of zero and a coarse value of 64 (40 in hexadecimal) — which actually represents the central position of the pitch‑bend wheel or lever, and effectively amounts to no bend at all. Sent one after the other, then, the above messages would have the effect of a sudden sharp bend up in the pitch of an instrument, and an equally sudden return to normal. More smooth and gradual bends of the kind created by moving a pitch‑bend wheel or lever (or by moving a Mixermap object programmed to send pitch‑bend data) would involve sending a long series of messages, each with a data portion representing a small incremental change.

Variables

However, as you can see on the right, there is only space to type one message in the Object Definition dialogue box — and indeed it would be impractical to manually type the number of messages required to create smooth continuous effects suited to Controllers such as Pitch‑Bend, Pan, Main Volume and so on. Mixermaps instead send as the data portion of their MIDI message a variable byte, which alters to reflect the movements of the object. The variable is usually entered into the object as the 'byte' XX (although for some kinds of SysEx message the byte pair XX, 00 is used instead).

So, bearing in mind all of the above, let's have a look at some simple Mixermap objects and their messages:

• Volume fader

Here the Control Change Status Byte (B0) is followed by the Main Volume controller number (07), and then by the variable. Of course, you are not limited to only using fader‑shaped objects: any object can be used for any function, although 'button' or 'text' objects wouldn't make a lot sense in this context. Message: B0, 07, XX

• Pan knob

As above, the Control Change Status Byte is followed by a controller number — in this case Pan (0A). Message: B0, 0A, XX

• Program Change Counter

As you can see, only a two‑byte message is required: the Program Change Status Byte followed by the variable. Message: C0, XX

• Pitch Bender

Here the Pitch‑Bend Status Byte (E0) is followed by a fine bend value of zero, and that the coarse bend value is given as the variable byte. This means that the object will send out coarse pitch‑bend data only. You could choose to send only finepitch‑bend data by entering the variable as the second byte instead of the third, or you could create a pair of pitch‑bend objects, one for fine values and one for coarse. However, Cubase only allows one variable per object, so you could not send both fine and coarse bend values from a single object. You might want to use a horizontal fader object for this one. Message: E0, 00, XX

Obsessed With SysEx

The above Mixermap objects have the great advantage of being simple and general enough to work with a wide variety of MIDI devices. However, they really only scratch the surface of what can be done with Mixermaps. In order to explore some more interesting possibilities, you'll have to learn some of the System Exclusive code implemented by your various machines.

It's difficult to generalise about SysEx because each manufacturer devises their own protocols and rules to suit their own particular machines. You'll need to get hold of the manufacturer's SysEx documentation for whichever device you will be concentrating on. If you're lucky, this will be in the back of the manual for the machine. If you're very lucky, you may even be able to persuade the device to display the relevant code for you (something some of the Yamaha MU‑series synths will do if you press Enter twice whilst in edit mode). If you're unlucky you may have to contact the manufacturer, or search the internet for relevant web sites (official or unofficial).

It's difficult to generalise about SysEx because each manufacturer devises their own protocols and rules to suit their own particular machines.

Another invaluable weapon in your battle with SysEx is the 'Learn' function available in the Object Definition dialogue box. This function can be used to receive SysEx messages sent from a MIDI device (don't forget to connect its MIDI out to Cubase's MIDI in), and from them extrapolate the right code required to access a particular function. To call this feature 'labour‑saving' would be a gross understatement! However, unless you are very lucky, you will not be able to do it all using the Learn function alone. First of all, not every parameter on every device will send SysEx data when altered, even though they might respond to any SysEx received. Secondly, depending on the eccentricities of a particular manufacturer's SysEx, Cubase might not be able to extract a complete or usable message from the data it receives. Sometimes you might get part of a message, but you may need to consult the manufacturer's documentation to correct errors, or add missing bytes.

You may find that the documentation specifies that data in the message must be sent in a particular non‑standard form, which can present problems when using standard Object variables to send data. The Options menu (next to the Status menu in the Object Definition dialogue box) offers several conversion options which are designed to help work around these problems. There are specific options for Korg, Roland and Lexicon devices, and a couple more general conversion possibilities. It should be clear from the documentation which (if any) of these options you'll need to use. If you do use one of the conversion options for an object, you must follow the XX variable byte in the message with 00. Be aware that, for some varieties of SysEx, there may not be an absolutely perfect Mixermap solution. Some compromise may be inevitable.

Case Notes: The Akai S2000

This is a prime example of a kind of SysEx that is really not well suited to Mixermaps. The Akai SysEx documentation states that the data portion of any Akai SysEx message must be sent "...in a nibbled form, ie. each data byte is represented by two message bytes; the bottom nibble of the first containing the bottom four bits of the data byte and the bottom nibble of the second containing the top four bits of the data byte." In practice, this means that any byte must be split into two. For example: to increase a given parameter by a value of 25 (19 in hexadecimal) you have to split the byte into two characters, 01 and 09. Akai SysEx requires you to send the least significant byte first, so the data bytes of the message would be 09, 01.

However, this presents an obvious problem as far as Mixermaps are concerned: only one variable byte per object is allowed. The Akai requires all data to be sent in nibbled byte pairs. The problems arise if you want to send values greater than 15 (0F in hex). As the Akai expects to receive the least significant byte in the bottom nibble (second character) of the first byte of a pair, it completely ignores the top nibble (first character). So if you send 1A, the Akai responds as if it was 0A. And as the second byte of the pair is never sent at all, the problem is compounded by the Akai's assumption of a null second byte (effectively 00). This means that whether the value of the Mixermap object variable is 0F or 1F, the Akai will respond as if it had been sent 0F, 00. In other words, as far as the Akai is concerned, it is impossible for a Mixermap object to count higher than 15!

The conversion function 'MIDI Byte ‑> 2 Nibble' available in the Options menu is supposed to generate a nibbled MIDI byte pair from the single‑byte variable. However, this is really intended for use in situations where values outside the range of 0‑127 need to be sent, and it does not seem to solve the Akai nibbling problem — although it does alter it slightly!

What this means in practice is that you can only really create SysEx objects for parameters which have an effective range of 0‑15 or less. This is quite a major limitation, but it is still possible to create some useful objects. For example, filter resonance only has a range of 0‑15. Likewise you can set a Multi Part to any of the 16 MIDI channels via SysEx, as MIDI channels are counted starting from zero. And these aren't the only possibilities.

An in‑depth guide to Akai SysEx could easily take up a whole article on its own. If you want to learn in more detail then go to www.akai.com/akaipro/ and download all the SysEx documentation you can find. In the meantime here are a couple of examples to get you started (these will work with the S3000XL and S3200XL as well as the S2000):

• Effects bus selector

This object adjusts Effects bus routing for Multi Part one (this requires the EB16 effects board to be installed). The range of the counter should be set as 0‑5. The second byte is the Akai manufacturer code, and the fourth is the operation code 'Receive Multi Bytes'. The fifth byte of the message is the model identity for all Akai samplers from the S1000 to S3200XL (however, this object will only work with the later samplers which have Multi mode.) Bytes six and seven signify Multi Part one. Bytes nine and 10 are the 'offset' for the FX bus function. Message: F0, 47, 00, 42, 48, 00, 00, 01, 71, 00, 01, 00, XX, 00, F7.

• Output selector

The object in this example can be used to select which of the sampler's (optional) eight outputs Multi Part five will be routed to. As you can see, the message is very similar to that used by the FX bus selector, although a different 'offset' is used. Message: F0, 47, 00, 42, 48, 04, 00, 01, 16, 00, 01, 00, XX, 00, F7.

Case Notes: Yamaha Four‑Operator FM synths

By far the easiest way to make use of SysEx in a Mixermap is to have somebody else do all the hard work for you! A quick online search of FTP and HTTP sites will turn up a large number of different Mixermaps created for different MIDI devices by dedicated SysEx enthusiasts. This particular one is a real gem, however, and comes highly recommended. It was created by Martin Tarenskeen, and effectively acts as a comprehensive patch editor for a number of Yamaha's four‑operator FM synths, such as the YS100/YS200, the V50, the TX81Z, the DX21, and the DS55.

Here are a couple of objects taken from the Mixermap, together with their respective MIDI messages:

The strength of Mixermaps is that they allow you to create software control surfaces which are precisely tailored for specific instruments and ways of working, and to record and edit parameter changes as a part of your song.

• LFO Pitch Modulation Depth

As you can see, Yamaha's SysEx is much simpler, and much more suited to use in Mixermaps than Akai's. The second byte is Yamaha's manufacturer code, and the third and fourth refer to the device number and model identity. Just a single variable byte is used, with no extra conversion required. Message: F0, 43, 10, 12, 38, XX, F7.

• LFO Sync

In this example the code is almost identical to that used in the LFO PMD object. The only difference is in the fifth byte, which we can therefore deduce must be the operation code. Message: F0, 43, 10, 12, 3A, XX, F7.

The Mixermap can be downloaded from Mr Tarenskeen's homepage at www.telebyte.nl/~mt/yseditor.htm, as can an excellent FM patch editor/librarian program for the Atari ST. The Mixermap was also created on an Atari, but should be easily portable to all other versions of Cubase on other platforms.

As a long‑time user of the notoriously awkward TX81Z, I was delighted to discover this Mixermap, which not only provides an easy‑to‑use front end for programming new patches, but also has the added advantage of allowing you to record parameter edits as part of your song file. By recording individual edits in sequence it is possible to gradually warp one patch into another during the course of a tune — something which would be absolutely impossible from the synth's front panel. By using snapshots to recall groups of edits, you can employ much more sudden and precise changes in timbre.

Examples like this really illustrate the potential power and flexibility of Cubase Mixermaps. The strength of Mixermaps is that they allow you to create software control surfaces which are precisely tailored for specific instruments and ways of working, and to record and edit parameter changes as a part of your song. Although setting up Mixermaps does take time, they can really help you to get the most from your equipment — and a well‑put‑together Mixermap can save a great deal of time when it actually comes to using that equipment.