Magazine Archive

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

Lab Notes

Computer Drums

Article from Polyphony, July 1976


Are you ready for a computer peripheral that's fun, instructive, low in cost and provides an impressive demonstration that even your least technically inclined friends can understand? How about this one - a computer controlled drum set.

Yes, there are a lot of automatic percussion units available and yes, they're pretty much a drag. Useful, under just the right set of circumstances, but even then their incessant BOOM-chik-chik can really turn into a BUMMER.

Now, think about computer interfaced drums. You're not forced into using what somebody else thinks is a cha-cha; you write your own rhythm pattern for the specific thing you're doing, even if it's in 7/16 time. And the real world niceties like bridges and intro's? They're simply not possible with conventional electronic drummers. But with drums tied to a computer - no sweat.

If you're interested, we've got a lot of ground to cover; drum circuits, interfacing and programming. Let's get on with it.

Figure 1 - Typical Drum.


DRUM OSCILLATORS



Most drum units generate their percussion sounds using a simple active filter section like that shown in figure 1. There are two ways to think of this circuit. Either it is almost an oscillator which when excited by a pulse "rings" for a short period of time; or, it is a high Q filter section which extracts from a pulse excitation function a single sine wave component. Either of these explanations is valid. Either produces an accurate description of what happens. When you hit the circuit with a pulse it responds by generating a damped sinusoid, which is the electrical analog of the mechanical action of a drum head.

Table 1 - Component Values for Various Drums.


Table 1 shows a realization of this circuit when using one stage of an LM3900 type quad current differencing amplifier as well as the component values required to generate a number of different drum/percussion sounds.

Snare drums and cymbals require a keyed noise source with filtering. Figure 2 shows a circuit that works well for snares - and don't forget that a drum circuit must be used at the same time to produce what is known as the "strike tone".

Figure 2 - Keyed Noise Source


Building a complete drum set is simply a matter of duplicating these circuits for as many different sounds as you require and resistively mixing them all together to a common audio buss.

INTERFACE



There is only one difficulty with using drum circuits like those shown as a peripheral to a computer and that is that the computer is just too fast. Our filter circuits like a triggering pulse that is at least several milli-seconds long whereas the average write cycle of a microprocessor (and we will be playing the drums by "writing" into them) is on the order of a few micro-seconds. This typical response of our drums to a microsecond long pulse looks like this:

As you can see, it doesn't strain even my non-existent artistic abilities.

If you own one of the computers that's all pretty and boxed up, you can refer to a section of your systems manuals entitled "slow peripherals". In the parlance of the field that's what the drums are.

I'm going to assume that you're going to be using someone's low cost "evaluation" unit. And further, that your manuals are typical of most of the ones that I've seen in that they tell you only enough to make sure that your level of confusion is appropriate to this "complex" field. My comments here are specifically for National's SC/MP evaluation kit, but with slight modifications are applicable to most others.

Figure 3 - Drum Interface.


Figure 3 (shown on the following page) shows an extremely simple interface adapter that has performed well for me. As you can see, it's nothing but three packages of quad CMOS NOR gates. Here's what happens.

As I said before, playing the drums from a program standpoint will be a memory write operation from the processors accumulator to the memory location occupied by the drum set. When the program says write (actually STORE) the group of ones and zeros which we will have loaded into the accumulator to produce the drum sounds that we want are put out on the machine's data lines while the address of the memory location into which we are going to write appears on the processor's address lines.

Very shortly after the valid address and data appear on their respective processor lines, the machine issues a WRITE command (in the SC/MP, the NWDS line goes to ground indicating a write). As we shall see shortly, when the machine issues both a write command and the address that we've selected for the drum board at the same time it causes the SEL (select) line on the interface to go high which is buffered by gates G1 and G2.

The output of G2 is coupled by the time delay circuit R1 and C1 to the input of G3. The output of G3, which was in a high state, switches low as soon as the SEL line is activated and produces two major results. First, any of the data lines which have a zero on them, when NORed with the output of G3, will cause the outputs of their respective gates (G4-G10) to change state. These gates changing state causes the drum oscillator attached to that gate to sound.

Also, the output of G3 is routed back to a pin on the processor called NHOLD. This is an interesting input to the processor, because when this pin is grounded it causes the machine to STOP with the data and address lines held in the same state they were in when the hold command was issued. This has the effect of latching the address and data lines of the processor for as long as NHOLD remains low (a time determined by the R1, C1 time constant) and serves to stretch the micro-second write cycle out to the few milli-seconds required by the drums.

We need to discuss programming some, but before we do let's consider for a moment which memory location(s) we want the drum set to occupy. If you are using one of the larger systems by SWTP, IMSAI or MITS (or even some smaller systems such as the F-8), the problem is academic. These machines have provisions for output ports and you will use them - why fight the system. In these cases the SEL and NHOLD lines can be used for the handshaking "data ready" and "data accepted" lines respectively.

On smaller systems you will want to base your decision on what the cost (both financial and emotional) will be of using a specific location or group of locations. May I make a suggestions that might not occur to you otherwise? Use the same group of addresses that is occupied by whatever ROM your system has. This is not "ordinary" (you never write into the ROM locations with the usual programming because it won't do anything - they're Read Only Memory) but, there's nothing wrong with it and they have the tremendous advantage of being locations that are already decoded. On the SC/MP this is accomplished as shown in figure 4.

Figure 4 -SC/MP Address Decode.


PROGRAMMING



There's another big plus to using the ROM locations as an output port, this one from a programming standpoint. And we're both going to have to go slowly here because it can be confusing otherwise.

ROM, even in minimal systems, represents a chunk of memory - ordinarily at least 256 bytes. This means that in a machine like the SC/MP, which has 16 address "lines" (some are multiplexed onto the data bus, but forget that) only the most significant 8 bits are required to address the output port.

