Following on from the previous post, we now move on to Data Formats and Data Generation.
The system can play music in up to 8-part harmony, equivalent to 8 separate parts or voices in a choir, and keeps track of the current status of each part. The numerical data for each piece of music are arranged in groups to represent events at successive points in time. Each event usually involves changing the note being played by any one or more of the parts, including muting any of the parts. Following are some examples of three typical events:
|Data Group starting at Address||193||199||200|
|Control Byte||&B4 (180)||&83 (131)||08|
|Significance||Voice||4-note chord||Mute||Bar No. 8|
- Starting at address 193 is the Data Group for a chord, duration 21 time units.
- The Control Byte at 194 has value 180 = &B4, which has 4 bits set (7, 5, 4, 2).
- The voices corresponding to bits (6, 3, 1, 0) will remain unchanged, whatever their previous states.
- Address 199 holds value 131 = &83, which represents a mute of all voices, duration 3 time units.
- Address 200, 201 hold the sequence 00, 08 which represents the bar line at the start of bar 8.
The data group for each event begins with a Duration Parameter, D, a 6-bit number in the range 1 to 63 which defines the length of time that the note or chord in question is to be sustained.
The default value of D is 24 units for a crotchet, 12 for a quaver, etc., although these values are arbitrary – but the inclusion of a factor of 3 facilitates the rendering of triplet rhythms when required.
Next comes an 8-bit Control Byte which acts as a mask defining which part or parts are to be changed. This is followed by a list of N numbers, each in the range 0 to 54, representing the notes to be played. N is the number of set bits in the mask and the sequence of note-numbers defines to which parts they are allocated.
The note value zero indicates that the relevant voice is to be silenced. A Duration Parameter in the range (1 to 63) + &40 indicates that the previous chord is to be maintained unchanged for a further period of time (a tie). A parameter in the range (1 to 63) + &80 heralds a mute, a period in which all parts are to be silenced.
A Duration Parameter of zero represents an Escape Code which is followed by at least one further byte. If this next byte is a number in the range 0 to 240 (&F0) it indicates a bar number in the music – this is ignored by the playing program but is an invaluable aid to editing the data. Values from &F1 to &FF invoke various special functions and may be followed by additional bytes. These functions include setting the Tempo Parameters, marking the beginning and end of repeated passages, implementing octave- and pedal-coupling facilities and marking the end of the piece.
Generating The Data
In the early days, the data lists were compiled and entered into memory manually, which was extremely tedious even for short and simple melodies. Around the same time, Dad was writing a PC-based program originally designed merely to print music in a legible form, and it occurred that it might be possible to combine these two problems. Now, generation of the data begins with a Project in Visual Basic running on a PC under Windows 98. Please stop laughing, there are good reasons for using this ancient machine!
[Left – the PC-based Visual Basic screen for inputting music – very much “me-ware”! – click image for bigger version if you dare]
The programme initially displays a pair of blank staves, plus, in the case of organ music, an additional stave to show the pedal part. Notes are inserted by a series of mouse-clicks to build up a single line of music.
The information displayed is stored in memory merely as the note-values and their co-ordinates on the staves, and each line of music can be saved as a .DAT file. No bit-image files are involved.
The N lines of music required for a given work can be printed out for future reference. The filename for each line of music is constructed from the file-stem, Plus the bar number at the start of that line, thus Bday1.DAT and Bday5.DAT.
About The Voices
The treble clef (normally played by the right hand) contains the Soprano part (tails up). Alto (tails down) and an extra intermediate part (X, with no tails).
Similarly the next stave down (bass clef, normally played by the left hand) supports Tenor (tails up). Bass (tails down) and an additional part (Y, no tails).
When the music has been compiled the order of parts as shown in the Control Byte is from most to significant bit to least: S, X, A, T, Y, B, P, Q. The lower bass clef, where used, is played by the pedals and can contain two parts, tails up (P) and down (Q).
Compiling & Editing The Data
Visual Basic and Windows can now be closed and a compilation program loaded in GWBASIC under MS-DOS. Details of the file-stem (Bday), bar numbers (1, 5) and Folder (Happy) are entered, together with an estimate of the required metronome value in crotchet beats per minute. The compiler then reads each if the .DAT files in turn and processes them into the format required by the BBC program. The complete data list is saved as a .BIN file, e.g. 8HBDAY1.BIN , indicating 8 parts (and 7+ext file name).
[Left – raw data Editor on the PC – click image for bigger version]
Control is now passed to a second program in GWBASIC. This enables the data to be edited and any errors and omissions corrected. In this 8-part PC editor two lines of data, comprising 32 columns or events, can be displayed. Note that a line of displayed data does not as a rule correspond to a line of the printed music.
Various features of the data are indicated by their colours: green (decimal) numerals indicate memory addresses at which the data for each event begins. Red (decimal) numerals are the Duration Parameters. Pale blue (hexadecimal) numbers are the Control Bytes, and the white characters define the note letters and the octaves in which they are situated. The usual range of organ music is from two octaves below middle C (C1-B1, and C2-B2) to two and a half or three octaves above (C3-B3, C4-B4 and C5-F5 in this case).
Pressing any key at this stage of the display causes the lower line of 16 columns to be erased and replaced by cues and space for input statements to make any changes [right – click image for bigger version].
Phrasing in organ music is achieved solely by small adjustments to the duration of selected chords and by short gaps inserted between them. The data as initially compiled will often sound rather bland and boring but can be made to sound more realistic by careful editing at this stage. In particular it is the custom to increase the length of the first note in each bar by one unit, a process carried out automatically by the compiler.
Transferring The Data
[Left: the equivalent Editor on BBC Micro – click image for bigger version]
After the data has been edited it is wise to save it to a different filename, e.g. 8HBDAY2.BIN
A further GWBASIC program is then invoked to transfer the file over a parallel cable to a BBC where it is received and saved by another program. There is also a BBC data editing program but due to memory space constraints it is very limited in scope compared to the PC version & can display only 10 cols or events at a time. The data, now on a lovely old BBC floppy disc, can be taken to the church to be tested on the organ. If necessary, final adjustments can be made there using the BBC editor.
So Why Bother?
In typical geek fashion, the project was originally undertaken to test an idea and see if it could be done. After a few teething troubles were ironed out it has proved extremely versatile and reliable and appears to be capable of playing almost any organ music that can be rendered on a single-manual instrument. It just requires sufficient time and patience in setting up and editing the data.
It now plays most of the voluntaries in the weekly service and has even been used for an evening’s organ recital, raising money for charity. With the aid of a computer-literate assistant, it has occasionally been used to accompany the hymn singing when no organist (Dad) has been available. However, setting up the files for 5 hymns is no trivial task since each verse may need to be differently edited for correct phrasing due to different words.
And now for a short recital… (use http://cazm.eu/ernie3u as a shortcut):
I have often wondered if, instead of spending so much time designing hardware, software and inputting data to the system, Dad had spent the time practicing the organ tunes in the first place, he would be able to play them himself! But that would not have been half the fun!
For more details, see Part 1 (Intro) and Part 2 (Machine Control).