MIDI Hardware and Software for RS232 Interface Standard
A MIDI utility hardware and software package for any RS232-equipped micro. Review by Simon Trask, who’s thinking of having RS232 fitted to himself.
Up till now, most MIDI software packages have been written specifically for certain computers. But in the shadow of Oxford's dreaming spires, they see things somewhat differently...
Whichever way you look at it, there's one inescapable fact about the burgeoning MIDI software industry. It now has countless sequencing and patch dump programs to its name - probably far more than can actually be supported in the marketplace, in fact - but very little in the way of general-purpose utility software and hardware. The Hinton MIDIC, an entirely new system from sunny Oxfordshire, is an attempt to change that. The only other package at all similar is Roland's MPU401 MIDI Processing Unit, but that unit's appeal is limited in this country by virtue of the fact that it'll only work with the Apple II/IIe and IBM PC computers (long-planned Commodore 64 and BBC versions have yet to materialise).
From the outside, MIDIC is a self-contained, Z80-based microprocessor system on a single Eurocard housed in a robust aluminium casing measuring 2.5" x 4" x 6.5". But crucially, and unlike the MPU401, MIDIC has been designed to work with any computer or terminal that has an RS232 interface. That means designers Hinton Instruments have ensured themselves a broad range of potential users, and that they can draw comfort from the fact that any change of computer is unlikely to leave their MIDIC system out in the cold. Because in case you weren't aware, RS232 is a world standard communications protocol used for the transmission and reception of data over the phone network via modem, and the current explosion of interest in this field means that even if a computer company fails to fit the system to their latest machine, an RS232 add-on from an enterprising peripherals firm is never too far round the corner.
But what is MIDIC? And what's all this talk about RS232 when everyone knows that MIDI is where it's all at, musically speaking?
Well, MIDIC is an intelligent buffered interface unit that sits between instrument and computer, with MIDI cables at one end (one each of MIDI In, Thru and Out sockets are provided) and an RS232 cable at the other. The user manual gives full instructions for getting MIDIC up and running, and thankfully, it's a pretty straightforward procedure.
The idea behind MIDIC is 'to make life with MIDI easier' (Hinton's words), a sentiment I wholeheartedly applaud. It sets out to do this by, among other things, allowing you to read data from and send data to any MIDI instrument, filter out selected MIDI codes, convert MIDI channels, and leave all MIDI timing considerations to MIDIC. In many instances commands are issued by single keypresses, and a 'helplist' of commands can be summoned at any time simply by keying 'H' on the host computer. Thankfully, upper and lower case characters are treated as being the same.
Within the Hinton unit is current MIDIC software version 1.1, which, is held in an 8K EPROM, along with 10K RAM for buffering MIDI data. There's also space for another 8K EPROM, the intention being that other software houses (or indeed Hinton Instruments themselves) can build their own software into the MIDIC system - definitely an appealing idea.
The price of the above configuration is £300 excluding VAT, or £350 for the version with battery backup. However, there are some other costs to bear in mind - an RS232 cable, for instance. Currently, Hinton Instruments can provide 1.5m MIDIC RS232 cables for the BBC B, Apple Macintosh, RML 380Z and 480Z, Sinclair Spectrum and QL micros, along with a 'null modem' cable for those computers with standard RS232 pinouts; cost is £15 per cable. Alternatively, MIDIC pin connection details are given for the above-mentioned computers and for making up a standard RS232 cable, should you wish to follow that route.
Further possible costs are an RS232 interface unit and terminal emulation/comms package, though one nice consequence of using RS232 is that, for reasons outlined earlier, any purchases you make on this front will not be limited to MIDIC applications. For this review, I used a BBC B fitted with Commstar, a ROM-based intelligent communications package that also sees use in a conventional modem system.
MIDIC requires an external power supply, and this may be supplied either by the host computer via pin 25 on the RS232 D-connector, or from an optional 6V DC supply.
As you may know, the MIDI protocol allows no restraint to be put on the reception of data. This is understandable as MIDI is essentially a real-time system, so the receiver should always be in a position to handle data when it arrives.
But RS232 has no such requirements made of it - in fact, a receiver may often need to tell the transmitter to wait a while (well, a few microseconds). This process is termed 'handshaking', and the RS232 standard allows for several handshaking lines. MIDIC will work at the following baud rates (ie. speeds of data transmission): 150, 300, 600, 1200, 2400, 4800, 9600, 19.2K and 38.4K. The alert among you will notice that none of these equate with MIDI's 31.25Kbaud (and only one of them is actually faster than MIDI), which is where the handshaking comes in. However, as MIDI data will just stream into MIDIC regardless, some form of buffering is necessary. The 10K RAM inside MIDIC is logically divided into four buffers: MIDI input, RS232 input, MIDI output and RS232 output. The RS232 output (ie. MIDIC-to-computer) buffer has, logically enough, been allocated the lion's share of MIDIC's RAM - 7K of it, in fact.
The MIDIC 1.1 software operates in two modes, Process and Interface, with the idea behind the former being to give musicians a means of equipping MIDI synths with MIDI facilities the original designers didn't think fit to include. It offers filtering, generation and assignment commands for the control of MIDI data, whilst the latter allows MIDI data to be presented over RS232 in two formats, ASCII and Binary, which basically offset clarity against memory usage.
A few quick words of elucidation are probably in order here. First off, filtering in this context refers to the removal of specific MIDI codes from a datastream, so that, for instance pitchbend on a master instrument doesn't always have to be copied by a slave. On the other hand, generation commands allow the insertion of timing and synchronisation codes into a MIDI datastream, so that MIDIC can be used to control drum machines and sequencers, for example. As for assignment commands, their purpose in life is to rejuvenate an otherwise unassuming MIDI system by giving it powerful voice and channel control facilities.
On power-up, MIDIC goes through a self-checking phase, and if all is well, the small 'Run' LED on the unit's front panel blinks rapidly to show that it's awaiting a character over RS232. While things are in this waiting state, any data arriving on MIDI In is echoed on MIDI Out, as well as MIDI Thru.
To instigate communication between computer and MIDIC, you have to transmit a character over RS232 from your computer. This character is then analysed by MIDIC to match MIDIC's baud rate with that of the computer, after which a sign-on message is sent to the computer. If you're using a comms package this message will automatically appear on the VDU screen, but if you're using MIDIC with your own MIDI software, don't discard this message altogether - it's advisable to search for the space+delete terminators as a sign of successful communication.
"If you incorporate too much MIDI processing into your system, you run the risk of introducing noticeable delays."
With all preparations completed, Process mode is the default mode on entry. Everything received on MIDI In is still retransmitted on MIDI Out, but now a number of processing operations (which allow incoming MIDI data to be altered in various ways) can be brought into the picture.
Let's look at filtering commands first. The MIDIC way of doing things lets you filter out codes prior to the MIDI data-stream being passed to MIDI Out and MIDIC's RS232 Out buffer, and only incoming MIDI codes are suppressed - all codes may still be transmitted. Control of the MIDI Out route means that MIDIC can, for instance, act as a 'control extension' for a synth that has no MIDI filtering facilities. For the RS232 route (which comes into action when you enter Interface mode), filtering can simplify the procedure of programming by only sending data required by the program over RS232. Filters implemented in MIDIC 1.1 are pitchbend, active sensing, aftertouch, all Real Time codes, and System Exclusive. Pitchbend and aftertouch are not channel-specific. There's also an implementation of channel filtering that enables you to specify anything from 1 to 16 channels as being recognised for MIDI reception.
The second form of Process command is the generation type. With these, you can use MIDIC to generate active-sensing clocks, say, for synths that lack them. Tempo commands allow MIDIC to insert MIDI timing clocks between other MIDI codes being output, and you can send MIDI Start, Stop and Continue codes using single keypress commands on MIDIC 1.1, adjusting tempo in a similar manner. These timing commands can be sent in ASCII mode as well, and MIDIC also lets you set tempo in crotchets per minute, with a display of your chosen value being available at any time.
You'd be right in thinking that list is a long one, but it isn't excessively so. All these-generation commands greatly ease the would-be programmer's task by allowing MIDIC to take control of one of the most difficult aspects of MIDI - timing. Further useful commands simplify the task of dealing with timing on input MIDI data, and these come into operation in Interface mode (see later).
A 'reverse generation' command allows running status processing to be carried out on MIDI output. By removing unnecessary status bytes from the MIDI datastream, associated time delays can be removed. This feature is useful for reducing the amount of data transmitted when using Assignment Processing.
The third category of Process command is keyboard assignment. More than any other MIDIC feature, it's this one that allows a comparatively humble synth to assume the role of MIDI controller keyboard. Sixteen assignment memories are available in total, and they operate only on data received via an assignable Basic Channel (1-16), which means that MIDI data received on other channels is subject only to the general filtering commands of MIDIC.
Each assignment memory consists of four 'registers', a name (up to 28 characters long), and a list of MIDI codes that's transmitted as soon as the assignment is selected. The registers are used for defining up to four keyboard ranges, which can be defined either by typing in MIDI pitch codes over RS232 or by keying notes on a connected MIDI keyboard. You can assign each register its own output MIDI channel, and pitchbend, aftertouch and all-notes-off commands may be enabled for the assigned channel of each register. You can even transpose incoming pitch data over the entire MIDI pitch range prior to transmission on the assigned channel.
The MIDI event list for each assignment enables you to enter a sequence of up to 50 MIDI codes. The only hassle is that you have to input them in hex format - and make sure you get them right first time, as there's no error-checking. But because any MIDI codes can be transmitted, the possibilities of the assignment system are many and varied. Obvious uses include separate patch selection for each instrument in a MIDI setup (as long as they're on separate channels), MIDI sequencer and drum machine start-up, and MIDI mode selection for individual instruments.
The register definitions let you define up to four splitpoints and/or overlays, each with its own voice. The channel conversion facility, meanwhile, allows a master synth to effectively transmit MIDI data over several MIDI channels. A simple application would allow, say, a DX7 to transmit over any one of the 16 channels available, or you could use one assignment memory as a 'MIDI off' control for those occasions when you suddenly want to play your master synth by itself.
In reality, if you incorporate too much MIDI processing into your system you run the risk of introducing noticeable delays, so don't get carried away with your newfound MIDI freedom. It's all a matter of experience and commonsense, really.
You can select your chosen assignments on the host computer over RS232, or on the master synth over MIDI In by selecting an appropriate patch number twice. This latter facility is useful if danger-fraught (Casio's CZ101/1000 synths won't transmit double selects, for instance), but it really comes into its own if you want to use battery-backup. This option is available for £50 on top of the basic 1.1 system, and allows all Process mode settings (including keyboard assignments) to be stored when the unit is powered down. Interface mode and Tempo Generator On aren't recalled states, but the baud rate and current assignment number are.
The main benefit of battery backup is that it allows you to use MIDIC without a computer, something that could certainly come in handy at a gig, for example. However, as assignment memories aren't retained through power-down with the basic system, battery backup is actually useful for any situation - though assignments can be downloaded over RS232 for storage and subsequent retrieval.
One irritating feature of the assignment system as it stands is that assignments can't be edited, so if you make a mistake, or you want to change one code, you have to redo the assignment from scratch. There's scope here for a spot of home programming - but that's not going to be much consolation for non-software writers.
Whereas Process mode allows you to set up a number of data processing options, Interface mode actually allows MIDI data to be communicated over RS232. The two available sub-modes govern the form in which this data is transmitted and received by MIDIC: ASCII mode and Binary mode.
The standard use of RS232 is to communicate ASCII text files (either to another computer or to a printer). A comms package will therefore treat incoming bytes of data as representing ASCII characters and will echo them to the screen (or a printer). But seeing as MIDI codes are not ASCII-compatible, MIDIC provides an ASCII mode which converts received MIDI codes into ASCII hex format, and separates them with two ASCII space characters for added display clarity. This means four characters are placed in the RS232 output buffer for every one code received over MIDI, so consequently, the RS232 buffers can only hold a quarter of the data in ASCII than is possible in Binary mode (in which incoming MIDI codes are merely 'echoed' down RS232).
"There's no reason why this package shouldn't run and run, giving rise to all manner of application programs."
So, ASCII mode gives you greater clarity of presentation, but with an increased risk of buffer overflow - and only experience (or relevant information) will tell you whether your particular application is likely to place great demands on buffer space. A DX7 32-patch dump, for instance, takes up 4K of memory, but reading it into the RS232 input buffer in ASCII obviously results in buffer overflow. Fortunately, MIDIC generates the message 'lost data' when this situation occurs, so the error shouldn't be compounded.
In Binary mode this situation simply doesn't arise, though for reasons outlined above, you'll need to do some programming of your own if you want to stand an evens chance of actually understanding incoming MIDI data in this mode. You have been warned.
Coming back to ASCII mode, it's worth pointing out that this also functions in the computer-to-MIDIC direction, in which case data must be sent in the same hex format in which it was sent by MIDIC. This allows you to send MIDI codes and data manually via your comms package to a MIDI instrument, with MIDIC performing the process of converting your ASCII data into true MIDI codes.
Another aspect of Interface mode lies in its timing controls. MIDIC's internal tempo generator can interleave MIDI timing clock codes with incoming MIDI data if required, which means that all a program reading MIDI data has to do is count timing bytes. A further simplification removes even this task, with MIDIC undertaking the count and transmitting the resulting value for storage.
I've already made mention of the fact that MIDIC's designers have allowed for the inclusion of a second 8K EPROM within the system, the intention being that interested parties can write custom software to sit within the MIDIC system.
To understand the value of this more fully, we need to consider how various applications could be built into MIDIC. There is, of course, great scope for developing computer-based (as opposed to MIDIC EPROM-based) MIDI software using MIDIC, and certain applications actually require this approach - the familiar sequencing and patch dump applications, for instance. The immediate thought here is that such software immediately becomes computer-specific, which is no terrible thing in itself, but nonetheless lessens the 'universality' that characterises MIDIC.
EPROM-based software in the MIDIC context will probably be process-based - and use the MIDI In-Out route of MIDIC's Process mode. One obvious application that's already seething in the cauldron of Hinton Instruments' programming inventory (Pseuds' Corner here I come) is a MIDI controller allocation program. One day, maybe every synth and expander will incorporate soft allocation of controller values, but until that day comes, any program which allows some degree of flexibility in this area will be welcome.
Even if you're a fairly experienced programmer, and no matter whether you take a MIDIC-based or computer-specific approach, you're going to want a fair bit of documentation to help you get going in the first place. The Hinton won't let you down. The clear, concise and well-laid out user manual contains a good deal of information on both possible applications of Process mode and writing MIDI software using MIDIC.
And deserving of the highest praise are the manual's appendices, which include a MIDI 1.0 Quick Reference Guide, a complete (though easily outdated) list of MIDI manufacturers' ID numbers, and impressively-comprehensive MIDI implementation lists for 10 synths including the Yamaha DX7, Roland's JX3P and JX8P, the Korg Poly 800 and Casio's CZ101/1000. If all goes according to plan, the next revision of the manual will include complete Korg, Akai, Oberheim and Ensoniq MIDI implementations, while Hinton will gladly expand the appendix to include any other implementations users may have checked using MIDIC. That's got to be good news, because as the manual's introduction puts it, 'quite often the manufacturer's published data (assuming any exists) is incorrect or incomplete - not quite the MIDI spirit'.
At its most basic level, the Hinton package is an attempt to bring computers and musical instruments (and therefore musicians) closer together. Ably assisted by two interface standards - MIDI and RS232 - it succeeds admirably in achieving that aim, at least on paper. Whether it actually performs the function in reality remains to be seen, but its design and presentation gives the user every encouragement to (a) delve deeper into the workings of MIDI and (b) think seriously about writing custom MIDI software for specific musical tasks.
At the same time, MIDIC can be used to good effect with minimal recourse to a computer. By using Process mode to its fullest, you can create a powerful set of control facilities for your master synth with nothing more than a basic comms package and MIDIC's straightforward commands.
In fact, the built-in (and refreshing) open-endedness of MIDIC should allow it to satisfy any number of MIDI requirements. I've already given a few possible applications, but if things go well, these should be no more than a drop in the MIDIC ocean. Given the right support both from Hinton Instruments and from third-party software companies, there's no reason why this package shouldn't run and run, giving rise to all manner of MIDI application programs. It really is that versatile.
What MIDIC won't give you are any of those 'extra-MIDI' features offered by other software packages, like syncing of non-MIDI drum machines and sync-to tape facilities. It won't give you multiple MIDI Out sockets, either, which is a shame when you consider the possibilities afforded by the package's assignment system.
MIDIC is already a little on the expensive side, but I guess initial development costs have to be recouped somehow, and if, like Hinton, you're a relatively small company, that task isn't easy to achieve.
If only more MIDI packages were as inventive...
Further information from: Hinton Instruments, (Contact Details).
Review by Simon Trask
Previous article in this issue:
Next article in this issue:
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!