BeeBMIDI Monitor (Part 1)
E&MM's latest piece of MIDI software is a program that intercepts MIDI communication between instruments and displays it on a computer monitor for all to see. Introduction by Jay Chapman.
Introducing a new software package for our BBC-MIDI interface that intercepts MIDI data from instruments and displays it on-screen. Next month: the program listing and how it works.
Welcome to yet another BeeBMIDI extravaganza! As usual, the terrific technical pyrotechnics discussed herein can equally well be applied via a different MIDI interface, or even a different micro, given a bit of effort on your part, so all you Spectrum, IBM PC, Macintosh, Amstrad, ZX81, Casio calculator, and abacus owners can refocus and keep reading.
So, what will the amazing MIDI Monitor program do for you once you've worn your highly-sensitive musician's fingers to the bone typing it in? Well, in essence, you're going to be able to create a sort of T-junction in a MIDI cable, and suck a copy of the MIDI bytes flowing through the cable into a buffer area in the BBC Micro's memory. You can analyse the data later at your leisure. In this way, you can record a reasonably large snapshot of some MIDI communication running at up to 3000 bytes per second, and play it back at a speed more conducive to the functionality of your average eyeball-to-brain configuration (ie. at a speed people can actually read).
Why should you wish to do such a strange thing?
First, simply out of interest in the communication and to gain familiarity with MIDI protocol. Obviously, it's going to be a lot easier to write programs to control a synthesiser using MIDI if you understand what the standard's protocol is. But be warned. Experience gained by observing what happens in practice may well cause your original interpretation of MIDI theory to mature somewhat. In fact, it can quite often be the case that the software you develop eventually does exactly what you thought you wanted it to do, but still doesn't work because you've been labouring under a misconception all this time. Amongst other things, you'll see why pitch wheel and aftertouch data are ignored whenever possible in MIDI recording - one pitchbend can result in hundreds of bytes being sent out over MIDI.
Second, to check that the synthesiser, drum machine, sequencer or computer you're working with really is throwing out MIDI codes in the format you are expecting. Is running status being used? Are active sensing bytes interspersed where you didn't expect them? Or is the manual right about which key number corresponds to the snare drum on your secondhand Gargantuan MegaBongo drum machine? These are the sort of questions you can expect Monitor to help you answer. And if you haven't managed to obtain a list of the MIDI code sequences particular to your synth, you can push buttons on the synthesiser and get a look-in what gets sent over MIDI each time.
Third, BeeBMIDI Monitor makes pseudo-real-time debugging possible. For example, if you have one synth controlling another via MIDI and notes on the controlled synth keep getting left turned on, you'd be able to insert the Monitor into the connection between the synths and search for evidence of missing or corrupted key-off messages. If a particular sequence is of paramount importance, you could easily modify Monitor to commence data capture only when that sequence has been found, or even to replace one sequence with another, or perform other forms of filtering such as preventing some sequences getting through.
Finally, the recording part of the Monitor software is interrupt-driven, and can therefore be configured as a background task gathering MIDI data sent out from a BBC micro that's also acting as a sequencer at the same time. Useful for debugging your own software as it's developing.
Figure 1 shows what is quite possibly the most typical configuration of computer, BeeBMIDI interface and synthesiser(s). In it, the computer might be acting as a sequencer which tells the synthesiser(s) what to play by transmitting suitable MIDI protocol code sequences via the MIDI Out on the BeeBMIDI interface, which the synthesiser receives via its MIDI In port. Further synthesisers could also be controlled by passing the same stream of codes on via the first synth's MIDI Thru port, which simply copies out the data received via MIDI In.
For real-time recording from the first synthesiser, the codes transmitted from its MIDI OUT would be received via the BeeBMIDI's MIDI In port and stored (with timing information) in the computer's memory.
Figures 2a and 2b show how the BeeBMIDI interface would be connected to allow the Monitor software to capture a copy of the MIDI data flowing along a link. Figure 2a shows another typical MIDI arrangement, with one synthesiser controlling another. In this instance, the MIDI Out on the controlling synth is connected directly to the MIDI In on the one being controlled. Thus the BeeBMIDI interface and computer play no part in the communication.
If you wish to monitor the data flow between the synthesisers, all you do is connect the controlling synth's MIDI Out port to BeeBMIDI's In, and BeeBMIDI's Out to the controlled synthesiser's MIDI In. If that description has left you a little confused, the arrangement is shown graphically in Figure 2b.
As we'll see later, the Monitor software running in the BBC Micro automatically passes any MIDI bytes received via its MIDI In straight over to its MIDI Out before storing a copy of the MIDI byte for its own use. Thus the only effect of 'inserting' BeeBMIDI into the original communication path is to introduce a very short delay. So short, in fact, that in the vast majority of circumstances it'll be of no consequence whatsoever, so the Monitor function is effectively transparent. In other words, it does not affect the communication it's helping you to observe.
Figure 3 shows a configuration that's slightly further out of the ordinary. As experienced programmers, particularly those of real-time systems, will know, it's not always the case that a system performs in the manner you expect it to. When part of a MIDI control software package fails to perform correctly, it can be tempting to pore over the listing to try and find the source of the trouble. Sometimes errors can be spotted fairly quickly, but quite often, evidence of what the system is actually doing - rather than what you think it's doing - can be an invaluable aid to debugging. If you have two computer systems (or the right sort of test gear), it isn't too difficult to arrange for one system to monitor the other. However, most micro-owning musicians have only a single system on which to develop MIDI software, so observing software output can become a little more difficult.
In Figure 3, BeeBMIDI's MIDI Out is connected to the controlled synthesiser's MIDI In in the normal manner. The MIDI control software will presumably write a sequence of bytes to the transmit register of the 6850 ACIA as usual, and with luck, the synth will respond more or less correctly. Provided that the synth is correctly copying everything that arrives at its MIDI In to its MIDI Thru, you can monitor the exact stream of bytes sent by 'looping back' the Thru output to the BeeBMIDI's MIDI In port. Every time a byte arrives back at BeeBMIDI, an interrupt is caused and the interrupt routine (described next month) can save the byte into a 'safe' buffer area.
When the event you're investigating has occurred, you stop your MIDI control software and load in an amended version of the Monitor program. This just displays the contents of the 'safe' buffer, ie. it doesn't record into the buffer itself before displaying, as the version shown in the listing does. But then again, you can't see the listing anyway, can you? Just one more little incentive not to miss out on next month's E&MM, I guess.
Part 1 (Viewing) | Part 2
Gear in this article:
Feature by Jay Chapman
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!