Most machines have a scheme of addressing memory which is referred to as "indexed" and they have, internally, one or more 16 bit wide "index" registers that can be used to "point" to a specific memory location. Since most of the processors used by hobbyists work on only 8 bits of information at a time it is obvious that it will take two "groups" of instructions to load the 16 bits into the index register - one "group" to load the "low order" 8 bits and a second "group" to load the "high order" 8 bits. But if we're using 256 bytes of memory occupied by ROM as a single output port, we don't have to worry about the low order 8 bits, they can be anything and we will still be addressing the output. Since they can be anything a still work, we don't have to worry about loading them and as a result we've saved at least three ( and probably much more in a complete program) lines of program code.

Programming for the drums can be as simple or elaborate as you like. Regrettably, there is sufficient space here for only a few tips. The instructions for the experimenter's kit goes into much greater detail with sample program listings for a variety of machines.

Let me point out a few hardware considerations that will affect programming. Each bit of data in the accumulator at the time of the write operation will determine whether a specific drum sounds or doesn't sound. A typical coding arrangement was shown in figure 3 and with this arrangement the drums would be coded like this (remember that a 0 sounds the drum).

drum sound binary hex octal
heavy bass 11111110 FE 376
light bass 11111101 FD 375
snare 11111011 FB 373
tom-tom 11110111 F7 367
conga 11101111 EF 357
clave 11011111 DF 337
woodblock 10111111 BF 277


This is confusing. It would be much easier if when we were programming we could just write a 1 for the drum we want to sound. We can do that if we write a program flow that reads a byte of drum data but before writing it to the drums does an Exclusive Or Immediate with FF16. As many of you will realize, this has the effect of complementing every bit of data so that the drum sounds we want can be written in memory in this more logical form:

drum sound binary hex octal
heavy bass 00000001 01 001
light bass 00000010 02 002
snare 00000100 04 004
tom-tom 00001000 08 010
conga 00010000 10 020
clave 00100000 20 040
wood block 01000000 40 100


This is particularly easy if we want to sound two drums simultaneously; for example a heavy bass down beat and a snare drum at the same time would be in binary 00000101 (0516) (0058).

For very simple repeating patterns, this complementing action even has an advantage in that we can use FF16 as a repeat indicator that is stored along with the drum data. Program flow would be 1) load drum data, 2) complement (XOR IMM. FF16), check for zero (11111111 complemented is 00000000) and if zero start again, 4) if not zero, write accumulator to drums, 5) delay (tempo) 6) get next data and go to 2.

Various machines have an amazing variety of ways to test the accumulator (test for: zero, not zero, pos., neg., carry, overflow, etc.) but one thing they all have is a test for zero.

Notice that the 8th data bit in the arrangements that I've shown does not have a dram associated with it. There are two reasons, first, we've got a bunch of drum sounds already and secondly, we can use that 8th bit in our programming as an indicator that the data we've loaded is not to be played as drums, but to be interpreted as an instruction. A simple example would be to suppose that we have a rhythm pattern we wish to play 16 times and then stop. We can use a program based on the flow chart shown in figure 5 to accomplish this. Notice that in this case the program reads the drum data, tests to see if it is in fact an instruction, and if not plays it. When it does get to the byte that is the instruction it decrements the "count", saves the data back in the location it got it from and iterates the pattern. On the last pass through the program the decrement operation on the "instruction data" results in the last seven bits being 0, which tells the machine that it is through (or to go to the next pattern, or whatever). There are, of course, as many ways to handle this as there are people to write programs.

Figure 5 - Program Flow Chart using 8th drum data bit as instruction indicator.


Looking back over this I can see that for some I will have covered a lot of ground in not quite enough space to make it all clear. To others I will have said nothing that wasn't already obvious. If you're in the first group, think about the experimenter's kit. I have a lot more space there.

If you're in the second group, hang in there - next time we're going to look at D/A converters with an eye toward full computer synthesizer interface. I promise, some of those things are not obvious at all.

EK-2 Computer Drums Experimenter's Kit - kit consists of circuit board and all parts necessary to build the interface and drum circuitry described in this article. Includes more detailed analysis and sample programs for a variety of processors including SC/MP, 6800, 6502.

EK-2 COMPUTER DRUMS $19.95 plus $1.00 postage & handling



JOHN'S CONTEST - RESULTS



You may remember that we had a contest in the last issue to find an easier way to design the "Tracking Top-Octave" circuit that I had shown in Lab Notes. Everyone who was interested enough to enter received a copy of the "correct" answer and the contest was won by David Harper of Houston, Texas.

Unfortunately, along with piles of entries, we also received a copy of a patent that pretty accurately described where we were headed. As of this writing I have not been able to negotiate an acceptable licensing arrangement, so I guess that this will not be a new product any time soon.

The correct answer is:

The divider shown in Lab Notes is not needed. The top octave chip is already a divider.

Could look like this:


Switch selects octave above or octave below VCO reference.

I want to once again thank everyone who entered. As I said in my letter, the next time we have a contest, all correct entries are going to go in a barrel and we'll choose one. The Post Office's handling of the mail makes a "first correct entry wins" contest impossible.


More from these topics


Browse by Topic:

Computing

Electronics / Build



Previous Article in this issue

Patches


Publisher: Polyphony - Polyphony Publishing Company

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

 

Polyphony - Jul 1976

Donated & scanned by: Vesa Lahteenmaki

Feature by John Simonton

Previous article in this issue:

> Patches


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 March 2024

Please note: Our yearly hosting fees are due every March, so monetary donations are especially appreciated to help meet this cost. Thank you for your support!

Issues donated this month: 0

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

Funds donated this month: £208.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