The computer in our system does not itself generate any sound. It is simply acting as a performer/composer assisting control system for a more or less normal synthesizer. Providing what amounts to an extra set (or several sets) of hands.

From a system standpoint, it fits between the keyboard and synthesizer like this:

We said above, "more or less normal" synthesizer because there are three special elements involved in the synthesizer/computer interface;

1) a digitally encoded AGO keyboard
2) a Digital to Analog Converter
3) a multiple S/H circuit to allow several simultaneous outputs from the Digital to Analog converter.

The computer runs programs (either supplied by PAIA or user written) that receive data from the synthesizer keyboard and issue instructions to the D/A and multiple S/H which in turn control the synthesizer.

PROGRAMMING OVERVIEW

Just saying that the computer controls the synthesizer is hardly a satisfactory explanation of the system. Hardly satisfactory because it leaves out a VERY IMPORTANT CONCEPT which is that it is not really the computer that is controlling the synthesizer, it's the programs. In a very real sense, the computer is there only because it's a way to run the programs.

One of the programs (for example) "reads" the synthesizer keyboard and builds a table of what it finds there.

If the phrase "builds a table" is unfamiliar to you, it simply means that when the program finds that a given key is down on the keyboard it records in a special place (location or address) in memory which key it is. The next key that it finds down, it records in the next memory location; and so on. When the program has finished looking at the entire keyboard the result is a list or "table" of the keys that were down during that scan. If you were holding down a C chord for example, the table might look like this:

That's not really all there is to this program - there are some subtleties that would probably be confusing at this point. We'll get to them later. For right now, we'll just think of this program as a list-builder.

Also, so that I won't have to keep typing "the program that builds the list of keys that are down on the keyboard", we'll agree among ourselves that we'll call this program by the name "LOOK". From now on, when I say something like "we LOOK at the keyboard" you'll know that I mean we "execute" (run) this program.

And, while we're hanging labels on things, we may also just as well name the list that LOOK generates "key-table", or, since I'm a lazy typist, just KTABLE.

Got that? LOOK builds KTABLE.

OK, next.

There is another program that we'll call NOTEOUT, because it takes care of outputting the notes.

Like LOOK, this one can be stated in simple terms: it reads the first entry from a table and causes the D/A to convert that key data to a control voltage which it then strobes into the first S/H. It then gets the second entry from the table, converts it to a control voltage and assigns it to the second S/H. Gets the third entry, etc.

Also, like LOOK, there are subtleties that we'll look at later but the important point is that this routine works quickly. A block of 32 Sample and Holds can easily be refreshed and up-dated in about 16 ms. - more than fast enough.

The table that is read by NOTEOUT we will call the "note-table" or, simply NTABLE.

LOOK builds KTABLE and NOTEOUT reads NTABLE. Maybe you're wondering why two tables - why not just one.

Well, we could do it that way - if we did, a simplified diagram of the system should look like figure c.

You will recognize that we're still holding down that C chord. Now suppose we let the E go. On the next scan of the keyboard, LOOK up-dates KTABLE to reflect the fact that the E is no longer held down. KTABLE now looks like this:

And when NOTEOUT reads this table and up-dates the S/H circuits, guess what? The G has moved to the location previously occupied by the E and from the S/H that previously was producing the control voltage for the G we now have... nothing.

As if it weren't bad enough that the VCO which was previously producing an E is now playing a G (and we can hear when it makes this change), we can't do any decay processing on the E - the way a natural instrument would - because it's not there anymore.

Maybe this isn't too bad. A lot of organs produce results very similar to this - and all multiple output analog keyboards do this exact same "guess where the note's going to come out" trick. Still, it seems that there would be a more pleasing way to do it.

There is.

Because we're using two tables, we can generate a large (very large) family of programs that make decisions on how to transfer the information from KTABLE to NTABLE. This produces a machine which diagrammatically might look like this:

How this new middle program makes transfers from KTABLE to NTABLE determines completely the "personality" of the instrument.

For instance, a better way to handle the multiple-output problem would be to have the "middle" program not delete an entry from NTABLE simply because it no longer appeared in KTABLE, but rather to indicate that while the note should still be played, the key corresponding to it was no longer being held down and decay processing should begin. This is where the concept of "flags" associated with each note comes in and while it is slightly out of sequence, we should examine this important feature now.

The data that goes out to the synthesizer interface is a collection of 8 binary digits (bits - "1" or "0"). Like this:

If we want to indicate to the synthesizer that the note that the data represents is one which currently corresponds to a key that is being held down on the keyboard, then we set bit #7 (D₆) to a "1". If the data does not correspond to a key that is currently down then this bit is a zero. As you can see, if you're already familiar with synthesizers, this flag bit corresponds to the "gate" signal that you get out of most synthesizer keyboards.

