Magazine Archive

Home -> Magazines -> Issues -> Articles in this issue -> View

The Integration Game (Part 2)

Improving Your MIDI Environment

Martin Russ concludes his discussion of MIDI environments with an in-depth look at how to create your own profiles in X-Or and Galaxy.



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:

TXBYTE 00B0H
TXBYTE 0007H
TXBYTE *ParamAdr

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:

EQU TEMP#3 176
ADD TEMP#3 ParamNo
TXBYTE TEMP#3
TXBYTE 0007H
TXBYTE *ParamAdr

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).

TERMINOLOGY

Rather than use conflicting terminology when talking about two different products — Galaxy and X-Or — I have decided to settle on the following terms:

A 'bundle' is a collection of profiles which define a snapshot of the complete MIDI system. (Dr. T call these Performances)

'Profiles' are files which configure a librarian/editor program for a specific device. (Opcode call these Modules)

A 'patch' is a file containing the information about a specific sound or patchbay setting.

A 'bank' is a collection of patches.


OPCODE GALAXY SUPPORT

As of version 1.2.1 (March 1992), Galaxy supported at least the following MIDI devices:

ART: MIDIverb III

ALESIS: Quadraverb

CASIO: CZ1, CZ101, CZ1000, CZ3000, VZ1, VZ10M, VZ8M, RZ1

DMC: MX8 Patchbay

EMU: Proteus 1, Proteus XR, Proteus 2

ENSONIQ: VFX, VFX-SD, SQ1, SQ80, ESQ1, ESQM, SQ1+, SQR, SQ2, SQR+

EVENTIDE: H3000

FENDER: Chroma, Polaris

KAT: DrumKat

JL Cooper: MSB16/20, MSB+ Mk2, FaderMaster, Synapse

KAWAI: K1, K1R, K1m, K3, K3m, K4, K4r, K5, KSm, XD5

KORG: M1, M1R, M3R, M1ex, M1Rex, T1, T2, T3, DW6000, DW8000, EX8000, SDD3300, Poly 800, EX800, Wavestation

KURZWEIL K1000 (SE, SE extended, SEII, SEII extended, PX, HX, SX, GX, PX+, AX+), K1200 (Pro1, Pro2, Pro3)

LEXICON: LXP1, LXP5, PCM70

LINN: LinnDrum

OBERHEIM: Matrix 6/6R, Matrix 1000, Matrix 12, OB8, Xpander

PEAVEY: DPM3

RANE: MPE14, MPE28, MPE47

ROLAND: D70, JD800, PAD80, CM32L, CM32P, CM64, D5, D10, D20, D50, D550, D110, DEP5, JX8P, MT32, GM70, GP16, Juno 106, R8, R8M, Alpha Juno 1, Alpha Juno 2, MKS80, MKS70, MKS50, U220, S330, Super Jupiter

SEQUENTIAL: Prophet 5, Prophet VS, SixTrack, Split Eight

WALDORF: Microwave

YAMAHA: SY99, SY55, TG33, SY77, TG77, DX100, FB01, DX1, DX5, DX7, DX7E!, DX7E!v2, DX7S, DX7II, DX27, DX27S, DX21, KX88, KX76, TX802, TX7, TF1, TX816, TX81Z, SPX90, SPX90II, PMC1, DX11

ZOOM: 9010, 9030

GENERIC BULK

SAMPLE NAMES

In addition, OMS also recognises devices from Akai, Buchla, Digidesign, Lake Butler and Uptown.

Some of the above are only supported for librarian use or limited editing. Further details can be obtained from the distributors. Remember that printed profile lists are always out of date!


OTHER ENVIRONMENTS

C-Lab's recently announced Notator Logic sequencer will be available imminently for the Macintosh, although an ST version is promised soon. It takes many of the ideas in OMS and X-Or, but integrates them into a complete object-oriented music environment where you control 'views' onto the music, and where much of the MIDI complexity is replaced by a 'virtual' representation on the screen. For ST users, C-Lab's PolyFrame generic editor and its single editor version, MonoFrame, enable editing and librarian functions within the Notator environment.

Steinberg's Cubase offers integration with the Synthworks editors using M.ROS on the ST, and again has many of the editor/librarian functions tied into the sequencer itself. On the Mac, Cubase offers virtually the same environment, but without the editors at present.

Zadok's Uniman seems to be a generic editor and librarian rather than a full-blown environment.

Keynote's Chameleon is a superb generic librarian with a simple but powerful scripting language. A generic editor extension to Chameleon is under development.


DR. T'S X-OR SUPPORT

