In the two years since its introduction, Hinton Instruments MIDIC processor has found applications in both professional and home recording studios, live performance and educational establishments. Having already used a MIDIC to help develop new MIDI programs, we asked our software consultant Jay Chapman to tell us more about what the MIDIC can do.

The Hinton Instruments MIDIC is a rather rare, slightly eccentric, amazingly flexible, semi-dedicated MIDI processing system. As this review will explain, MIDIC has something to offer every MIDI user although perhaps it would be fair to say that it offers considerably more to the MIDI software developer, experimenter, or researcher than to your average MIDI-using musician. Don't despair if you fall into the latter category, however, since MIDIC facilitates software development for MIDI and that means that new facilities can be added to MIDIC almost at the drop of a hat!

MIDIC is an absolute boon to somebody like myself who is interested in writing MIDI software for anything from a BBC micro to a VAX 11/750, passing by the IBM PC on the way. In fact, MIDIC can turn many computers that couldn't hope to offer sensible MIDI facilities into paragons of MIDI virtue - we'll discuss the features that make this possible later in the review.

ARE YOU A POTENTIAL DABBLER?

Anybody who would dabble with creating a little MIDI software but has been put off because of the need to understand interrupts, timer chips, buffers, assembler code, memory mapped interfaces etc, etc, should read this review. Anybody who would like to use MIDI as an example in teaching computer music or as a project area in secondary or further education should also read on. Anybody that has a computer that nobody sells a MIDI interface for can also have hope!

To give all you people in the last paragraph a ray of sunshine in your darkness, you may be interested to learn that I had my Nimbus computer acting as a one and a half octave MIDI keyboard with transposition over the full MIDI key number range, with full control over key velocity and selection of MIDI channels, all within a couple of hours of the MIDIC being plugged in and switched on! A little of that time was spent persuading the RS232C port on the Nimbus to play ball and most of the remaining time was spent building up the features of the program. Hardly any thought at all had to be given to the MIDIC after I had worked out what commands (single ASCII characters) I needed to send it so that it would then pass on any MIDI events I sent it (ie. sequences of bytes) to its MIDI Out.

As an example of the ease of use of this device, you don't have to tell it what Baud rate to use when communicating with the computer or terminal down the RS232C link - you simply send it one character and it works out the Baud rate by itself. Before I lull you into a false sense of security, however, let me point out that ease of use doesn't mean that you don't have to do your homework first. I can assure you that the MIDIC makes life with MIDI easier but as with other complex MIDI devices, you either make a pact with the Devil or you spend sometime devouring the manual. I know which method I chose!

INTELLIGENT MIDI BLACK BOX

I'd better make it clear what I meant by 'semi-dedicated' in the first paragraph. The MIDIC that I am reviewing here is a sort of super MIDI interface combined with a MIDI event processor (cf. the Yamaha MEP4 reviewed July 86 issue). In fact, it is quite possible to obtain a MIDIC which has been reconfigured to perform other tasks such as turning an AMS DMX 15-80s digital delay unit into a monophonic MIDI sampler! Other devices which can be brought under comprehensive MIDI control (tamed?!) by a suitably configured MIDIC are the REV-1 digital reverb and YDD-2600 delay line, both by Yamaha.

The reason that MIDIC is such a flexible and intelligent device is quite simple: inside this small black box lurks a Z80 processor with ROM, RAM and a few other chips besides, ie. it's a microcomputer system! (Figure 1 shows the flow of data through MIDIC - it may help to glance at this diagram as the text unfolds!)

Depending on how modern a musician you are, you will now either have fainted clean away at the very thought of another microcomputer in the music room or you will be rubbing your hands together with glee at the prospect of more processing power! Those of you still with me read on, the rest of you (those wearing the blinkers) read on as well, you never know: you might learn something!

PHYSICAL DETAILS

When you buy the MIDIC (in the configuration I am describing) you will receive the MIDIC interface itself, a comprehensive manual (which I will give a little attention to later), and one or two semi-optional extras. I say semi-optional because you will need a cable to connect the MIDIC to a terminal or computer system and you may also need a power supply (the power requirements are described in the manual). I found that I had no problems powering the MIDIC from the +5 volt supply on the back of an RML Nimbus or from an Akai 400mA 6 volt separate power supply when using a BBC micro. The BBC micro's auxiliary DC power connector could also have been used - specify your requirements and Hinton Instruments will be able to makeup a suitable communications/power cable (for a consideration, of course!).

