Last month I started off by talking about MIDI environments — software tools for simplifying your interface with a complex MIDI setup. This month I'm going to take a deeper look at Dr. T's X-Or (which, for the record, I was running on an ST) and Opcode's Galaxy and OMS.

DR. T'S X-OR

As I pointed out when I first looked at X-Or in the November 1989 issue of Sound On Sound, X-Or is not just another generic editor (in fact, the editing functions are arguably a minor feature). Instead, X-Or is a system integrator, a tool for turning your MIDI equipment into a single music creation device. More specifically X-Or is a combination of a generic librarian and editor, with the ability, via the E-Or editor, to create your own profiles, although it comes with profiles for a wide range of instruments (see panel).

X-Or is the control centre for Dr. T's MIDI environment, and it performs all the librarian/editor/patchbay control/model functions (by 'model' I mean the ability to deal with a software model of the connected MIDI hardware). The editor and librarian sections have exactly the same features as any fully-featured program. The model details are limited to the ST's MIDI interface, although this is bound to change as multi-port MIDI interfaces become more popular. On the Mac, X-Or can use the MOTU MIDI Time Piece and other multi-port interfaces. Bundles collect together profiles into easy-to-load complete 'snapshots' of the system, and provision is made for manual patchbays, although this is not recommended.

When I reviewed X-Or I mentioned that the profile files used to cater for different instruments were being developed and added to all the time, and that a profile editor would soon be available. Well, it is here already, included with version 1.1 of X-Or. (As I mentioned above, I was using X-Or and E-Or on an ST; X-Or is available for the ST, Mac, Amiga and PC, but E-Or is only available for the ST at present.) Although this is an early version of E-Or, and intended for knowledgeable computer users, it provides a fascinating and complete development environment for doing many of the things which I talked about in the System Exclusive series (SOS April 1989 to March 1990). Best of all, it provides one glimpse at how the future of interacting with MIDI system exclusive might look.

E-Or puts you in the driving seat. A manual is included on the disk, which gives lots of background information intended for the programmer, and I should stress that familiarity with both X-Or and the system exclusive features of the instrument for which you want to create a profile are both very important. E-Or itself takes care of many of the tedious and tiresome 'housekeeping' functions, such as getting and sending patches and banks of patches, although you need to supply some information about the format and size of dump to be expected. The editing functions are provided for by using 'objects': sliders, text boxes, and envelopes. These are exactly the same as those which you use in X-Or, except that their position on the screen, their range and the MIDI messages which they transmit all need to be specified and controlled.

The specification is dealt with by several pages of controls which determine all the important features of the objects. The control is provided by a special language — the X-Or Control Language (XORCL for short). This is a low-level programming language, not entirely unlike assembly language, which lets you interact with the objects, with MIDI, and with the internal processes within X-Or. Seeing what is happening is an important part of working with any editing package (I usually use dialogue boxes whilst debugging my programs and then edit them out in the final versions) and E-Or provides a Monitor Window which can be used to display incoming or outgoing MIDI, as well as the contents of X-Or's internal bank and patch storage areas.

E-Or's full GEM environment lets you shuttle between the specification screens, editor screen and E-Or's menus whilst still updating the Monitor Window, enabling you to interact with the whole MIDI system. For most typical applications, you will start out with a simple librarian and then extend it to a full editing and multi-timbral controller package, and the ability to work with the objects, the program and see the MIDI messages makes a potentially difficult job much easier.

Even so, assembly language is not for the beginner, and Bob Melvin, the creator of X-Or and E-Or, intends to make the user interface of E-Or much more graphical and easier to use as it develops — this version is really just a sample for the dedicated user to experiment with I Looking at the supplied profiles can help a lot, however, since they already contain most of the things which you will probably want to implement yourself.

There is no substitute for actually doing 'hands-on' programming (who said that reviewing was easy?), so I set about using E-Or to create a profile to perform a useful but simple task: a MIDI Volume controller. Sixteen numbered sliders are used to send MIDI Controller Number 7 messages to control the volume of any MIDI devices set to that channel number. I found a suitable profile and removed everything except one slider object, which I then copied 16 times to form a bank of slider controls. I then arranged the sliders onto the screen in their final positions, set their ranges and other definitions, and then plunged into the XORCL to try and persuade it to send the appropriate MIDI messages.

Here is the first program which I wrote:

The first two lines do the obvious thing — they send out two MIDI bytes, first the Controller on Channel One byte ($B0), then the Controller Number 7 byte ($07). The last byte to be transmitted is E-Or-ese for the value of the parameter currently being altered by moving the mouse. This is all very well for one slider, but how do you cope with 16 sliders on 16 channels?

This second program takes care of that:

