TROUBLE-SHOOTING

You may have been following the articles in this series, wondering if I have the same sort of problems that you face - strange behaviour of MIDI networks, dumps that won't load back, drum machines starting for no apparent reason etc. Despite appearances, I do not have a program ready to hand for all eventualities, and sometimes I am well and truly caught out!

As an example of how I have used some of the techniques and programs described in this series, I am devoting this month's episode to showing how a minor problem with a program led to a perplexing major problem, and the writing of a new program to enable further investigations to be made. I will use ASCHEX, Movie, Sane, SYSEX and other programs in this adventure.

THE QUEST FOR THE ERROR

When I wrote Movie, I tested it thoroughly - a tool like this needs to be very trustworthy, since you will be using it to store many hours worth of work. After I was satisfied with it, I released it to my trusty band of beta-testers - a hardened bunch of desperate users with reputations for crashing even the most robust of software. Apart from one tester who wanted to use it with sample dumps larger than 128K (Movie is really happiest with smaller dumps) there were no problems, except the obvious ones where handshaking or composite bulk dumps were involved.

So it came as quite a surprise when, several months after I had released Movie V0.9, I got some feedback from a user who claimed that it did not work with his equipment. Now Movie is not a particularly complicated program, and I was pretty convinced that myself and the beta-testers had caught all the major bugs, so to be told that there was a major flaw was rather upsetting!

Apparently, sending a bulk dump from a Kawai R50 drum machine to Movie and then attempting to load the same file back into the R50 did not work. If anything, this compounded my guilt, because the R50 was not exactly the latest release, did not use handshaking, had relatively compact dumps, and should have been a dead cert for perfect operation. I might have expected a new whiz-bang megasynth to cause problems, but this was totally unexpected.

TRACKING DOWN THE PROBLEM

After some serious questioning of the R50 owner, I set about putting things right. I started with the obvious (and silly) questions in order to reject the trivial distractions:
- Were the MIDI cables OK?
- Was the Atari ST OK?
- Did Movie work with any other equipment in the same network?

With affirmation of these points, I tried to narrow down the possibilities and home in on the culprit.