MIDIC is a practical device - it is meant to be used by musicians on real live gigs as well as by students researching the whichness of the (musical) why... in either case this means it should be robust and this is where MIDIC scores the first of its brownie points. I subjected the extruded aluminium box to the ultimate test by standing on it. Those of you that haven't met me won't go far wrong if you imagine a 280lb gorilla balancing on one foot on a 60 x 105 x 165mm box - it didn't even creak; that's what I call roadie-worthy!

Another optional extra you might consider is battery backup. This will allow you to use the MIDIC on stage without having to connect a terminal or computer system to tell it what to do after power-up because it will remember everything you set up last time. I'll expand on this point later.

THIS END

What one might call the MIDI end of the MIDIC case features the three ubiquitous MIDI sockets: In, Thru and Out. If the MIDIC has not been told otherwise, the Out will function as a Thru when the unit is powered up allowing your master MIDI controller to immediately drive any devices connected to either Thru or Out, which could be useful in a live performance situation. Also at this end of the MIDIC are one red and one green LED (Run and Int respectively) which are used to indicate what state the MIDIC is in. Their detailed meaning need not concern us here; suffice it to say that they are used informatively to tell us such things as whether data is flowing, or that the MIDIC has just been reset or powered up, or that the MIDIC is trying to determine the Baud rate of the computer communication it is connected to, and so on...

THAT END

At the other end of the MIDIC is a standard female, 25-way, D-type connector which is used to communicate with a terminal or computer system via the computer industry standard RS232/RS423 communications medium (there is also an input connector for a +6 volt 350-400 mA supply). Again the detail of RS232/RS423 need not concern us here which is good news because it can confuse even some fairly expert computer people; just make sure that you save hours of frustration by buying the right cable for your intended configuration; Hinton Instruments will be pleased to advise you.

It is important to note that this RS232/RS423 connection is one of the major strengths of the MIDIC. Almost every computer and terminal in the world can be connected to the MIDIC which naturally means that MIDIC can be controlled from almost anything. Also, it is worth bearing in mind that as software (such as sequencers, synthesizer patch editors and voice libraries) is written for the MIDIC, it should be possible to port them to other (and newer) micros in the future. With the accepted universal musical interface at one end and the universal computer communications interface at the other, MIDIC is a large step ahead of its competition: your MIDIC interface isn't tied to just one micro, so it needn't become obsolete when you eventually update your computer system.

WHAT DOES IT DO? (1) EVENT PROCESSOR

I'll look at this side of the MIDIC's capabilities first because this is the most instantly accessible part for the non-programmers amongst you. To use the facilities described in this section you will have to connect a computer terminal to the MIDIC at least once to tell it what you want doing. If you have the battery backup option on the MIDIC then all your carefully thought out setting up will not be forgotten - this is particularly useful in the middle of a gig when somebody trips over the power supply and thereby powers the MIDIC down unintentionally!

The most obvious thing you can do with the MIDIC is use it as a MIDI monitor. In other words, you can insert the MIDIC into a MIDI daisy chain and see the data that is flowing come up as a display (in hexadecimal) on your terminal screen. This is especially useful when some part of your MIDI network is not responding properly and you're not sure where the fault lies. With the display you can check if the right messages are getting through on the right channels and so on.

An even more important use of the monitor display is when you are trying to use some poorly (or incorrectly) documented feature of a MIDI device. If you're not quite sure what is happening over MIDI when you carefully give some sequence of command key presses, then you will be able to verify what the device is actually doing (compared to what the manual insists that it is doing). Since the display is scrolling up the screen you can see the last twenty or so MIDI events no matter how quickly they arrived... this is a little more useful than the Yamaha MEP4's display where you are only likely to be able to see the last event because each incoming event replaces the previous one.

Whilst you are in this terminal display mode where all data is being converted from the binary code into readable ASCII characters, it is possible to obtain a full 'Help' message showing all of the available commands. The possibilities offered by the commands relating to Event Processing will now be discussed.

Assignment Processing

By the simple expedient of selecting one of the first sixteen program selection numbers on your 'master' synthesizer by pressing the relevant button quickly, twice in succession, you can select one of sixteen Assignment Memories in the MIDIC. You can also make such a selection remotely from a computer or terminal via the RS232C link. The Number and Title (an up to 28-character string that you specified earlier to help jog your memory eg. '2 octave bass/3 octave piano') of the Memory you have selected are displayed on the computer or terminal screen (if connected) and a stream of MIDI events - that you also specified earlier - are sent out over MIDI.