This time the object numbers (from 0 to 15 for my sliders) are added to $B0 (176 in decimal) by using a temporary variable in much the same way as calculators have memories which you can use for storing values. The temporary variable, $07, and the value of the slider position are then transmitted as before.

As you can see, arranging the objects on the screen is the easy part. Writing the code to handle the objects needs careful planning and methodical work if you are to succeed. The Development System environment helps though, since you can use the MIDI Monitor Window to see exactly what the bytes going in and out of the ST are at any time, so you can interactively debug your XORCL code. This freedom from working 'blind' really does help programming MIDI, especially with handshaking, where you need to keep track of MIDI inputs and outputs. Like X-Or, E-Or works 'live' with the profile — there is no compilation process. This means that the profiles are compact and efficient, but conversely it also means that they are complex and need 'interpreting' for their purpose to be understood.

Each of the Profiles supplied with X-Or can be thought of as a training example for you to investigate. Most of the example profiles provided with E-Or are quite involved, and a few simpler examples would help the learner, but E-Or is at present really a tool for the experienced explorer. At the moment the method of entering the commands is primitive, and decoding what the supplied profiles do can be quite difficult. Future versions should make things much more accessible, which should increase the number of E-Or users.

If you are a programmer, then the development environment should be quite interesting and the XORCL language will be a challenge. For non-programmers E-Or promises to be a route to creating your own profiles when the user interface is improved and simplified. X-Or is definitely a complex and comprehensive generic editor/librarian, and so E-Or is necessarily hard to come to terms with, but the results would seem to make the effort worthwhile.

OPCODE MIDI SYSTEM (OMS)

The Opcode MIDI System (OMS) is the key element in their MIDI environment. It deals with the maintenance of the model which is used to hold the details of the MIDI system. It displays a graphical representation of the current setup, including individual devices, patchbays, MIDI ports and their interconnections. Further details, like MIDI channels and synchronisation capability, are shown in pop-up dialogue boxes. Once a model, or 'studio' in OMS-speak, has been defined, any OMS-compatible program can use the model to configure itself. Checking that a connection is OK is made easier by OMS verbally confirming if MIDI has been received — yes, it talks to you. Score another point for the Mac's built-in sound functions. OMS can be used with or instead of the Apple MIDI Manager, although it is especially useful in the less powerful Macs.

Galaxy is Opcode's generic librarian, and it is available with or without the editor functions — the version with editors is called, naturally enough, Galaxy Plus Editors. As with X-Or, Galaxy can be used to completely automate the process of collecting or distributing SysEx dumps, and it makes no concessions to manual patchbays (probably a very good idea). Bundles of profiles not only allow you to take snapshots of a complete system, but also allow you to 'publish' the names so that they can be used in other programs (the Vision sequencer, for example).

Galaxy has a special scripting language which has been influenced by HyperTalk, the programming language used in HyperCard. PatchTalk is probably the closest to normal English that you will find in a programming language, although it is limited to the librarian functions only, unlike X-OR's programming language. However, this restriction also makes it very easy to learn PatchTalk, since it is not complicated by all the problems of graphics sliders, buttons and pop-up boxes. Instead PatchTalk is all about the nitty-gritty of getting SysEx from a MIDI device and back again.

Although the structure of PatchTalk looks like conventional programming, you only have to look at the actual language used to see that this is no ordinary techno-speakers jargon. Instead of something like 'x = x+4' which looks like some weird nonsense maths, you get 'put x + 4 into x', which almost begins to make some sense if you can think of x as some sort of container for numbers. Adding 4 to a number is an interesting start, but PatchTalk can also deal with abstract concepts like True and False. How? Well, True is something which is always true, like 1=1, whilst False has to be always wrong, like 1=0. Using simple ideas like this coupled with logic lets you achieve control without too much hassle.

I think we need an example at this point. The Yamaha RY30 Rhythm Programmer (drum machine to you and me) is not supported in the current set of Galaxy profiles, so I set about writing one. First off, I needed to store the SysEx dumps for the drum voices from the RY30, and this was a single liner:

receive 126 into patch

What this means is 'receive 126 bytes from the RY30, and store them in something called patch'. Tying up the Mac forever like this whilst it waits for an RY30 dump is probably a bad idea, so we need some sort of timeout:

receive 126 into patch timeout after 1 second

This waits for a dump, and if it doesn't get one within one second, it will timeout and stop waiting. In ordinary english you might have expected some sort of punctuation between 'patch' and 'timeout', but then PatchTalk is really designed for computers to understand, and we humans have to make some sacrifices. Manually triggering the transmission of a SysEx dump isn't my idea of fun, however, so we need to generate a dump request message and send that. Sending uses another obvious command word:

send RYheader RYstring RYblankDPNum $0 $F7

This line obviously sends four blocks of bytes, then $00, and $F7 to finish. Putting the values into those blocks is just a matter of a few lines of 'put's. And that's it — the program is written:

