The Programmable Digital Sound Generator (Part 2)
Part 2: Applying the PDSG
Some typical applications of the Programmable Digital Sound Generator, outlined by its designer, Alan Boothman.
Alan Boothman of Clef Products outlines some possible uses for this new add-on music system for home computers, and explains why the PDSG design should remain well ahead of the commercial synth Held for some years to come...
The first point to note is that the PDSG is very dumb, and once programmed to make a set of sounds, it will continue to do so as long as the CEGB's energy supplies last out. However, an intelligent host computer can, in a very short space of time, write numbers to the PDSG to change its course into more productive territory. The 2ms interrupt period within the PDSG is the shortest time interval between any parameter changes for a logical oscillator, and within the BBC Model B, which uses a 6502A Microprocessor operating at 2MHz, some 1000 computer instructions could be executed in that time. In general terms, the following activities can be carried out by the host computer.
The PDSG requires two eight-bit numbers for each logical oscillator, as described last month. Probably the most efficient way to provide the numbers is to store them in tabular form to be accessed as required, but an alternative is to calculate them and then use a combination of the two techniques for creating glides or vibrato. Chorus can be created by the use of multiple tables based on small differences in frequency between each table corresponding to the same nominal note, even to the extreme where each oscillator has its own table. In practice, three tables have been found to give rich ensemble effects, while a table containing slightly sharp frequencies adds an effective attacking sound to many percussive instruments.
The area of dynamics is likely to be the one which takes up the highest percentage of available computer time, since updating, particularly for percussive sounds, has to occur frequently. Tables are of minimal help when touch response is included in the system, so mathematical operations following both logarithmic and linear procedures are essential. ADSR requirements can vary between different types of instruments and methods of playing, and this is therefore an area which can benefit from flexible programming by the user. Within certain limits, envelope control is arguably more important than wave shape, and the software developed for the system for far has adopted this approach.
Apart from the ability to pan sounds for special effects, the means to direct sounds through separate loudspeakers, combined with frequency separation as outlined last month, results in a chorus effect that avoids the deep electronic phasing produced by direct electronic mixing, leaving the ear to interpret the subtler presentation typical of conventional musical instruments. The definition of spatial position for a particular oscillator is usually a fixed parameter within an Instrument Specification (typically 80-100 numbers stored in the host), but can be enhanced by calculation.
The PDSG allows synchronous transfer of waveforms from the host. Due to the large amount of data involved this is likely to take at least 1.2ms, but in some applications it could be of such importance that the rest of the workload on the computer could be minimised. The alternative approach is to utilise envelope control to define which of the large number of waveforms always available on the board is to dominate the overall sound from moment to moment, resulting in dynamic tone changes.
The most obvious source is a musical keyboard which can be scanned under control of the host computer to determine the position of every key at a given time. As a simple on-off activity, this takes little time to process in the computer and could occur, say, every 10-20ms. However, for a velocity sensitive system (where the practical range of time taken for a key to travel from the up to down position varies typically between 2ms and 32ms) the required touch resolution can only be achieved if the scanning interval is 2ms maximum, giving 16 points which can be weighted to give a non-linear energy characteristic in order to simulate a conventional keyboard action. The software required for this activity can become very time consuming, so efficient programming is essential and more details of this will be given when the keyboard unit is described.
It is desirable to have a number of touch tables in the host, with differing characteristics to be used by individual oscillators within an Instrument Specification, and the tables offer a level of output corresponding to the number of sweeps of the keyboard; these are counted between the detection of a key commencing to move and its achieving the fully depressed position. Utilising a combination of multiple touch curves with oscillators of different harmonic and envelope content, a wide range of instant dynamic tone can be applied to the system in its response to keyboard activity.
Key movement can be translated via software into a series of events which can be temporarily stored in memory and then transferred to other storage media, for later use as raw digital music data capable of playback with the same or different instrumentation. This real time sequencing activity can be either overdubbed or multitracked, depending on the software adopted.
The users likely to benefit from non real time activity range from qualified composers to people who have a depth of musical feel but lack any instrumental technique with which to express it. Since hardware to translate musical ideas into realistic sound has not previously been generally available, it seems certain that not all possible methods of entering musical data have yet been found. A number of programs are available which use the capabilities of various home computers, with or without simple peripherals, based on the input of standard music notation or simulation of music keys on the computer keyboard (see The Gentle Art of Transcription elsewhere this issue), but it is expected that since the PDSG without keyboard leaves a considerable amount of spare computing power in the host micro, a number of alternative music programming techniques will evolve.
The list of possibilities extends to the processing required for auto-chording, harmonising, keyboard splitting, adaptation to teaching aids, lighting control, and so on, but it's hardly likely that all the required software will become available overnight. The important point is that a sophisticated music generation peripheral, based on the flexibility of home computers, has considerably wider capabilities than the units produced for the traditional musical instrument market. The whole character and mode of operation of the system can be quickly altered by feeding in new, relatively low-cost programs as they arise form a wide range of sources, and due to this flexibility, it is expected that such a unit will outlive the lifetime of many of the dedicated digital synthesisers now appearing on the market.
An important motivation in publishing this article in E&MM is to encourage readers to apply their thoughts to the potential of the system, and those with programming skills can put their personal ideas into practice and offer them to others sharing a similar interest.
Feature by Alan Boothman
Previous article in this issue:
Next article in this issue:
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!