Multi‑port MIDI interface/patchbays can seem like an expensive indulgence for the average studio. But, as Martin Russ explains in the concluding part of this two‑part feature, they can really help you to get the best use from the MIDI gear you already own. This is the last article in a two‑part series.
Last month, I explained just some of the ways in which you could use a multi‑port MIDI interface, like the Opcode Studio 5LX, to make working with MIDI equipment easier. This month, I'll describe yet more applications for these useful devices.
I currently use a Yamaha SY99 as my main master keyboard, but sometimes I want to change it to something else — like another keyboard with different facilities, or a wind controller. To achieve this painlessly, I have my Studio 5LX set up so that I need only make one change, and I don't even need to touch my patches! This trick is achieved by using a Virtual Controller, which is a neat way of mapping real MIDI sources to ones which exist only inside the software in the Studio 5LX and the Macintosh. Notice the two other greyed‑out sources to 'Master No Clock' ? They are 'reminders' for the other sources I have available for my master keyboard. If I want to use a Wind Controller instead of the SY99, I go to the Virtual Controllers window and select the WT11. Without using a Virtual Controller, I would instead have to go to each patch that used the SY99 as the master keyboard and edit it, which could be a long and very tedious task. As it is, I have a very quick and simple method of selecting sources for the master keyboard. Not content with just one Virtual Controller, I also have several different 'versions' of my SY99. The basic one produces no MIDI Clocks, so is very useful when I don't want to clog up the MIDI bandwidth with unnecessary timing information (I can't be bothered to turn it off on the SY99 — it takes rather too many button‑presses). By replacing my use of the SY99 output with a Virtual Controller, I can have an SY99 master keyboard that does not produce clocks — and I've only got one thing (the filter in the Virtual Controller patch) to change if I need to change the allowed MIDI messages — like Active Sensing, or extra Controllers, for example.
Another 'virtual' version of the SY99 only produces MIDI Clocks and related messages (Start, Stop, and so on). The filter block removes everything else. Once again, because all the filtering is in the Virtual Controller instead of the individual patches, you only need to edit this one filter to change the filtering for all the patches which use this controller.
But one of the 'other' versions of the SY99 produces just a MIDI clock, and this patch is called 'Master MIDI Clock'. Although the clocks usually come from my SY99 (which acts as the master keyboard most of the time), I could change the source of the clocks merely by editing this one patch. Of course, when I use the WT11 wind controller as the 'master keyboard', I may still need to have the SY99 as the source of the timing, since the WT11 obviously can't do this — and in this case I would change only the source for my 'Master No Clock' Virtual Instrument. If I was changing real MIDI cables at this point, I would have to wire up the WT11 as the 'keyboard' input, and somehow merge the SY99 MIDI clocks with it. I'd have to rewire the cables without getting lost and having to start all over again, whereas with the MIDI patchbay/interface and a few Virtual Controllers, it takes just a couple of double‑clicks to completely alter the MIDI topology of my studio.
Virtual Instruments are also the key to producing simple patches like the one I explained last month, where the master keyboard was connected to all my Emu devices. Without the underlying Virtual Instrument, the patch would have to explicitly connect the master keyboard to all the Emu instruments, and if either the master keyboard changed, or a new Emu instrument was purchased, every patch containing either of these devices would have to be changed.
Master keyboards are a good idea because they let you use a keyboard whose action suits you, but the response of many synth expander modules to velocity is variable enough to cause some problems. This 'velocity curve' problem has afflicted MIDI from the very beginning: the original DX7, for example, did not like to output velocities much above 110. Sophisticated patchbays allow you to sort out this problem either at source or at destination. I have experimented with Virtual Controller keyboards, where the synth module's output is modified to give alternate 'velocity curves', but I find that I prefer to make the changes at the input to the expander modules which have the wrong 'feel': here's how.
Opcode's news‑sheet regularly features patches from people who are using the Studio 5LX to automate complete keyboard rigs for tours, or complex tasks in studios.
The Studio 5LX provides a neat 'input/output' map which shows velocity curves in a graphical form. One useful curve expands velocities from the middle of the velocity range and compresses the extremes, which makes playing some dynamic synth sounds much easier. As I mentioned, velocity curves are best changed at the input to the specific item which requires the change — so my easy‑play 'Piano' velocity curve is often used before piano‑like modules to reduce the amount of pressure which a soft‑fingered player like me has to use!
Tying up a master keyboard as the input to a sequencer is fine until you want to do some accompaniment. Playing on the master keyboard usually results in all the 'Thru'd' instruments playing your melody line, which is often exactly what you don't want. For this occasion, I have a 'Two Keyboard' patch, which leaves the master keyboard alone, but adds a second keyboard for the solo or melody playing.
When performing live, it is possible to extend this idea so that all the MIDI instruments for all the performers are routed through the patchbay — as long as someone stays in sole charge of patchbay patch changes! More creative uses for patchbays which feature processing capabilities are limited only by the available facilities and — as they say — your imagination. For example, it is possible to use multiple keyboard splits inside the Studio 5LX, where groups of notes are assigned to different instruments. Or a Virtual Instrument could provide 'hocketing' — the distribution of notes to different instruments. Although you could set up this sort of patch on the two instruments themselves, it is much easier to do it inside the patchbay, and much faster and easier to edit it.
When I took my Studio 5 to MCMXCIX to have it upgraded to the LX version, I had a chat with a fellow musician who had recently moved from Atari to Macintosh. He commented on the poor resale value of Atari computers, at which point I said that he should keep the Atari, and use it in his MIDI system. He replied that he now had a Mac and did not need the Atari any longer. So I asked him if he'd ever read the June 1993 issue of Sound On Sound...
The Atari Notes column in that issue of SOS advises you not to sell your old Atari, but to use it with whatever you buy to replace it. Your ST/TT/STE is not going to make you very much money when (and if) you can sell it, so why not keep it, and continue using some of the music software?
Although I only have one Atari physically connected to my MIDI system, these are treated as several different 'virtual' Ataris, depending on what tasks the machine is asked to do. The first thing to do when integrating an Atari is define a new device on the Studio 5LX. Since Atari don't normally figure in Macintosh MIDI equipment lists, you simply choose 'Other' for manufacturer, and 'Other' for the model type. I select all the options so that everything gets passed to and from the Atari. Once set up, the way in which the Atari is used depends on the patches in which it appears. Message filtering can help to prevent unexpected problems which can be caused if extra data gets into the rest of the MIDI system from the Atari.
One of the patches that I use the Atari ST with provides 'jittered' MIDI clocks from a small utility program I wrote several years ago: the idea was to humanise sequenced phrases and drum patterns by not always having the same gap between successive MIDI clocks. It works very nicely, and everything else 'syncs' to it, although if you record something while using it, the tempo maps in a sequencer can look a little unusual. Of course this kind of randomisation now comes as standard with most modern sequencer packages, but it serves to illustrate the point — that the Atari still plays a valuable part in my setup.
Another Atari ST patch is optimised for sound editing on my Yamaha FB01, a useful device which is not supported in my favourite editor/librarian software. The patch allows me to use the ST to edit FB01 patches, via MIDI SysEx messages, whilst also merging in the SY99 keyboard so that I can play edited sounds. In this patch, 'Atari SysEx' is connected to a 'device' called FB01, even though in my case the FB01 is not physically connected directly to the Studio 5LX port, but is connected via a Yamaha TG77 FM expander module instead.
Having a graphical display of your patch routings may seem like overkill at first, but it makes the complex possibilities much clearer.
Normally, the only device that you would see in a Source pop‑up menu would be the one which is directly connected to the port — the TG77, in this case. But since it is unlikely that a single TG77 would be able to use all 16 MIDI channels and still have a usable amount of polyphony, you can hang a second device on there and feed it with a different MIDI channel. The FB01 is connected to the Thru port of the TG77 and is set to an unused channel (if the TG77 were set to receive on the same channel as the FB01, any note messages would be played by both the TG77 and the FB01!). Although this is perfectly OK for providing extra polyphony and sounds, it complicates any editing of the FB01 using SysEx messages, since the Out of the FB01 needs to be connected back into the Studio 5LX.
One apparent catch with this setup is that there's no obvious way to name that second device. However, it can be done. You simply use a Virtual Instrument, so that you can give it a meaningful name — like FB01.
Although this approach works fine for sending SysEx and other MIDI information from the Out of the Atari ST to the In of the FB01, it does fail when it comes to connecting the Out of the FB01 to the In of the Atari ST — so I have a little MIDI switch box that swaps between the FB01 and the TG77 output. The effort of switching whenever I edit the FB01 is very minor compared to the cost of an extra Studio 5LX! I have defined a Virtual Controller for the FB01 channel, to remind me that when I'm using the FB01 with SysEx messages, I need to switch to the FB01's MIDI Out port instead of the TG77's. The end result is a device called FB01, which can be used almost as if it was one of the devices connected directly to a port, even though it isn't!
MENU TIP: When naming a virtual object, I place an underline character (a shifted 'minus' key) at the beginning of the name. This is so that when you display a menu, all the virtual objects will be listed together near the bottom of the list. Using the alphabetical sorting of names like this can be very helpful with long lists of equipment, especially if you use lots of virtual Instruments and Controllers.
Another SysEx patch to the Atari ST is used when a 'direct' connection is required between the ST and another device. This time, the SY99 is connected directly to the Atari via the Studio 5LX port; no switching is needed, and I can edit samples on the Atari ST and download them to the SY99's user sample RAM. The Atari ST is just another way of editing the SY99 patch or sample data, and the fact that I use a Mac connected to the same patchbay makes no difference. This really is using computers as musical tools rather than the focus of everything, which can only be good for the music.
Why do I still use the Atari ST for samples? It turns out that acquiring sound patches via SysEx dumps from a BBS or the Internet has one major shortcoming: they're almost always in the wrong format for the generic editor/librarian that you use. In such circumstances, I reach for the excellent Chameleon on the Atari first, because it is very adept at ignoring 'foreign' headers and looking for just the System Exclusive information. After that, I use a home‑written ST MIDI Toolkit utility, which will quite happily squirt complete nonsense as a MIDI SysEx dump if you ask it to. This is another useful way of extracting usable SysEx out of someone else's format. I don't know why every editor/librarian program insists on adding their own header around the basic SysEx information, but they do, and I often need to try and undo it.
Opcode's news‑sheet regularly features patches from people who are using the Studio 5LX to automate complete keyboard rigs for tours, or complex tasks in studios, and more. Having a graphical display of your patch routings may seem like overkill at first, but it makes the complex possibilities much clearer — imagine trying to work out how a Virtual Controller is set up from just a few LEDs!
Although the applications I've featured in this article have used the Opcode Studio 5LX, many of the same techniques are applicable to other multi‑port MIDI interfaces. Opcode's own Studio 4 shares many of the features of the 5LX, and Mark of the Unicorn's MIDI Time Piece also has comprehensive routing and patching capabilities. Whichever MIDI patchbay you have, take another close look at your user manual and start making the most of it. If you don't have a MIDI patchbay at all yet, perhaps you can now see the sense in buying one!
Once I had been using my upgraded Studio 5LX for a while, I noticed that I was getting more 'over‑run' errors than before. These errors occur when there are communication problems between the Macintosh and the Studio 5LX. I quizzed Opcode about this and got several answers, in ascending levels of complexity. Here's some of what they said:
Opcode's Greg Thomas advised checking that 'Local Control' was off on my master keyboard, and looking at the routings in Studio 5 patches for feedback loops. He also suggested a 'hard reset': hold down both the black front‑panel buttons, and power up the Studio 5LX. If you use a PowerBook or PowerMac, you need to connect to just the Modem port, not the Printer port. The Mac IIfx and Quadra 950 models might also need the 'Studio 5LX‑to‑Mac' speed slowing down.
Jarrell Irvin, the author of the Studio 5LX firmware, also responded, with more detail on the slowing‑down theme. Apparently, the enhancements to the LX improve its MIDI throughput and accuracy of the transmission delay calculations. In other words, the new ROMs are 'more efficient' — which can mean that you need to slow down the 'Studio 5LX‑to‑Mac' speed so that the Mac can respond properly. Jarrell pointed out that even SysEx information only produces one set of MIDI data, and that where you need the speed is in the 'Mac‑to‑Studio 5LX' direction — which is normally eight sets of MIDI data.
Opcode's fast response was thorough and helpful, and simply slightly reducing speed, as suggested, solved my problem — no more 'over‑run' error messages.
The problem with drum sounds is that they are often available as part of the same multitimbral MIDI expander as the instrumental sounds. Coping with this can be confusing, as can trying to remember which channel the percussion is on. Roland and GM‑compatible equipment may use MIDI Channel 10 as standard for drums and percussion, but some other manufacturers use channel 16, and some use any channel they like!
I often use a Virtual Instrument for drum sounds, and I have all my drum sounds mapped to note numbers which remain the same, wherever possible. Depending on how much control I need over the drum sounds, I either assign all the drums to the same channel, or use separate channels for each drum sound source. If you put all your drum sound sources on the same channel, they become a single destination and, of course, they'll all play at the same time. When I do this, I can use my mixer to select the mix of drums I want .
For multiple channels of drums, I can clone my sequencer drum track and then send the drum notes separately to all the sources of drum sounds I have. The drum hits are still made up from several separate drum sounds, but I can then delete the ones I don't like on an 'individual note event in a track' basis... This gives a dynamic mix of drum sounds which suits my ad‑hoc working methods beautifully. Using a 'subtractive' method like this avoids the complication of having hundreds of separate defined drum sounds made from combinations of individual instruments.
These slightly unorthodox methods enable me to add and take away percussion sounds quickly, and mean that all my drum patterns use the same note numbers. The mapping I use is based on GM drums, but with differences due to the way in which I've gradually built up my percussion sound sources over the years.