Adventures In MIDILand (Part 1)
Part 1: Martin Russ sets off on a wild and wacky expedition through the MIDI Programming Jungle.
One of the feedback comments which consistently arose during the 'System Exclusive' series, was "When are you going to do the same for ordinary MIDI?". My answer is in your hands at this moment!
Before we set off into the land of MIDI, a few words of warning. We will be going where the natives have probably never seen the sort of crazy, mixed up, messed about with MIDI messages we will be using, so you need to be on your guard.
All sorts of unexpected things may happen, so always be ready to powerdown anything which locks up or starts throwing out loud noises. Despite the serious nature of this warning, remember that many earlier explorers have already passed through without suffering casualties. I myself have come face-to-face with some of the nastiest MIDI problems imaginable, and survived.
In the course of our exploration we will discover some unusual and interesting things, so be prepared to make further investigations on your own. This trip is designed to help you learn by showing you some of the more exotic denizens of the world of MIDI. You will find some useful tools on the toolkit disk: the rest of this series will explain how to use them.
Before setting off you will need the following equipment (in approximately descending order of importance):
The basic connection of the MIDI equipment is very straightforward. The Out of the MIDI keyboard is connected to the In of the ST, and the Out of the ST is connected to the In of the expander (Figure 1).
More advanced MIDI users may like to experiment with adding a Thru box and MIDI Switcher (Figure 2). This will help in setting up, and can also add increased functionality. It also helps integration into a conventional MIDI network.
There are going to be lots of programs used in this series — more than 30 in total. With a few exceptions, all the programs are short and simple, and they are designed to illustrate the important points but not necessarily provide everyday usage in a working MIDI studio. (See panel for details of where to obtain the floppy disk containing the example programs from this series.) If you are interested in taking any of the ideas further, then a professional sequencer is probably a good place to start looking for the relevant features. If a serious, high-specification sequencer cannot achieve the effects you want, then write to the manufacturer and ask why not — often they will have hints and tips for doing most things.
The more complex and serious programs in this series are designed to show what can be done by taking the basic ideas and developing them. The source code will be supplied only for the simpler programs, although the basic operation of all programs will be described to show the principles of how they work. In most cases, it will not be necessary to follow the programming examples to understand what is going on, but you will get more out of the series if you do.
Because the Atari ST will be fully occupied doing MIDI processing, it may be useful to find another ST owner and use the second ST to monitor the MIDI messages, or even run a sequencer. Such a combination is a very powerful creative tool for the serious MIDI explorer, and anyway, it is more fun investigating things with a friend! One of the major side-effects of MIDI is that it seems to produce musicians who hide away in home studios. I hope this series encourages you to share your investigations with other people — the result will be a much richer and more rewarding experience.
Just about the only thing I will not be talking about are System Exclusive messages — anything else is fair game. I suggest that you make sure you are aware of the important points about MIDI before proceeding. Most of the exploration will focus on MIDI Channel Voice messages, with just a few System messages. In past issues, Sound On Sound has published some excellent articles covering the basics of MIDI, and some of the books in the SOS Bookshop (see p.77) are good references, too. From here on, things get tough!
The initial starting point for any investigation of how to manipulate MIDI messages involves looking at exactly what is happening. The 'System Exclusive' series [SOS April '89 to March '90] introduced two sophisticated programs which displayed MIDI messages in graphical form on-screen, but gave no clues as to what they were doing. This series will start out by revealing how the programs are working, although the MIDI Display program is much simpler, with a clear and concise text output only.
Incoming MIDI data appears at the ST's Port number 3, and outgoing data should therefore be presented to Port 3. This means that you can read the MIDI In port just as easily as the keyboard. So just as this program segment
Pause = INP(2)
makes the program pause until one of the ST's QWERTY keys is pressed, so this program segment
Pause = INP(3)
makes the program pause until a MIDI message is received at the ST's MIDI In socket. Because the ST is a 16-bit machine, it assumes that the incoming data from the MIDI port is also in 16-bit format, so you need to chop it down to 8-bit to produce ordinary MIDI data bytes:
MIDI_input = INP(3) AND &HFF
By using logical operations on the incoming MIDI data, it is possible to mask out the various parts which may be of interest:
Status = INP(3) AND &H80
This program segment sets the variable Status to $80 if the MIDI byte is a status byte — ie. if the most significant bit is 1 (or any bytes from $80 to $FF). Otherwise, Status is set to zero — so for MIDI data bytes the Status will be zero. Similarly, this program segment
MIDI_byte = INP(3)
IF (MIDI_byte AND &H80) = &H80 THEN
Channel = MIDI_byte AND &H0F
Channel = Channel + 1
checks that a Status byte has been received, then sets the variable Channel to the value of the MIDI channel and increments the value by one to give the normal representation. Remember that MIDI Channel 1 is represented by $0 in the actual MIDI messages.
By placing this sort of segment inside a loop, it is possible to make a simple MIDI Display program. The lowest level just displays the raw bytes:
MIDI_byte = INP(3) AND &HFF
PRINT " ";HEX$(MIDI_byte);
escape$ = INKEY$
IF escape$ <> "" THEN GOTO leave
In this segment the program flow goes around a loop formed by the start label and the GOTO start statement. Inside the loop a MIDI byte is input and masked to eight bits, and is then printed out in hexadecimal. Exiting the loop is made possible by detecting the pressing of a key on the ST's QWERTY keyboard.
This loop will form the fundamental structure of almost all the program segments which follow. The two lines containing escape$ are included so that it is possible to leave the loop by pressing any key on the ST's keyboard. Notice that this will only work if the ST receives a MIDI message, since otherwise the INKEY$ statement is never executed. This is a common feature of all the programs which follow in this series. Normally, Active Sensing messages will mean that you can leave the loop at any time, but if these are not present then playing a note should also cause the loop to be exited, since the keyboard will then be read by the INKEY$ statement.
By using the already developed Status byte detector, it is possible to extend this loop segment so that it has a more meaningful display:
MIDI_byte = INP(3) AND &HFF
Status_test = MIDI_byte AND &H80
escape$ = INKEY$
IF escape$ <>"" THEN GOTO leave
IF (Status_test = &H80) THEN PRINT
PRINT " ";HEX$(n);
This segment incorporates the test for a status byte and produces a new line in the printout. This means that the screen display shows the status byte followed by the data bytes, with each new status byte on a new line. Presenting the information in a clear way can make it much easier to interpret the MIDI data.
I have already mentioned Active Sensing, and if this MIDI message is active on your master keyboard, then you will see lots of $FE messages causing the display to scroll upwards. This can be rectified by removing any Active Sensing messages:
n = INP(3) AND &HFF
a = n AND &H80
escape$ = INKEY$
IF escape$ <> "" THEN GOTO leave
IF (n=&HFE) THEN GOTO start
IF (a = &H80) THEN PRINT
PRINT " ";HEXS(n);
This program segment also replaces the variable MIDI_byte with the more manageable n, and similarly the variable a replaces Status. The new line, shown in bolder type, causes the program to go back to the 'start' label and so miss out the statements which print out the MIDI bytes — thereby filtering out just the Active Sensing bytes.
An expanded and extended version of this simple program, incorporating Active Sensing filtering which can be switched in and out by pressing the spacebar on the Atari ST, is our first program of this series. All the programs are given slightly cryptic filenames, because of the problems of fitting them into only eight characters, so this program is called MDISP01.TOS. Almost all of the programs should work in all three ST screen resolutions (low, medium, high), which is one reason why GEM and sophisticated graphics have not been used.
To run the MIDI Display program, just double-click on the program icon displayed on the ST's desktop and it will run. Pressing the 'Q' key on the ST's QWERTY keyboard will return you to the desktop, and pressing the spacebar will toggle the filtering on and off. This 'quick and dirty' style of user interface is more or less standard in all the programs — explorers must be able to put up with some hardships!
So what does the program do? After double-clicking on the program's icon, the program will load and run. The screen will then clear and the program title and some other information will appear at the top of the screen. The program starts out in the mode where Active Sensing bytes are filtered out, so you will see nothing until you actually send some MIDI messages to the ST. Pressing a key on your master keyboard should produce a display like this:
90 3C 70
This is a MIDI Note-On message for note number 60 ($3C) on channel 1, at a velocity of 112 ($70). Releasing the key will produce the corresponding Note-Off message, which can be in one of two forms:
80 3C 40
90 3C 00
The first message is a true Note-Off message from a keyboard which does not implement Release Velocity, and so the velocity defaults to 64 ($40). The second message is a Note-On message with a velocity of zero, which can also be used as the equivalent of a Note-Off message.
Moving the Pitch Bend or Modulation Wheels will produce a stream of messages beginning with either a $E0 or $B0 byte, assuming that the master keyboard is set to MIDI channel 1.
Pressing down on the key will produce a similar stream of messages beginning with $D0, or $A0 if the master keyboard provides Polyphonic Key Pressure (the latest Ensoniq keyboards do this).
By pressing the spacebar on the Atari ST's QWERTY keyboard, you can toggle the program into the Unfiltered mode, whereby the screen should gradually scroll upwards as the $FE Active Sensing bytes are displayed. Some master keyboards do not transmit this message at all, so do not be surprised if nothing appears different! Equally, some 'workstations' send out MIDI clocks ($F8) all the time, and this can also cause unwanted scrolling of the screen. As an exercise, try altering the program yourself so that it filters out MIDI clocks.
In our first brief excursion into the land of MIDI, we have seen how to extract some useful information from a MIDI byte, how to display MIDI information in a useful way, and how to escape from a MIDI input loop. Simple stuff, I know, but this is the foundation on which we will be building. This basic program segment will be added to in next month's installment, which shows you how to deal with Running Status — something which confuses many MIDI programmers at first.
The MIDI Display program provides a way of testing your understanding of the way MIDI works. Try decoding the display on the screen and see how it matches what you send to the ST from your master keyboard. Most (but not all) of the standard MIDI messages have a three byte structure, so try to get used to looking at these and working out what each byte tells you. If you find something unusual happening in your MIDI system, then using MIDI Display may be a way of detecting what is happening.
The second part of this series will look at MIDI messages in more detail, and show you how to understand messages which are not three bytes long.
Feature by Martin Russ
Previous article in this issue:
Next article in this issue:
mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.
If you value this resource, you can support this project - it really helps!