Magazine Archive

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

Practically MIDI (Part 7)

Article from Sound On Sound, March 1988

Martin Russ dons his lab coat and deerstalker to investigate some of the unwanted features of MIDI.


What you don't want in your MIDI system. Martin Russ investigates some unwanted features of MIDI.

Everyone tells you what you want these days, so instead here's a rundown of what you don't want! Think of this as a user's guide to the difficult questions to ask before parting with your money.

I have identified six areas of concern. Some may be familiar to you, others may seem obvious, but hopefully there will be something of interest to even the most MIDI-hardened individual.

1. Loops



The 'Art of Looping' is really only relevant to sampling. In a MIDI network, the last thing you want is a loop. So what is a loop in MIDI terms? Look closely at Figure 1.

Figure 1.


As you can see, the MIDI Thru from the Tape Sync box is connected to the MIDI In of the Sequencer, whose Thru is connected to the MIDI In of the Tape Sync box. Any data you place in this set-up just zips around from the Tape Sync box to the Sequencer, since a Thru merely repeats any data placed at the In. Why would we want to do this? We wouldn't, but it can happen ever so easily, especially when functions are hidden. Look at Figure 2.

Figure 2.


Believe it or not, but just such an arrangement is commonly used where you want to synchronise sequences to tape.

The trap is that in many sequencers there is a 'feature' that makes the MIDI Out act as a Thru for any data appearing at the input. That's fine on its own - but, unluckily for us, the Tape Sync box also does the same. Yep, when you have the Tape Sync box set to MIDI In mode its Outs act as Thru connectors as well. In the case we have here, this unfortunately makes things go very wrong, very quickly. So, although you have been careful and connected Outs to Ins, the 'hidden' Thrus have created a loop - and that's when everything goes astray.

Imagine that we have just connected everything up and enter 'play' mode. Timing comes off the tape and is converted to MIDI clocks which are sent from the Tape Sync box's Out to the Sequencer. The Sequencer uses these clocks to derive its timing and it starts to play back the sequence of notes. The MIDI messages for these notes are merged with the timing information from the Tape Sync box (remember that the Sequencer has this wonderful 'Thru' feature) and arrives back at the Tape Sync box input. We are using the Outs of this box as Thrus and so the sequence is sent to the Expanders and we then hear the sequence. Or rather we hear some of the sequence. Remember that we are driving the Sequencer from one of the Outs of the Tape Sync - and so the Thru action of the Tape Sync box puts the data we have just sent out back at the Sequencer input. Bingo - a loop!

What happens? Well, the data travelling around the loop quickly fills the available capacity of the MIDI data stream and we start to overwrite messages. As soon as this happens the timing starts to go astray and we begin to get notes which sustain. Eventually, a really unusual MIDI code will upset one of the Expanders or the Sequencer and everything hits the dirt!

The solution to the problem is very easy - do not use the Tape Sync box as a Thru! Using a separate MIDI Thru box prevents a loop from ever occurring. Figure 3 shows one possible way that you could do it.

Figure 3.


2. Long Chains of Thrus



That mention of Thru connections brings me nicely to the next potential area of trouble. You are always told not to use long chains of Thrus when linking many MIDI instruments and instead to use a 'star' formation from a Thru box (see SOS Sept '86 for more details on star networks). The reason given is always that this daisy-chaining creates problems with MIDI delays. Wrong! In actuality, the delay involved in echoing the In data at the Thru is so negligible that you would need chains of hundreds of Thrus to get any noticeable delays! The real reason why it is not recommended practice to link too many Thrus is more subtle, but deadly nevertheless.

The opto-isolators used in MIDI Ins are part of the problem. It takes some time for the LED to turn on and off. Worse still, driving MIDI cables needs time to get the current moving as it turns on and off. The combination of these two effects is that the time taken for the MIDI data to change from an On state to an Off state begins to increase as you link more opto-isolators and cable together. Eventually, it takes so long to make the transition that it causes a 'hiccup' and generates a false transition. Once this occurs, you have then generated a bit of digital data that was never originally sent. This upsets all the following MIDI equipment and causes all sorts of problems. Figure 4 shows the horrors that the data is subjected to.

Figure 4.


The solution? Use a MIDI star network. Connect your master keyboard into a Thru box and connect your expanders, drum machine, etc, together with direct connections from the Thru box. It is as simple as that! (See Figure 5.)

Figure 5.


3. Y leads



I have mentioned this problem before, but it bears repeating. Audio people are used to using Y leads to split an audio signal and send it to two places. Naturally, it seems okay to do the same with MIDI leads. In fact, some Thrus are created exactly in this fashion. The problem is that MIDI sends its data in the form of current, not voltage. Splitting the MIDI cable with a Y lead halves the current in each cable. For ordinary audio this would just mean a drop in level, but for MIDI it means that the receiving In can't make a sensible decision. Figure 4 shows what is happening. The result of all this indecision is complete chaos after the Y - worse still, it may be intermittent and some equipment may be insensitive enough not to mind, while other pieces will refuse to work at all. So, forget about using Y leads where MIDI is concerned.

4. Battery-powered Thru boxes



Thru boxes again! Just a quickie this time - beware of using battery-powered Thru boxes in permanent MIDI installations, eg. in studios. It is much better to use mains eliminators, because batteries will inevitably fail at the wrong moment. As batteries run out of steam they can also corrupt MIDI data quite nicely, which can seriously upset System Exclusive bulk dumps, etc.

5. Self-powered Thru boxes



You don't see these very often, but I have come across them. They take their power from the MIDI Out that is driving them. The idea seems simple enough - you use the voltage available at the Out socket to produce a Thru box which needs no batteries and no mains eliminator. The problem is that the voltage available at the Out varies with the current drawn through it, since it is not designed to supply Thru boxes. So, although these Thrus work okay most of the time, power supply variations and chip tolerances inside the Thru box can occasionally make it into a non-Thru box. Figure 6 shows what is happening.

Figure 6.


6. Self-consistent MIDI



This is a very common problem in computer-based MIDI interfaces. The MIDI specification is interpreted in such a way that the resulting Interface works perfectly okay when it is tested with its Out connected to its In and data passed through the link, but it will not work with anything else. Care in working out what amount of current is flowing through the Interface is the cure for this problem. If you find a MIDI In which works with some instruments but not with others, then you could be facing a design problem of this sort.

If you have purged your MIDI system of all offending items, as detailed above, and it still gives you problems, then what you really need is the 'Practically MIDI Guide to MIDI Troubleshooting' which I seem to remember we are including in next month's instalment...


Series - "Practically MIDI"

Read the next part in this series:


All parts in this series:

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 (Viewing) | Part 8


More with this topic


Browse by Topic:

MIDI



Previous Article in this issue

GenPatch ST MIDI Librarian

Next article in this issue

System Exclusive Dumps


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


The current copyright owner/s of this content may differ from the originally published copyright notice.
More details on copyright ownership...

 

Sound On Sound - Mar 1988

Topic:

MIDI


Series:

Practically MIDI

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 (Viewing) | Part 8


Feature by Martin Russ

Previous article in this issue:

> GenPatch ST MIDI Librarian

Next article in this issue:

> System Exclusive Dumps


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 May 2025
Issues donated this month: 0

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

Funds donated this month: £0.00

All donations and support are gratefully appreciated - thank you.


Magazines Needed - Can You Help?

Do you have any of these magazine issues?

> See all issues we need

If so, and you can donate, lend or scan them to help complete our archive, please get in touch via the Contribute page - thanks!

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