The Integration Game (Part 1)
Improving your MIDI Environment
In part one of this two-part article, Martin Russ looks at how the right software can make the difference between a studio full of lonely synths, samplers and other gadgets, and a powerful integrated setup.
MIDI can hardly be accused of standing still. The limits of what hardware can be controlled by MIDI are expanding all the time, with tape recorders and lighting equipment among the more recent additions to the fold. But the scope of MIDI expands as well, from the deliberately simplified structure of General MIDI, through to the large LAN-based MIDI networks in large studios. (A LAN — Local Area Network — is a means of sharing data between several computers and peripherals.) Actually, the fundamental ideas behind both General MIDI and the latest ideas for using big MIDI systems are very similar — they both aim to make using MIDI easier and less confusing. Rather than just using MIDI as a small component, it is possible to create a large and complete MIDI environment for producing sounds and music.
Total environments aren't new. A player piano, for example, is a good example of a self-contained music generating device. General MIDI has the same sort of self-sufficiency built in — armed with a GM sound module, some MIDI Files and a suitable MIDI File player, you can have a complete musical performance setup. A closed system like a player piano, or a GM module and player, has the advantage that you don't need any major add-ons to play the music — and you know that you will get repeatable results. This easy duplication of a 'pre-recorded' musical performance using piano rolls or MIDI Files only really works when you have detailed information about the whole of the system.
One of the major problems with MIDI has always been that its flexibility also made it difficult to use. With a couple of synths, a drum machine and a sequencer, it is surprisingly easy to produce a MIDI File which is almost impossible to play back on any other similar setup — and when you do succeed, the instrumentation and drums are certain to be nothing like the original. The task of describing exactly what you have used (and how) is difficult, whilst trying to recreate it some months later can be almost impossible. If only there was some way of tying any MIDI system together into something resembling a larger version of General MIDI.
Manufacturers don't call them environments. Organisers, Orchestrators, Integrators and many other names struggle to convey the basic idea: something which lets you use a big MIDI system with the same sort of ease as if it was just a simple 'fun' keyboard. In fact, the theme of bringing things together into a unified whole is already familiar from the workstation concept which has dominated the synthesizer world for the last couple of years. Interestingly, a similar idea is beginning to make its early appearances in the software world as well — in the past, editors, sequencers and programming languages have all been separate programs, with the user acting as the connection between them; we might draw an analogy with a setup consisting of a separate master keyboard, hardware sequencer, expander, and drum machine. All this hardware could be replaced by a suitable workstation, and the software equivalent can be called an 'environment', or even a 'virtual' workstation; you'll be hearing a lot more about them in the next few years.
There are several basic components at the heart of an integrated MIDI environment, although there are all sorts of extra goodies too. The bare necessities are: some serious MIDI hardware, probably several synths and a sampler; a MIDI patchbay; a multi-port MIDI interface; a computer; software to tie it all together.
Probably the most important hardware part of an environment is a MIDI patchbay, or switching matrix. This serves two purposes Firstly, it controls the connections between the different parts of the MIDI system but, more importantly in this case, it enables the isolation of specific parts for special purposes, like dealing with System Exclusive communications, to just one device. Choosing a patchbay that is large enough can be quite a problem. There are some simple 2x6 units (two MIDI Ins and six MIDI Outs), but these restrict you to only two sources of data, and so are really only suited to very small MIDI systems. Patchbays with an 8 x 8 configuration can cope with most needs, whilst a 15 x 15 patchbay can cope with all but the largest arrays of equipment.
Perhaps the most essential feature of a MIDI patchbay in this context is the ability to be controlled via MIDI; by making the patchbay controllable, it can become part of the environment itself. Usually program changes are used to select pre-programmed settings for the patchbay connections. Using a manual patchbay prevents the computer from controlling the patchbay remotely, and means that the user has to change the switch settings when the computer demands. Being a slave to the computer is not my idea of fun. (Madonna in a bath of baby oil? Now you're talking fun...).
A multi-port MIDI interface is quickly becoming a necessity rather than a luxury. With most new MIDI equipment offering 16-part multi-timbrality and at least 16-note polyphony (if not more), the days when the basic 16 MIDI channels seemed generous are long gone. Adding an extra 16 channels is easily accomplished on most computers by connecting another MIDI interface to the second serial port. But a major innovation was introduced a couple of years ago by Mark Of The Unicorn (MOTU), best known for their Mac software.
MOTU's MIDI Time Piece is often dismissed as just a way of syncing a Macintosh sequencer to SMPTE timecode, but it also contains eight separate MIDI Outs. These are not to be confused with the eight Thrus you might produce from a single Out, where there are still only 16 channels available — the MIDI Time Piece offers eight sets of 16 channels, which is equivalent to providing 128 individual MIDI channels. This means that you can have eight different 16-part multi-timbral devices connected to it, and still be able to assign individual channels to specific devices.
More recently, Opcode's Studio 5 has taken the idea further, with 15 separate MIDI Outputs and thus 240 MIDI channel capability, which is surely enough to stretch even the most capable Mac to the limits of its processing power. Opcode's Studio 5 has on-board processing power too, which allows the connected MIDI devices to be treated in some unusual ways — you can stack instruments, split or layer them, and even do the sort of velocity mixing normally found in samplers. Using 'virtual' instruments like this can make using composite sounds much easier than trying to cope with two different channels all the time. Putting the processing into the interface relieves the sequencer from many of the more mundane tasks and leaves it free to cope with the sequencing.
On the ST, there is a wide range of options for providing an extra MIDI port, with prices from about £30 upwards. An extra set of 16 channels can be fairly easily obtained via the ST's serial port, and the more you pay for a serial port add-on the more you get in terms of sync options, extra triggers, audio input and output — in fact you can have almost anything, other than more than a total of 32 MIDI channels. MIDI Interfaces with more than two ports have taken longer to appear on the Atari ST, but Hybrid Arts' recently announced MIDIplexer provides extra ports via the Atari's DMA port, and more units are under development from other manufacturers. On a PC or Amiga, re-using extra serial ports is probably the way forward to more than one MIDI output.
Whatever else goes into your MIDI environment, it's totally useless without MIDI instruments: synths, samplers, and drum machines. There are several approaches to providing 'comprehensive' sound creation facilities: the 'true' synthesist is likely to go for a mix of analogue and digital technology, whilst those with an ear for emulation will throw in a sampler too. The modern 'sound hacker' is much more likely to have an array of samplers with large hard disks and perhaps even optical drives containing a sample collection which is probably the result of several years avid magpie-like collecting. You might even have 'classic' all-analogue synthesizers, which lack memories and tuning stability (easy enough to control via a MIDI-to-CV convertor, but not quite so easy to integrate into a MIDI environment), or plug-in digital audio/synth boards for your computer.
The computer is arguably less important than the software that will run on it. Speed and processing power are of primary importance for a large system, since the demands of multi-port MIDI interfaces can tax even a powerful computer. In much the same way that most of the current synthesizers look, feel and sound very similar, so computers seem to get more like one another as their power increases. The future seems to hold the promise of computer platforms with wide compatibility.
The software is the essential element of the whole environment, bringing together all the other elements into a composite whole. This software must have several distinct parts. Firstly, some sort of internal model of the physical MIDI system is needed, so that you can avoid all the complication of trying to keep track of which device is on which channel on which port. Opcode's Opcode MIDI System (OMS) and C-Lab's Notator Logic provide two excellent examples of an on-screen representation of the real world which ensure that, once primed with essential information on what is connected to what, you can almost forget the actual hardware and deal just with the computer's view of it.
Hooking into this 'world model' is the second software component: a generic librarian. Using the map of devices and connections, the librarian can request and receive system exclusive dumps from individual pieces of equipment, and so store a complete snapshot of the whole system. This is why the automated patchbay function is so essential a part of the hardware — the librarian and patchbay become two parts of the same SysEx 'camera'. The librarian can of course use the information about what is connected to choose the Profiles that it needs to use, which removes another task from the owner. If the computer knows that you have an Okikoki YT234, then there should be no need for you to have to set up the librarian to deal with it. You set up the model of your MIDI system first, and after that all the rest of the software goes to the model and automatically takes the information it needs from that, not from you.
Large MIDI systems are relatively static, which means that you don't have to update the model held by the environment too often, but even changing systems can be catered for by careful design in the first place. My own environment (see screen shot) has a master keyboard and expander with the eponymous name of 'Review' pre-defined, so that testing a new device for review is merely a matter of connecting the MIDI and audio leads.
If the focus of the environment's software is the librarian, then the engine room is the sequencer. Again, this will derive information about the real-world implementation of the MIDI system from the model, and this means that a lot of the fiddliness of naming can be avoided. That killer bassline can now be produced by an 'instrument' called 'Bass', instead of by whatever happens to be connected to Port A, Channel 12, Patch A54.
Splitting up the functionality of the software in this way can hide an important aspect of the way that a MIDI environment works, because it is a complete system which works as one large entity, rather than several smaller ones. For example, you can completely avoid the traditional problems associated with trying to find a particular sound that was in memory location 23 when you originally worked on a sequence, since the environment will store the sequence data along with the sounds that were used to play it. This is especially important when an editor is used to tweak the sounds to suit a particular song — you can save those changes along with the song itself, instead of trying to sift through memory cards or disks of patches. Of course, the editor program's task is made easier since it can find out which devices you have in the system, and how they are connected.
Today's environments begin to run out of steam when faced with the memory demands of sampler-based systems, but even here they can act as a database of what was used, even if the user has to re-load the samples from the optical or hard disks. The rapid development of optical drives and SCSI interfaces on hi-tech musical equipment promises that this may soon cease to be a problem.
The most obvious 'extra' that I have left out is provision for scoring or notation. With the widening acceptance of MIDI Files as a way of exchanging MIDI sequences, it is relatively easy to take almost any sequencer and almost any notation program and produce high quality scores. Some environments (notably Notator Logic and Cubase) include some notation facilities, although these are actually intended for editing rather than serious scoring purposes, and these can be useful if you prefer to work directly in music notation, but you will still need a more 'publishing' oriented program for full scores. Another possible extra is a sample editor, since current generic editors are restricted to synthesizer editing, and so a dedicated program like Sound Designer II or Avalon can be used.
With so many products to choose from, it is probably better to look at two systems in depth, so next month I'll conclude by looking long and hard at Opcode's OMS (with Vision and Galaxy), and Dr. T's X-Or. The former combination offers its comprehensive and powerful features on the Mac only, whilst X-Or can run on the ST, Amiga, PC, and Macintosh. In both cases I'll demonstrate how to actually customise the environment to work with your equipment (even if it's not supported by standard profiles), and I'll also provide a brief guide to some other systems.
Feature by Martin Russ
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!