--initialise
put empty into temp
put (1=0) into False
put (1=1) into True

--check for edit buffer
if UseEditBuffer = False then
put DevicePatchNum into DPNum
else
put 0 into DPNum
endif

--assemble sysex header components
put $F0 $43 $2:DeviceID S7A Into RYheader
put "LM 0017 " into RYstring
put $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 into RYblank

--assemble sysex single voice dump request
send RYheader RYstring RYblank DPNum $0 $F7

--receive dump from RY30
receive 126 into patch timeout after 1 second

--view variables

Obviously, there are a few extra tweaks in the above program. The initial values of a few useful variables are set first. Checking if the EditBuffer is used makes use of the definition of False in the initialise section (two '-'s turn the rest of that line into a comment) by using an 'If... Then, Else' structure. The 'view variables' line which is commented out is used for debugging, and allows you to display all the current values of the variables in a dialogue box — you just edit out the two '-'s and the comment turns into a real command. This is a useful technique for debugging PatchTalk programs. You write the program with lots of checks built in, and then comment them out as the testing proceeds.

Transmitting the voice back to the RY30 involves using the 'send' command word again:

send patch

For rather more of a challenge, and to show some of the power that PatchTalk provides, we can look at extracting the voice name of the drum sound so we can use it within Galaxy itself without any need to type it in by hand. Unfortunately the RY30 'encrypts' the voice name with an unusual double-layered ASCII coding scheme. For example a capital 'K', which would normally be represented as $4B in ASCII, would be represented in the RY30 SysEx dump as the ASCII characters for 4 and for B ($34, $42). Whilst writing a script to correct this requires some quirky tweaks because of the limited function set available in PatchTalk, it can be done:

--initialize
Put "" into DisplayPatchName
put 0 into z

--do each pair of nibbles separately
repeat
put DevicePatchName[z] into a
put DevicePatchName[z+1] into b
if (b >= $41) then
put (b+10-$41) into b
endif
put a:b into c
put c after DisplayPatchName[0]
put z+2 into z
until z >= 15

--view variables

The important thing to notice here is not what the program is doing, or even how it does it. Just note that it is possible — and knowing that should give you considerable confidence in the ability of PatchTalk to be able to cope with most (if not all) the SysEx requirements of your system for some time to come.

With both XORCL and PatchTalk, the most important thing to notice is that they are not really bounded by what they can't do — the limits seem instead to be set by what the manufacturers have time to create. Many of the supplied profiles have been sent in by users too, which shows that it's quite possible to roll your own, and that it is a good idea to share your creations. This effectively expands the potential number of people involved in development of new profiles; if the manufacturer kept the development system to themselves then they would be the only ones working on new profiles. Opening up interfaces like this is definitely one of the major features which differentiates 'professional' software from consumer 'toys'.

CONCLUSION

Both MIDI environments described here have their advantages and disadvantages. They support different sets of devices in different ways, and the Opcode software only runs on the Apple Macintosh at the moment. XORCL is hard to program but can be used for librarian and editing functions, whilst PatchTalk is easier to program but only supports librarian functions. OMS is probably a more complete and detailed model of a MIDI system, especially when using 'virtual' instruments. Both systems allow the user to customise the environment to suit their personal setup, and the programming capabilities mean that every user is a potential developer of additional profiles.

The important point here is the commonality between the two, not their differences. Both provide a comprehensive MIDI environment which turns a collection of bits of MIDI equipment into something much more useful — an integrated studio for creating music. This has several side-effects apart from the obvious one of enhanced ease-of-use. Better working speed and rapid access to previous setups can improve your efficiency, whilst freeing you to concentrate on being creative.

FINAL THOUGHTS

When I cited in last month's article a piano as an example of an integrated music production system, you may have wondered about what happens if you open up a piano and look inside. Although it looks like a neat and tidy wooden box from the outside, inside there is a complex system of tensioned wires, levers, hammers and pivots. In a MIDI environment, the equipment may physically be connected together with lots of cables, but the representation on the screen is the abstracted equivalent of the outside of the piano: neat, uncluttered and musical.

If this concept sounds too far removed from a real MIDI system, then consider how you cope with a multi-timbral synthesizer — do you think of it as one box which makes lots of different sounds, or do you visualise it as lots of separate synthesizers. Similarly, look at how sequencer programs themselves are often made up of many separate parts; you might have a basic track recorder, an arranging page, a MIDI real-time control page, synth editing etc, all within the one unified whole instead of lots of separate programs. So the basic ideas are already beginning to enter into common usage. The concept of abstraction and 'virtual' instrumentation promises to be the theme of the remainder of this century and beyond.

Further information

Dr. T's: Zone Distribution, (Contact Details).

Opcode: MCMXCIX, (Contact Details).