As of the 27th March 1992 (the most recent profile listing available), X-Or supported at least the following MIDI devices:

AKAI: MB-76

ART: Multiverb, Multiverb II

ALESIS: HR16, HR16B, Quadraverb

CASIO: CZ1, CZ101, CZ1000, VZ1*, VZ10M*, VZ8M

DMC: MX8 Patchbay

DIGITECH: DSP128, DSP128+

EMU: Proteus 1, Proteus 1/XR, Proteus 2, Proteus 1 with Orchestral Expansion, Proteus 1/XR with Orchestral Expansion , Proteus 1 with Protologic, Proteus 1/XR with Protologic, Master Performance System

ENSONIQ: VFX, VFX-SD, SQ1, SQ80, ESQ1, ESQM, Mirage with Soundprocess, SQ1 Plus, SQR

JL COOPER: MSB+ Mk2

KAWAI: K1, K1R, K3, K4, K5*

KMX: MIDI Central 15 x 16, 8 x 8

KORG: M1, M1R, M3R, M1ex, M1Rex, T1, T2, T3, DW6000, DW8000, DSS1, EX8000, DS8, DVP1, Z3, Poly 6, 707, P3, Symphony, Wavestation, Wavestation EX, Wavestation AD

LEXICON: LXP1, LXP5, LXP15, PCM70

OBERHEIM: Matrix 6/6R, Matrix 1000, Xpander*

PEAVEY: DPM-V3

RANE: MPE14, MPE28, MPE47

ROLAND: D70, JD800, PAD80, CM32L, CM32P, CM64, D10, D20, D50, D550, D110, DEP5, JX8P, MT32, GM70, GR50, GP8, Juno 106, R8, R8M, Alpha Juno 1, MKS80, MKS70, MKS20, U20, U220, U110

SEQUENTIAL: Prophet 5, Prophet 600, Max*, Drumtraks*, SixTrak

WALDORF: Microwave

YAMAHA: SY55, TG55, SY77, TG77, DX100, FB01, DX7, DX7II, V50, KX88, KX76, TX802, TX7, TF1, TX816, TX81Z, SPX90, SPX90II, DMP7*, RX11

360 SYSTEMS: 8x8 MIDI Patcher

GENERIC

PROGRAM CHANGE

*Librarian or limited editing only.


HOW MANY PROFILES?

The number of instruments supported by a generic librarian/editor or environment often changes on a monthly basis as the manufacturer releases new profiles. Often users also create their own profiles and send them to the manufacturer, and these can be useful for essential but not-so-popular instruments. The quality of user supplied profiles varies from excellent to merely functional — although from SOS readers I'd expect only the former. You can probably be certain that more profiles are always under development.

Because of the number and size of the files, some profiles are supplied in a compressed format on disk, and need decompressing before they can be used. This has the advantage that over 1MB of profiles can be stored on one 800K disk. Some profiles give useful information about the bug fixes, peculiarities of the instruments, and hints on converting files to other instruments with similar file structures, which can be useful even if you don't use the profile. Because of the complexity (and limitations) of particular instruments, some profiles provide librarian functions only, or only limited editing facilities — the Kawai K5 is a typical example of a complex device which has mostly librarian support. Some devices can be used even when the odds seem against it — the Cheetah MS6 does not have SysEx editing commands, and so it is virtually impossible to create an editor for it, but it can be supported by a generic bulk profile for librarian functions.


Also featuring gear in this article



Previous Article in this issue

Akai S1100EX

Next article in this issue

Alesis ADAT


Sound On Sound - Copyright: SOS Publications Ltd.
The contents of this magazine are re-published here with the kind permission of SOS Publications Ltd.

 

Sound On Sound - Sep 1992

Topic:

MIDI


Series:

The Integration Game

Part 1 | Part 2 (Viewing)


Gear in this article:

Software: Editor/Librarian > Dr. T > X-OR

Software: Editor/Librarian > Opcode > Galaxy


Gear Tags:

Atari ST Platform

Feature by Martin Russ

Previous article in this issue:

> Akai S1100EX

Next article in this issue:

> Alesis ADAT


Help Support The Things You Love

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!

Donations for June 2021
Issues donated this month: 0

New issues that have been donated or scanned for us this month.

Funds donated this month: £36.00

All donations and support are gratefully appreciated - thank you.

If you're enjoying the site, please consider supporting me to help build this archive...

...with a one time Donation, or a recurring Donation of just £2 a month. It really helps - thank you!
muzines_logo_02

Small Print

Terms of usePrivacy