This leaves us with a "left-over" flag that can be used in a variety of ways. It can, for instance, be used simply as an independent gate signal allowing the processor to select between one of two patching arrangements that we've set up. Or, and I believe that this is the preferable use, it can be used as a GLIDE SELECT bit that turns glissando on and off - under computer control.

But, to get back to the real subject at hand, the polyphonic output procedure described above is not the only (or, in my opinion, the most) interesting thing that the "middle" program can do.

It can examine the entries in KTABLE and if they are lower than a given note on the keyboard assign them to one group of outputs and if they are higher assign them to a second group of outputs, Which has the effect of "splitting" the keyboard into two different voices - one for low keys and a second for high keys.

The "middle" program can take notes from the keyboard and not only play them immediately, but also store them in another permanent table in the machine's memory for playback again later.

The "middle" program can take notes from the permanent table mentioned above, assign them to outputs and simultaneously assign current keyboard activity to other outputs - so that you can play along with something that was previously "recorded".

These same programs can allow independent recording and simultaneous playback of multiple "tracks". Like a multi-track recording studio only without the hassle of tape splicing, editing and (worst of all) over-dubbing noise.

The "middle" program can do tricks like making a chord played on the keyboard seem to be rising in pitch, constantly, without ever actually going beyond a pre-defined limit. It's not magic, it involves forming a "stack" of the notes and allowing the program to increase the pitch of the notes in the stack until they reach a pre-determined limit at which time the note is "faded out" and placed in the bottom of the stack.

The "middle" program can do lots of different things. So many, that it's going to be a while (possibly a long, long while) before we know what they all are.

If you're looking for something that will reach a "finished" state beyond which there is nothing further to do, this isn't the product for you.

SO MANY "DIFFERENT" PROGRAMS

One thing that you may notice in the discussion above is that all of these very different "resource allocation" schemes have in common the fact that they all use LOOK and NOTEOUT. We could make these two routines a part of each of the larger programs if we wished - there wouldn't be any problems with that - except that they are long-ish and would take a while to "load" into the machine's memory. Particularly if you're not using the computer's optional cassette interface. I think there's a much better way.

We can write the LOOK and NOTEOUT programs so that they're what's known as "subroutines".

Now ordinarily, computer programs proceed sequentially through memory an instruction at a time. Like this:

But a subroutine allows a block of programming to be stored out of sequence in the machine so that when you "call" or "jump to" a subroutine it's like this:

The "return" causes the computer to go back to the place that it was before the subroutine was called and continue executing the main program.

Maybe the "subroutine" concept confuses you (though after such a terrific explanation it's hard to imagine how). If it does, here's another way that you can think of them;

SOFTWARE MODULES

You're certainly used to synthesizer "hardware" modules by now - all those little processing elements (VCO's, VCF's etc.) that we tie together with patch cords to produce different sounds or effects.

Here we have their equivalent in computer instructions - little modules of programming that are patched together (not with wire, of course, with more programming) which, depending on how they're tied together, produce different effects.

LOOK and NOTEOUT are not the only software modules that are useful, others include SAVE (the "recording" module, SREPRO (the "playback" module), DELAY (a time delay routine), POLY (a useful polytonic resource allocation algorithm), and others.

These various modules are available in a number of different forms. They're available just as program listings (which can be manually entered into the computer - very tedious but about as cheap as you can get) or they're also available on cassette tape that can be loaded into the computer using the optional cassette interface.

First choice for a place to save these universally useful programs, though, is Read Only Memory.

This is the most expensive alternative (ROMs have to go for about $20/each - one would be filled by the programs mentioned above) but it has the advantage of NOT HAVING TO LOAD THE PROGRAMS AT ALL. Every time you turn on the machine, they're there, waiting to be used.

SOUNDS INTERESTING WHAT DO I NEED TO GET STARTED?

If you already have some PAIA synthesis equipment, you're well on the way, but you need to convert to the new digital format. We've tried to make that as easy and inexpensive as possible by providing a retro-fit kit to digitally encode your present PAIA keyboard, the EK-3 Keyboard Encoder Kit mentioned in POLYPHONY "Lab Notes" 4/76.

This encoder is primarily designed to fit 4700 series keyboards, but will of course fit 2720 series equipment as well. It is one of our experimenter's kit series and does not include step-by-step instructions.

If you want to start over with a new keyboard, we have the 8782 Encoded Keyboard - one of our full kits with complete instructions.

If you already have an organ and would like to use that keyboard for either synthesizer or synthesizer/computer interface, we have the EK-4 Organ Keyboard Encoder which we will examine in next issue's "Lab Notes".

The advantage to this is that the keyboard already in the organ may be used for both synthesizer/computer and organ - all at the same time. Even if there are no "spare" contacts on the keyboard.

BUT I DON'T HAVE A SYNTHESIZER!

Looking back over the text to this point I notice an important point that has not been prominently mentioned. This system - because of the properties of the D/A - will work only with low-cost LINEAR synthesizer modules. Synthesis modules whose characteristics are exponential cannot be used (though it is an easy matter to substitute another D/A for ours).

It is difficult to tell someone what the configuration of their synthesizer should be. Particularly with modular equipment like our current line. The modules that make up the system are so much a function of the use to which the system is to be put.

Never the less, we have two systems configured as starting points. "Starting points" because it has been our experience that most people add and make changes to their system as time goes on. Customizing it to their application.

These two packages are the 4700/C (primarily a monotonic system) and the 4700/J (suitable for polyphonic work, limited multi-track recording, etc.). These are both systems that we originally put together to take to shows. Each for its intended purpose, they have proven to be reliable and versatile; each capable (by design) of turning someone from an "I don't like synthesizers" person into a "I never realized they could do that" person. Maximum usefulness and versatility within minimum "waste" capacity.

The 4700/C is a minimal, useable system. It has roughly the capabilities of the "mini" this and that that you see advertised. It's made for people who find synthesis interesting but aren't really sure that they're going to get into it in a big way. It is (briefly) an ideal place to start. And since all of our gear is modular and available separately, it is a system which will easily grow as your interest grows.

The 4700/J is by the standards of the industry a good-sized system. It's difficult to make comparisons, since some of the modules (particularly those that are the computer interface) aren't available from other manufacturers; but, if these modules were available and you purchased them assembled through the normal distribution chain the '/J would be on the order of $2,500 to $3,500 worth of equipment. And, again, it's not a dead-end system, but one that can grow.

One final comment in this section is in order, and it may seem strange for someone who is, after all, trying to sell you equipment; DON'T OVER-BUY.

There are two reasons for making a statement like this - both imminently practical; 1) our experience has been that you will probably like the equipment a lot and will be a customer for many years, but if you don't (and aren't) you don't have a bunch of money sunk in something you're not going to use. We won't have someone wandering around bad-mouthing the gear.

