The Programmable Digital Sound Generator (Part 4)
Part 4: Further Hardware Details
The resumption of our series describing the design of Clef Products' new computer music system for the BBC micro, the PDSG. Designer Alan Boothman takes up the story.
Clef Products' computer music system is now reaching the production stage, and this month's editorial resumption sees details of the system's keyboard, among other things. Alan Boothman
The software interface information given in E&MM July could be applied to a wide range of home computers. A page within the memory map of the host will need to be decoded in a similar manner to NPGFD, where +5 Volts represents the inactive state and a zero level indicates that the page incorporating the PDSG is being addressed. The extended page circuitry can be disabled by cutting the track to pin 4 of the extended page gate and linking from that pin to the positive supply on pin 14. The extended page gate is within the package 74LS08, immediately above the 4069 on the lower left-hand side of the board.
The circuitry for the front end of the PDSG is given in Figure 1. Disabling the extended page makes NPGFC redundant, so that the addressing of the PDSG is controlled entirely by NPGFD in conjunction with 1MHzE. The latter is equivalent to 00 in a 6502 system, where address stabilisation occurs whilst 1MHzE is low and data becomes stable during the period when it is high. Combination with the R/W control line results in the RD and WR pulses shown in the diagram which control the PDSG: either read or write operations set up the address latch. It can be seen from the diagram that other signal inversions could be carried out if required. In addition to the lower eight address lines and the data bus, an interrupt request to the host is normally required, although it is possible to program this within the computer, ignoring the interrupt oscillator present in the PDSG. A pulldown reset from the host is desirable but not essential, since its only function is to clear the control register and this can be carried out by programming, ie. write zero to address 128.
Whilst the PDSG can be programmed to operate as an independent sound producing unit, in conjunction with the host computer, a music keyboard unit has been designed which plugs into the auxiliary port of the PDSG, giving a much wider range of application for the system.
The prime design criterion for the keyboard was that it should have accurate touch response, and it was therefore decided to reject simple mechanical approaches - using cut sections of rod or flimsy bent wires in favour of full-length substantial rods which give reproduceable and long-lasting uniformity. A relatively quiet action is then achieved using soft coiled springs, and the scanning order is determined by electronic switching.
The keyswitch is produced in 32-note modules, and up to four modules can be controlled via the PDSG to give 128 two-way switches. The standard keyboard unit is five octaves in length, using half the available capacity, and includes two switch positions dedicated to foot operation. Interlinking of the 32-note modules is via a 17-way bus, allowing easy adaptation to other keyboard configurations, eg. 2½ octaves, 7¼ octaves or two 44-note keyboards plus pedals.
When reading a single five-octave keyboard, the majority of notes will be inactive at a given moment in time so, in order to give a fast scan, it is desirable to detect the unused areas quickly and then remove them from further processing. Consequently, the electronic scan is carried out in blocks of eight consecutive notes rather than spread across the keyboard compass, and in the current software this allows a further split into half-blocks of four notes. This gives a reasonable simulation of the natural positions for two human hands and, on average, reduces the amount of host computer time used in the scanning operation. In the software, it is necessary to cope with switch bounce at both ends of the key travel, carefully defining the onset or completion of a movement, as well as synchronising the touch-counting information to give valid results.
To complete information on the parameters which need to be fed into the PDSG, it's necessary to look at the derivation of the two bytes used to define the frequency of operation of each oscillator. A falling scale of frequencies can first be created by using the formula F=FO/21/12, corresponding to a progressive division by 1.05946309 to produce the next lowest frequency.
In order to pitch the five octave keyboard with middle C positioned as two octaves above the lower end, the top C (note 63) can be given a frequency of 2093Hz. A basic program can be written to carry out both this and subsequent calculations, and it's useful to incorporate a displacement factor in order to obtain different frequency tables for providing a chorus effect. A suggested level of displacement is ±0.5% over the frequency range, and a fixed minimum change of ±1 can be superimposed on the low order byte.
The increment required to produce a particular frequency will vary with the Clock rate, which is adjustable in the range 1.8 to 2MHz. With a 2MHz clock (0.5ps period), each sample for an oscillator occurs every 32ps (64x0.5ps), so an increment of 1 in the high order byte will lead to the 256 count cycling in 8.192ms (equivalent to 122Hz). The formula to derive the increment is I = Fx256x64/Cx106). The top seven bits of the high order byte are used as bits 0-7 in the waveform memory to give a 128 byte cycle from the 256 count so that the lowest bit is the first fractional component. The two bytes can now be split using I1 = INT(I) for the high order byte and I2 = INT((I - I1)x256 + 0.5) for the low order byte.
Sufficient information has now been given to allow advanced programmers to use the PDSG in a complete sound system of their own choice. However, a considerable amount of programming detail is required to translate user requirements into a practical operating scheme, and flow chart instructions will be given later to assist in that process. However, since it would be difficult for readers to follow the detail involved without having a full appreciation of the overall purpose, it is first necessary to define what the system does at the present time.
The present system (referred to from now on as 'Sound System 1') is real time and covers a range of relatively conventional musical instruments, playable polyphonically from a keyboard with velocity-sensitive control. It particularly aims to simulate the subtle dynamic tone changes within this class of instrument and the chorus effect of ensemble playing. However, whilst this gives a multivoice preset machine for immediate live performance, it is assumed that a prime purpose for having the system is to develop one's own sounds. This process is assisted by the incorporation of a single-track digital recording facility which can be used to provide musical data for the instrument under development, allowing the user to change parameters subtly in the instrument specification until the required result is obtained. Development of the instrument can progress with or without the keyboard attached provided that the sequence recorded on the keyboard has been filed for recall. Individual instrument specifications may be filed or recalled at any time and then grouped into sets of 18 for instant call on the computer keyboard.
A typical instrument set is shown in Figure 2 and covers Organs, Strings, Brass, Guitars and Pianos of electric and conventional types. This represents a miscellany which may suit some users but could just as well be regrouped to give 18 preset stops in a classical organ application or 18 preset synthesiser sounds, for example.
Some of the instrument titles indicate that the specifications have been optimised to give the effect of two instruments on the same keybaord eg. 'B & G' (Bass and Guitar), and 'COMBLEC' (Organ without touch plus Electric Piano with touch). This form of instrument development can be very effective, avoiding the limitations imposed by splitting the keyboard with alternative software.
Choice of current instrument is made by pressing the appropriate numeric key with or without the Shift key, and the format of Figure 2 represents the normal display whilst playing the system. Two pedal sustain modes have been adopted in Sound System 1, the first simulating the normal piano sustain action whilst the second cancels sustain for any key held down - a mode that is particularly useful when playing long-sustaining strings.
Keys O, S, C and R enable the keyboard, play the currently loaded sequence, continuously play the sequence, and allow recording from the keyboard respectively. The keyboard remains active on sequence and continuous playback. The current instrument and operating mode are continuously displayed, and the filing and loading of a recorded sequence are both controlled from this display.
Specifying the form of parameters required to define an instrument can be entirely subjective and different types of instruments can benefit considerably from different approaches. For sound system 1, the instrument specification format is as shown in Figures 3 and 4. When an instrument has been selected, its full specification can be called to the screen by pressing key I on the computer keyboard. All parameters are then ready for immediate alteration if required. The instrument shown in Figure 3 has the title 'STRING4T', which is a touch-sensitive version of a string ensemble effect using three logical oscillators per note. By contrast, Figure 4 shows an electric piano using just two logical oscillators per note. A full description of the two specifications will illustrate the computer programming requirements which arose during the development of Sound System 1, and this will be appearing in next month's E&MM.
Feature by Alan Boothman
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!