This Event List can consist of anything sensible in the context of your MIDI network. For example, you may send out a series of Program Change messages, channel by channel, for each of your slaved synthesizers; you may set Pitch Bend Change parameters to initial values; you may even send out whole System Exclusive messages or initial chords to be played! Note that these Event Lists have to be specified in hexadecimal - but you're a MIDI expert by now anyway aren't you?!

Keyboard Splits

Ah, we're really getting into some of the fun areas now! Up to four Keyboard Assignment Registers can be defined for each Assignment Memory on the MIDIC. Going back to the bass/piano example whose Title was mentioned above, you would only need to use a two-way split to achieve that. The bottom and top notes of each register are either defined by their MIDI key numbers or you can simply play the relevant key on the MIDI keyboard connected to the MIDIC's MIDI In port. Each register can have its own transposition defined as well as the MIDI channel number that will be used (for all messages that include channel information) that belong to the register.

Pitch Bend, Aftertouch and All Note Off messages may be enabled or disabled for each register which means that in the bass/piano example it would be possible to ensure that any Pitch Bend was only sent to the bass synthesizer and not to the piano synthesizer.

Now, you may be saying to yourself that this is all very nice and useful but aren't there quite a few MIDI Event Processors around these days, some of which offer more facilities at a similar price?

The answer is that you are quite right! In fact, I think it is fair to say that the MIDIC is not too bad at all as an Event Processor but, as an example, lacks the delay facilities of the Yamaha MEP4. Don't forget two things however: firstly, it would not be too difficult for Hinton Instruments to add delay features to a future MIDIC (and the company has a policy of making new software releases available to existing owners); secondly, we have only so far considered what are to me the less important features of the MIDIC-there is much more to come!

WHAT DOES IT DO? (2) INTELLIGENT MIDI INTERFACE

OK, I'll admit it - this is the bit that gets my mouth watering! MIDIC makes it possible to achieve quick results when I'm writing MIDI software. I can concentrate on what my program is supposed to be doing and let MIDIC handle all of those essential but annoying-to-programme features of MIDI like Active Sensing, timing and synchronisation. Let's see how MIDIC helps.

Buffering

Many of you will be aware that MIDI transmits data at 31.25 kBaud (bits per second) which would suggest that any interface, and the computer that you are interfacing to, must also have to be able to keep up to this rate as the bits flow in. This is quite correct in most cases and can cause real problems for some micro systems! If the micro can't keep up all the time then it's a dead duck as far as MIDI is concerned. Often the micro will be able to keep up with MIDI in short bursts of typically up to 16 bytes in length; this is OK until you start transmitting voice parameter dumps which are 4000 bytes long!

Most of the time a computer can cope quite easily with the average data rate rather than the worst case maximum bursts of data - what's required is a means of holding onto the arriving data whilst the computer unchokes itself from the excess bursts! Well, that is exactly what MIDIC can do for you. In the worst case, the MIDIC I had could suck in almost 6000 bytes flying in at 3000 bytes per second, whilst the poor old Nimbus Piconet groaned along at about 240 bytes per second. In this way, even if I dumped the full memory contents of a TX7 to the computer (just over 4000 bytes in total) I didn't lose a single byte and thereby saved a lot of frustration!

If you have an unintelligent interface, such as the incredibly famous and wonderful (OK, cheap!) E&MM BeeBMIDI, then the computer has to do all the work and do it all fast enough. If you are the programmer, even if you are just having a quick dabble for fun, you will have to arrange for all incoming data to be captured and buffered safely whilst other processing is going on. With a MIDIC doing the dirty work for you, the job becomes a lot easier - just pull in the bytes as and when you are ready to deal with them, even using a simple, and very slow, BASIC program. In this way you can concentrate on what you want to do with the data rather than with the nasty details of safe capture, etc.

Timing

The other major feature of programming for MIDI (or for many other real-time systems in fact) concerns how you deal with the timing of events either for, or from, the outside world.

An obvious example here is when you (or some slave synthesizer) have decided that MIDI Active Sensing must be used. You're not really interested in your own sequencing program organising the (&FE) bytes on a regular basis, because you want to concentrate on the main issue without annoying distractions. In this case, one single character command to MIDIC will allow you to forget Active Sensing on output for the rest of the session! Active Sensing can be a nuisance on input as well since you're never quite sure when one is going to arrive (and they can arrive interleaved almost anywhere in the MIDI data stream) and they could upset your comprehension of the sequence. You've guessed it: MIDIC will filter them out for you upon request!