First task was to get hold of another Kawai R50 (see panel: 'Limited Resources'); yes, the ultimate ignominy is that I had never tested Movie with my own R50, since I never store dumps in it, preferring instead to programme it from a computer-based sequencer (I use Intelligent Music's RealTime) so that the drum patterns are always stored as part of the song file on disk. In any case, the R50 had no obvious peculiarities in its MIDI implementation, and so it had never seemed worth investigating in any depth. How wrong can you be?

Why the need for two R50s? Well, firstly, it reduces the possibility of a 'rogue' R50 giving unusual results, since you can compare the two units; but more importantly, it allows testing of reception of dumps between the two R50s. Initially, though, I tested both R50s to make sure that they behaved in similar ways. I sent dumps to and from Movie and discovered that, in all cases, while dumps could be stored using Movie, they could not be loaded back into the R50 without the drum machine reporting an error and locking up (which meant turning the power off and then on again to restore operation).

Perhaps there was some problem with the dumps themselves? ASCHEX soon revealed that the dumps were identical for both units, and that they matched the published Kawai System Exclusive information. I had half hoped that something unusual - like different formats for send and receive - might be the answer, but this did not seem to be the case. Starting to lose confidence in Movie, I tried using Sane to directly examine the output from the R50 drum machines, but this matched the published SysEx information and the Movie files.

I then started to wonder whether R50s could send SysEx data between themselves - you never know, it might never have been checked! So I tried sending a dump from one of the R50s to the other. As you might expect, it succeeded! Not put off, I tried sending the dump back again, and that worked too! I then checked all the cables and re-tried the same thing with exactly the same leads, but this time using Movie in place of the transmitting R50 - and it failed! I even tried sending the same dump to the other R50, and that failed as well...

So far I had ruled out the obvious answers - like faulty leads, incorrect information, and even the unlikely explanation that two R50s could not talk to each other! I was beginning to run out of ideas, so I decided to use SYSEX to try and discover exactly which byte caused the error message. Duplicating the first set of bytes of the R50 SysEx dump, and gradually reducing the length of message, soon showed that the problem lay only a few bytes into the message. Re-checking the transmitted bytes confirmed that they were correct, which really made me think!

By now I had more or less established that I was saving the right information to disk using Movie, since I had checked the R50's output using Sane - and this matched what ASCHEX said was on the disk. Unless I had made the same mistake in three separate programs, and it did not affect every other program, then all must be OK. Except that it wasn't - and so there must be something else about the dump from Movie...

NEXT DAY...

The following day I tried a completely different approach. Just about the only thing I could think of which might be left unchecked was the timing between the MIDI bytes as they were sent by Movie. Since this isn't exactly the sort of parameter you often need to measure, I had never bothered before; after all, any piece of MIDI equipment would surely have a wide range of tolerance for incoming MIDI data, wouldn't it?

Turning to the source code for Movie, I stripped out all the graphics used to indicate the output of data and rewrote the output routine to go as fast as possible. Running this go-faster program gave me one of the biggest surprises that I have ever experienced in connection with MIDI - it worked! The R50 dumps which had never before produced anything other than an error message, now loaded perfectly.

So the problem had nothing to do with Movie, the Atari, or the leads, but everything to do with the MIDI input software inside the R50 drum machine. It appears that the time allowed by Kawai between each incoming MIDI byte is very short; so short that even slight pauses between successive bytes can cause the error condition. Whilst this sort of timeout is normally a good idea (it prevents the machine locking up if MIDI transmission stops prematurely), Kawai do seem to have been less than generous in setting the allowable time delay between bytes.

Having discovered the nature of the problem, the next step was to try and discover the limits and get some feel for the actual timing restrictions - and for this, a new program was needed.

THIS MONTH'S PROGRAM

In contrast to previous installments of this series, this month's program does something which is really unwanted: it deliberately adds timing delays into a MIDI transmission, in order to test the timing requirements of units like the Kawai R50. Since it alters the timing between bytes coming from the ST's MIDI Out I have called it 'OUT-TIMER' (concatenated to OUTimer). The program is based around EASED, but with several major changes.

The program works in all three Atari ST resolutions, but the clearest display is in high resolution (monochrome). OUTimer works in a similar way to Movie. The basic procedure is to first receive and then save (on disk) a bulk dump from the piece of equipment to be tested, and then to send the same dump back to the unit, but with a variable time delay inserted between each MIDI data byte. The time between bytes is set by a single variable, which can accept values between 1 and 3. A value of 1 results in byte delays of about 32 microseconds, whilst a value of 3 gives delays of about five milliseconds. (The displayed resolution of the times is completely over the top, but it looks impressive - just ignore all but the first couple of decimal places!) The program displays a chart of timings as measurements are taken. By comparing the time delays with the reception of the dumps, a reliable measure can be taken of the allowable time delays for the MIDI input being tested.

Before using OUTimer, you should ensure that you have backed up the memory contents of the device you will be testing, because errors in reception can cause unforeseen problems if the incoming MIDI data is incorrectly received. With the Kawai R50 problem described above, the error message blocks any further data reception and so no overwriting of the memory should occur. But on other instruments this cannot be guaranteed.

CONCLUSION

Everything ties together neatly this month. I used Dr. T's T-BASIC program to test the Alesis DataDisk (see accompanying review), which puts too long a delay between MIDI bytes at its output for the R50 to work, and I verified this using OUTimer, this month's utility program. With hindsight, I could probably have used T-BASIC to load and send the Movie file and solve the problem without writing OUTimer. I even tried sending dumps to the DataDisk with each byte sent at 5ms intervals, but it worked perfectly, proving that it does not suffer from the same time-out problem as the R50.

So the problem was solved in the end. A suspected problem with Movie turned out to be something entirely different and unexpected. A new version of Movie - V0.9F - is now supplied with the ordinary version for use in those circumstances where speed is important. The moral of this story seems to be that you should explore even the most unlikely explanations when trouble-shooting.

Next month sees the final installment of this series: a rounding up of the demystification process.

The utility programs mentioned in this series are available on two 3.5" compilation disks, for Atari ST only.
SysEx ToolKit 1 and 2 each cost £7 inc postage.
SOS Software (see yellow pages: p38-4).

ALESIS DATADISK

The Alesis DataDisk is a purpose designed System Exclusive dump storage device, a sort of hardware version of the Movie program described earlier in this series. It is thus a subset of a full MIDI Data Recorder or MDR (see SOS March and May 1988) and could be a usefully robust on-stage replacement for a more delicate computer system, providing backup storage of SysEx dumps.

Externally, the DataDisk is a rugged 1U rack-mounting unit, but is a shallow 155mm from front to back - which might pose problems if you need to get at the MIDI In socket or switchable MIDI Thru/Out socket on the rear panel when it is surrounded by much deeper units in a rack. On the front panel, the orange backlit 2 x 16-character LCD and 12 LED-illuminated switches reinforce the impression that the DataDisk is from the same family as the popular Quadraverb. A 3.5" double-sided, double-density disk drive completes the front panel.

SINGLE & MULTI

In a refreshing and complete contrast to most 1U units, Alesis have provided a 'one button per function' user interface - full marks! In case you thought that this means there are 12 or less functions, the operating system actually provides menus for each switch - so pressing the 'Receive' button once prepares the machine for Single packet dumps, whilst pressing it again prepares everything for Multi packet dumps. Not unsurprisingly, the LCD screen reads: 'RECV MULT SYSEX: WAITING FOR DATA', and sending a SysEx dump causes this to change to 'RECEIVING.....' (the six dots give an indication of the manufacturer: Roland, Yamaha, etc or the ID code (eg. 52H). The disk drive starts up as soon as the dump arrives and continues until it ends. Once the dump finishes, the display changes to the rather confusing: 'STORED AS.........xxxxxx FILE nn' where 'nn' can be up to 53 - the maximum number of files. Unlike most computer-based units, the file has already been stored! (DataDisk is a direct-to-disk recorder.) Multi files can be used to build up composite dumps from several different synths to provide a 'system snapshot' facility (see SOS June/July 1989).

The field marked 'xxxxxx' is used when the DataDisk identifies the instrument being used; for example, for a Waldorf Microwave wavetable synth [reviewed SOS Dec 1989] the dots equal 'Waldrf' and the x's equal 'MicroW'. Dividing 796 Kbytes (an empty disk) by 53 files gives just over 14 Kbytes per file, which probably means that for most of today's instruments you should be able to get at least 20 dumps onto a single floppy disk, assuming a dump of about 20 or 30 Kbytes. In any case, 53 files is quite enough to cope with (53 lots of DX7 bulk dumps is 53x32 = 1696 voices!). To identify the files you can rename the 'FILE nn' part of the description with an 8-character name (using the 'Name' button). The '.....' and 'xxxxxx' fields still remain, so that you do not need to identify the manufacturer or the instrument.

Sending a file from the DataDisk makes use of the 'Send' button, again with just two menu choices: the first press gives 'send the currently selected file' (you use the two 'Scroll' buttons to move up and down through the available files) and second press gives 'send all files'. Pressing the 'Do/Yes' button sends the file(s); pressing any other button aborts. This really is an easy interface to use!

For use with MIDI devices which require handshaking, the 'Request' button has choices for Sample dump requests (00 to 99, selected from the scroll buttons) or SysEx dump requests (you can scroll through J.L Cooper, Oberheim or Roland).

DISK FUNCTIONS

The remaining five buttons are all concerned with disk maintenance:

• INFO gives two LCD pages of information, as well as the current file display:

24 FILES = 005% 758 Kbytes free
Software Version 1.2
13 Waldrf MicroW Internl 1

• MIDI controls the MIDI echo feature (Thru?) and the Receive Program Change channel, so that you can send files just by sending the appropriate program change message to the DataDisk.

• DELETE allows individual files or all the files to be made permanently inaccessible from the disk.

• FORMAT prepares a new disk for use, as on any computer - it takes about a minute.

• BACKUP enables single files to be copied to another disk, or all the files (the entire disk) to be backed up to either disk or to MIDI. The RAM available inside the DataDisk is limited, and so quite a few disk swaps may be needed to backup full disks.

IN USE

A typical MIDI network has a master controller connected to a MIDI patchbay or a Thru box for distribution to the rest of the network. Simple networks only send from the master controller (or a sequencer) out to the slave expanders. In order for SysEx dumps or editing to take place, the MIDI Outs of the expanders need to be connected to the patchbay or a switch so that they can be selected by the data recorder or computer. In a complex network, a MIDI patchbay is the only really practical solution for all the necessary switching and so the DataDisk or MDR probably needs to be installed in the same rack as the patchbay for it to work effectively. (In the future, as MIDI networks increase in size and complexity, you may find that the two functions become combined into a single MIDI control station with the switching and storage functions in the same unit.)

INSIDE VIEW

Inside the case is a Fujitsu disk drive and a double-sided, plated through hole, silk screened, solder resist printed circuit board. This PCB has a Signetics 80C31 8-bit CMOS micro-controller running at 12MHz (from a ceramic resonator, not a crystal!), with a 27C256 CMOS EPROM containing the Operating System software (V1.2: 15-12-89) and a Toshiba RAM chip. The disk controller is a Western Digital 1772 chip clocked from a 16MHz crystal. The 6N138 MIDI opto-isolator (a good choice) is in a socket, which makes replacement easy. The chip technology used is relatively current, with HC and HCT74 series logic used for the miscellaneous chips.

FINDINGS

- The DataDisk claims to be a direct-to-disk universal data storage device on the front panel, and although it does save directly to disk via a RAM buffer, unlike the Elka CR99 [reviewed SOS April 1989] it does not store MIDI timing information or non-System Exclusive data. This means that the DataDisk cannot be used as a replacement for a sequencer.

- I encountered problems when storing SysEx dumps shorter than six bytes long, since they caused the DataDisk to lock up, apparently having missed the '$F7' byte. Sending a second dump usually terminated the first dump, but then the second dump was ignored.

- Sending SysEx dumps (longer than six bytes) too close together in Single mode can mean that the second dump is ignored (maybe because the first is still being transferred from the RAM buffer to the disk?). Perhaps the buffer is not large enough? Considering that this is supposed to be a direct-to-disk machine capable of coping with large dumps (up to 796 Kbytes, presumably), this is not too impressive.

- When sending files via MIDI backup, the DataDisk seems to use Manufacturer ID 00 for sending a SysEx message containing ASCII text describing the file number. Yet when receiving such a message, the DataDisk decodes ID 00 as 'Sample'. I am not sure about the 'legality' of using IDs in this way...

- The DataDisk ignored any SysEx messages with a Manufacturer ID code higher than $5F. This included Noncommercial ($7D), Sample Dumps, and other Non-Realtime ($7E) as well as Realtime ($7F) messages.

- Some instruments can also correctly generate an apparently wrong ID code. For example, LinnDrums fitted with a MIDI retrofit option display a J.L Cooper ID, not a Linn ID. This is correct, because J.L Cooper designed the MIDI retrofit kit for the Linn!

- The decoding of instruments is not always reliable: 4-operator dumps from the Yamaha FB01, PSR 6100 portable keyboard dumps, Electone Organ dumps, and QX7 sequencer dumps can all be confused for 6-operator DX7 dumps! But the V50 is correctly decoded, as well as the TX816. Kawai's K4 was not recognised, but the K1, K3, K5, R100 and R50 were. Casio's CZ1, CZ101 and VZ1/10M/8M were not recognised. Sequential's Prophet VS was the only instrument automatically identified.

- Kawai are another manufacturer who sometimes use handshaking for SysEx dumps, and yet no provision is made for this in the DataDisk's 'Request' menu. (Downloadable additional device drivers on disk would be useful here.) The Kawai R50 would not accept its own stored dump when sent back by the DataDisk, suggesting that the transmission speed is not fast enough. K5 dumps did not terminate correctly (handshaking is needed), even though the K5 was recognised.

CONCLUSION

Unlike the Elka CR99, the Alesis DataDisk only stores System Exclusive messages and so is more restricted in its applications. The operating system is stored in ROM, which means that the instrument identification and Manufacturer IDs are fixed at the time of programming of the ROM, so periodic updates may be needed to avoid potential confusion about the identity of dumps and of instruments. Since the correct identification of instruments does not really affect the operation of the DataDisk, this is really only a minor consideration. However, the problems I encountered with the two Kawai units suggest limitations in the buffering and send speed.

Despite the problems I experienced with a few items, the DataDisk worked reasonably well on the majority of equipment available for testing. I am sure that user feedback to the manufacturer will help to clear up the few minor areas of concern which exist at present.

As a rugged, stage-worthy source of backups - particularly for Alesis MMT8 sequences and HR16 drum patterns - the DataDisk could prove very useful. If you can't stand computers and need to store only SysEx dumps, then the DataDisk's easy operation might fit the bill.

FURTHER INFORMATION

£299 inc VAT.

Sound Technology plc, 6 Letchworth Business Centre, Avenue One, Letchworth, Hertfordshire SG6 2HR 0462 480000.