BBC Micro Music Masterclass
In this chapter we will expand our range of activities to include the remaining SOUND channels two and three and then carry on to take a look at some further applications of ENVELOPE. It should come as no surprise to you to discover that the use of two or more channels simultaneously brings a number of problems in its stead. How do we go about synchronizing channels? Why is it that SOUND commands apparently act out of sync with screen displays? Over the next few pages we will find an answer to these questions and apply our new-found knowledge to programs such as a polyphonic organ, screen sync and polyphonic melody playing. One of the first new concepts we need to examine at this juncture is the SOUND queue.
Each SOUND channel has a small portion of memory set aside to store up to five SOUND statements. This memory stores SOUND statements in a queue. the queue is a useful device which allows short strings of SoUND state-ments to be executed without holding up a program for the duration of the routine. To clarify this point let us look at the following program:
10 REM QUEUE 20 PRINT"C" 30 SOUND 1,-10,53,50 40 PRINT"E" 50 SOUND 1,-10,69,50 60 PRINT"6" 70 SOUND 1,-10,81,50
At first glance, you might think that when this program is RUN, C will be printed and simultaneously played. Following this you might imagine that E will be printed and accompanied by E SOUNDing, and finally G will appear on the screen at the same time as the sound G is heard.
In fact, this is not the way it happens at all, for C, E and G are PRINTed on the screen before the first note has finished playing. Has the BBC gone loopy? Has it decided to read Lines 20, 40 and 60 before going back for the SOUND commands? This apparent leaping around the program can be simply explained with reference to the SOUND queue.
The machine in fact read and executed the program lines as normal. This is what happens: Line 20 is read and executed immediately. C is PRINTed on the screen. Line 30 is read and executed immediately. The note of pitch C is heard. At this point things do not go quite as expected. Instead of waiting for the note to finish before proceeding, the computer now reads and executes line 40. As a result, E is printed while c is still being heard. Line 50 is then read and the SOUND information for this line is stored in the buffer memory for channel one. This allows the computer to proceed to Line 60, PRINT G and carry on to the final Line, 70. Line 70’s SOUND information also goes into the buffer memory, coming after E in the queue. At this point C E G is seen on the screen, while c is still being SOUNDed. Control of the computer is returned to the user even though E and o are still to come. Since the BBC operates so quickly the initial c notes has not yet ended and the computer continues to play all three notes in the channel one SOUND queue, even though it is possible to type new information into the computer. Only by pressing ESCAPE or BREAK will you find it possible to terminate the sound.
The SOUND queue comes in very handy when you want to play a quick fanfare, of the kind found in a computer game, for example. Providing the number of notes in the fanfare does not exceed five, the program will not be held up. When you come to read the ‘Applications’ chapter, you will see that a number of examples of music which may be used in games are explored.
The program below “Queue 2”, will give you a clearer idea of how the queue works. As it is written “Queue 2” PRINTs READING P% INTO Queue for values of P% from 1 to 6. Since there are then six SOUND commands, one is played straight away and the remaining five are held in the queue, to be played in turn. FINISHED is PRINTed immediately.
10 REM QUEUE 20 CLS 30 FOR P%=1 TO 6 40 SOUND 1,-l0, P%*24, 20 50 PRINT "READING "; P%;" INTO QUEUE" 60 NEXT 70 PRINT "FINISHED!!!"
If we try to add just one more SOUND statement to the queue the program as a whole is held up. Try changing Line 30 to read:
FOR P%=1 TO 7
In this case we find that the ‘READING’ message for each value of P% up to 6