MIDI Clocks

The most painful timing has to be done, both on input and output, in dealing with MIDI clocks.

If clocks are arriving via MIDI In (perhaps from a MIDI-equipped drum machine), the programmer may well wish to synchronise his output with them. The program shouldn't have to count the clocks in since MIDIC can do that whilst the main computer gets on with something else (scrolling the graphics display of the musicscore being played maybe). If the program knows that the next MIDI event to be transmitted should actually go in 24 clocks' (1 crotchet) time, it can instruct MIDIC to accept a packet of information consisting of a clock value of 24 (to be counted down by MIDIC as clocks arrive on MIDI In) followed by the MIDI data that is to be sent.

Note that if you don't have a drum machine (or sequencer, or whatever) sending a MIDI clock stream into MIDI In that you can sync up to, and you don't fancy organising such timing yourself, you can instruct MIDIC to use its own internal Tempo Generator thus saving you the bother; the Tempo Generator can be set from 30 up to about 279 crotchets per minute. The clocks thus generated appear exactly as though they had arrived via the MIDI In port and it is therefore very easy to write software that synchronises internally or externally as required under software control. In fact, this is a good example of careful design!

Filtering

As mentioned above it is pleasant to let the MIDIC get on with filtering out any MIDI data that your program is not interested in. Quite simply it saves you having to complicate the logic of your own programs. MIDIC will filter out Active Sensing as we have seen and can also deal with the filtering of Pitch Bend, Real Time, Aftertouch (both Polyphonic and Channel Pressure) and System Exclusive messages upon request.

Another example of careful design is evident in the filtering of Real Time messages which include MIDI clocks. If clocks are being generated internally by the Tempo Generator (so that they can be used to time outgoing messages generated by the computer), then they would be added into the outgoing MIDI data stream so that slave devices can synchronise too. If this onward transmission is not required then MIDIC can cleverly filter out the MIDI clocks it created after it counts them for synchronisation!

CONCLUSION

You may well have gathered by this point that I am already an enthusiastic user of the Hinton Instruments MIDIC interface and my poor old BeeBMIDI interface (the original one I designed) sits dejectedly on a shelf and is never likely to see the light of day again. All I need to swap the interface over from my BBC to my Nimbus computer is an extra lead which I made up myself for a few pounds.

Thanks to the monitor facility and the ease of using MIDIC from terminal emulators, I have seen students catch on to using MIDI in a fraction of the time that one might ordinarily expect. They also managed to write programs to drive a synthesizer via MIDIC within a few hours of starting. The only slight problems that any of us had were cleared up by a couple of phone calls to Graham Hinton who was always most helpful (and genuinely interested!).

However... I have to admit to having a couple of reservations about MIDIC I'm afraid.

To be fair to Graham Hinton, he has designed and built an excellent product which he is continuing to develop - there will be rack-mounted MIDICs, a complete MIDI patchbay system and other professional pieces of kit to come in the not too distant future. His design and software skills, meticulous attention to detail and customer support are all to be complimented - so where's the rub?

Firstly, the owner's manual, whilst pretty good, is occasionally lacking in either breadth or depth and is really written for the expert reader. This leaves some of the interaction of facilities a little less obvious than they might be: the output from the Tempo Generator is in the wrong place on the MIDI Data Flow diagram (Figure 1) which threw me completely (until a helpful phone conversation with Graham sorted things out!). Perhaps the inclusion of some tutorial exercises would help - the novice programmer will need a little leading by the hand!

Secondly, whilst the Event Processor capabilities are useful (and MIDIC was offering these facilities a year or two ahead of the competition!) surely the MIDIC cannot be good value for money unless the 'intelligent MIDI interface' capabilities are being used to the full. The MIDIC really shines in this area and yet I am not aware of any MIDI sequencing software package being available for it. I feel that this is a serious omission which will prevent the MIDIC being as successful as it deserves to be in the 'MIDI using musician' (rather than 'MIDI programmer') marketplace.

Having made these two points I will still end this review by recommending the MIDIC wholeheartedly to 'MIDI programmers'. If you want your programming efforts to be productive and you want to avoid the MIDI housekeeping chores, buffering and timing hassles, then the MIDIC is for you.

When a good sequencing package becomes available, which should be a commercial certainty given that the MIDIC will support the software being ported to other computer systems, then I feel sales of the MIDIC will better reflect the obvious quality of the product.

(Contact Details)