2) Without committing to anything in print, development goes on all the time - to the practical synthesist, the versatility of modular equipment makes it desirable to have some of it around (ask anyone seriously involved in electronic music synthesis). But, well, look at any issue of POLYPHONY - development goes on and you never can tell what's just around the comer.

WHICH COMPUTER?

This one is almost as bad as which synthesizer. For the same reasons - the decisions are very personal and user related. Also like the "which synthesizer?" though, we have suggestions.

Our first, and strongest, suggestion is our own 8700 Computer/Controller. High on the list of compelling reasons to select this machine should be the fact that it will have our fullest software support (all of the programs mentioned earlier are available now), it is physically designed to fit into a space that has been kept free in our 4700 and 8700 series keyboards and is a machine designed to the PAIA ideal of "maximum impact for minimum bucks".

The 8700 is based on a 6503 processor (a fully software compatible version of the increasingly popular 6502) and has features as described in the product summary. This processor was chosen over others which were - at the time that the decision was made - more popular for a variety of reasons, but by far the biggest was that it is an easy machine to use. Even if you' re programming in machine language (and don't kid yourself, the day will probably come that you will want to do something completely different - something not available either from us or from the independent user's group program exchange - and the only way to do it will be to write the code yourself, it's easier than it looks).

But let's suppose that you already have a computer. If that computer happens to be something like a KIM-1, you're in great shape. We will shortly have a complete KIM-1 package showing how to interface and almost as complete a selection of programs as for our own machine (we like the KIM series stuff - and since it, too, uses a 6502...)

If you have a SWTP 6800 system, the 8780 and 8782 instructions already outline using one of their MP-L's for interfacing (sorry, no software support from us right now, but surely the user's group will come up with some - Southwest has a really nice, popular system).

Coincidentally, there are other machines that use the 6502 processor for which all of our software is written; if you haven't heard of them yet, you will.

They are:
Commodore's PET (personal electronic transactor) which looks at this point like it will sell in the $600.00 range. Certainly you're all familiar with Commodore - they're an old-line (if there is such a thing) calculator company.

and
Apple Computer Company's APPLE II

We like the APPLE II machine a lot and probably a single glance will tell you why. It not only looks nice and can grow up to be a VERY LARGE system, but it has all the bells and whistles including FULL-COLOR VIDEO GRAPHICS capabilities (vectored, no less). I own one (one of the very first, I'm led to believe) and I can tell you - it's a very impressive system. You will be seeing a system available from PAIA (by October, we hope) based on this true "appliance" computer.

The PAIA/APPLE system is not yet fully configured, but target price is approximately $2,500.