Davis, Stephen A. (Wappingers Falls, NY)
Dougherty, Keith H. (Peekskill, NY)
Levit, Alan D. (Poughkeepsie, NY)
Hendrickson, Thomas A. (Poughkeepsie, NY)
Sanderson, Kenneth R. (Wappingers Falls, NY)

05/430458

12/16/1975

01/02/1974

Download PDF 3926088       PDF help

Click for automatic bibliography generation

International Business Machines Corporation (Armonk, NY)

84/462

178/30, 84/645, 84/477R, 984/304, 84/723

G09B15/04; G10H1/00; G09B15/02; G10G3/04

84/1.01-1.03,1.28,DIG.29,115,461,462,464,477R

3683096	ELECTRONIC PLAYER SYSTEM FOR ELECTRICALLY OPERATED MUSICAL INSTRUMENTS	August 1972	Peterson et al.
3697661	MULTIPLEXED PITCH GENERATOR SYSTEM FOR USE IN A KEYBOARD MUSICAL INSTRUMENT	October 1972	Deutsch
3733593	CAPTURE COMBINATION SYSTEM	May 1973	Molnar
3746773	ELECTRONIC ORGAN EMPLOYING TIME POSITION MULTIPLEXED SIGNALS	July 1973	Uetrecht
3763364	APPARATUS FOR STORING AND READING OUT PERIODIC WAVEFORMS	October 1973	Deutsch et al.
3771406	MUSICAL INSTRUMENT WITH DIGITAL DATA HANDLING SYSTEM AND LIGHTING DISPLAY	November 1973	Wheelwright
3781452	METHOD AND APPARATUS FOR ASSEMBLING RECORDINGS OF MUSICAL SCORES	December 1973	Vauclain
3789719	TAPE ACTIVATED PIANO AND ORGAN PLAYER	February 1974	Maillet
3809786	COMPUTOR ORGAN	May 1974	Deutsch
3809788	COMPUTOR ORGAN USING PARALLEL PROCESSING	May 1974	Deutsch
3809789	COMPUTOR ORGAN USING HARMONIC LIMITING	May 1974	Deutsch
3809790	IMPLEMENTATION OF COMBINED FOOTAGE STOPS IN A COMPUTOR ORGAN	May 1974	Deutsch
3810106	SYSTEM FOR STORING TONE PATTERNS FOR AUDIBLE RETRIEVAL	May 1974	Nadler et al.

Hartary, Joseph W.

Witkowski, Stanley J.

Goldman, Bernard M.

What is claimed is

1. In combination with a data processing system:

2. In combination with a keyboard instrument:

3. In combination with a data processing system:

4. In combination with a data processing system:

5. The combination according to claim 4 including means actuable repetitively by a musical performer at said keyboard for providing repetitive electrical signals to said data processing system, which signals correspond to the rhythm maintained by said musical performer; and

BACKGROUND OF THE INVENTION

Field of the Invention

The invention relates to data processing systems, and more particularly to the specific application of a data processing system to the creative and educational aspects of the performing arts.

For decades, computers have solved man's business and scientific problems as an extension to his reasoning ability, freeing him to actualization of his creative self.

The present invention concerns itself with the artistic side of Man's creative spirit, in particular, the creation of music.

Computers have been attached to musical instruments in the past and have been programmed by translating the musical score into computer language so that the computer can control the keys on the instrument and thereby reproduce the programmed music. Therefore, the information stored in the computer can be played back through the instrument. For example, a deck of cards can be read into a card reader and an organ attached to the reader will play the music that has been punched onto those cards, much in the same way that a player piano interacts with the holes punched in a piano roll. Furthermore, the cards can be created by playing the instrument and then playback is accomplished by again reading the cards thusly created. Further, in the past it was possible to provide a time-line output which corresponds to a series of lines on a cathode ray display tube. The lines correspond to the computer data that is created by depressing the keys on the organ.

However, it has not been possible to refine this data to provide a graphical output in music notation. This requires an interpretation of what the artist played and the translation from the time-line output to the graphical input data to thereby produce data in musical notation.

Furthermore, in the prior art, the problem of rhythm has not been solved so that the true interaction of the artist with the computer can be realized, that is, so that the appropriate analysis of the rhythm provided by the performer in cooperation with keys depressed can be made.

It is therefore a primary object of the present invention to provide a means for translating a musical performance into computer language and from computer language to a graphical display language suitable for storage, printing or display.

It is a further object of this invention to provide a means for the real time display and/or playback of a musical performance on a musical instrument.

It is a further object of this invention to provide means for translating elementary sensor data derived from playing a musical instrument to an intermediate data suitable for printout to provide analysis of the performance.

It is a further object of this invention to provide means for translating elementary data corresponding to music played on a musical instrument to musical notation including clefs, time and key signature, notes, stem direction, beats per measure, and other musical forms.

Briefly, the above objects are accomplished in accordance with the invention by providing, in combination with a data processing system, apparatus for converting electrical signals produced by depressing keys on a musical instrument to first data manifestations in a format suitable for processing by the data processing system. Further means are provided in the data processing system for translating the first data manifestations into second data manifestations in a format suitable for printing, displaying or storing the data in musical notation.

In accordance with one aspect of the invention, synchronization between the performer who is actuating the keyboard and the computer internal timing is maintained by means of a foot pedal switch adapted to be actuated during the actuation of the keyboard during the musical performance. This provides appropriate electrical signals corresponding to the rhythm maintained by the performer which can be interpreted along with the data derived from the keyboard keys for analysis of the inter-relationship between the two by the computer.

The invention has the advantage of providing instantaneous interaction between the performer and the computer so that the performer can see his creative efforts in a musical notation familiar to him on a real time basis. This has the advantage of permitting the rapid and accurate transcription of creative thought while the creative inspiration is still present. This relieves the artist of the details of musical notation and transcription so that he is free to create.

The invention has further advantages as an educational tool wherein the intermediate data forms produced during translation within the computer can be printed out at an intermediate stage to thereby provide raw data for analysis of performing technique.

DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of the invention will be apparent from the following detailed description of a preferred embodiment of the invention, as illustrated in the accompanying drawings wherein:

FIG. 1 is an overall data flow of the various phases of the operation of the computer apparatus within which the invention is embodied;

FIGS. 2A- 2C comprise a composite diagram of a more detailed data flow of the invention shown in FIG. 1;

FIG. 3 is a diagram showing the interconnection of FIGS. 2A, 2B and 2C;

FIG. 4 is a chart showing the relationship between the various commands and the data level associated with those commands in the data processing system;

FIG. 5 is a block diagram of the data and control circuits for connecting a musical instrument to a data processing system;

FIG. 6 is a more detailed circuit diagram of the data flow circuits of FIG. 5;

FIG. 7 is a more detailed block diagram of the control circuits of FIG. 5;

FIG. 8 is a timing diagram showing the inter-relationship of the various control lines of FIG. 6 and FIG. 7;

FIGS. 9- 22, 29, 30, and 31 are a flow diagram of the command and I/O phase portion of the data flow of FIG. 1;

FIGS. 23- 28 are a flow diagram of the translate phase of the data flow of FIG. 1; and

FIGS. 32 and 33 are a flow diagram of the artwork phase of FIG. 1.

DESCRIPTION

Introduction

FIG. 1 is an overall block diagram of the data flow of the computer system within which the invention is embodied. Data is inputted from the organ 10. When the performer depresses keys on the organ a switch is closed for each key causing electrical signals representing musical notes to be sent to the computer. Operator commands (i.e. requests for the execution of a particular program) are entered into the computer system by means of a control keyboard on the organ or a separate input/output terminal. For example, the user may make a basic request such as "Picture" by means of the picture command. As described subsequently, the picture command invokes programming (FIG. 1, block 12) to output on a display data produced by playing the organ. At the command and I/O phase block 12, the output from the organ, which is data in the elementary form of a signal for each key on the organ which has been depressed, is translated by the module 12 to produce data which will be referred to as a time-line output 14. With the appropriate Print command entered by the user, the time-line output may be printed out to provide hard copy. The time-line output enters the translate phase block 16 which is activated by a Translate command entered by the user. The Translate command translates the data from block 14 into a programming graphical input language module at block 18. The result is an intermediate form of data which may be printed out. The intermediate form of data is entered into the artwork phase 20 which converts the intermediate data to the final output sheet music data which can be printed out or displayed.

The above overall description of the different data levels will now be described in more detail with respect to FIGS. 2A, B, and C.

Referring to FIG. 2A, the following functions occur. (1) The type init Program module 25 is called which sets the terminal up to receive messages and input commands to the computer. (2) The user enters a request into the terminal. (3) The scan request routine 26 is called. The scan request routine decodes the user's request and, (a) sets switches for the command language module; (b) checks the syntax; (c) sets up defaults; (d) saves the data set, and (e) if the user entered "delete" deletes entries 28 or 30. The scan request module 26 returns to the command phase module 24 at this point. The command module, in the final step (4), tests the switches which were set by the scan request and depending upon the setting of these switches, calls the appropriate routine.

A. translate Command

If the translate switch is on (A), the translate phase is entered, the wait bit is turned on and the translate module 32 is entered. In the translate module, the music grid is set up showing, (a) the key and (b) the notes in the key. The GETDAX module 34 is called which sends samples received from the organ to the translate module. The samples are processed measure-by-measure until the last sample is received at which point the translate module returns to the command language module and the translate phase is completed.

B. play Command

If the user's entry is Play (B), the translate module 32 may or may not be called depending upon the option entered with the Play command. If the translate option is entered, the translate module 32 is entered and the process proceeds as described above.

If the option 2 KDIO is indicated under Play, the KDIO module 36 is called. See FIG. 2B. This module opens the input data set checks the code for 1) write, or 2) read, and returns to the command module. The READDACS module 38 is then called. This module 1) sets up the interval sample which indicates the amount of time between each sample on the organ and 2) saves the data derived from the input samples which are taken from the organ. After a stop command is detected, the READDACS module 36 returns to the command language module.

Option 3 of the Play command is the save option. This allows the user to save the data acquired within module 38 for future use. This is accomplished by calling the servo 2 module 40 which stores the data from the organ in a save data set.

C. dump Command

The Dump command causes the calling of the servo 4 module 42 which retrieves the data from the SPAD for printout. The data printed out is the SPAD data output which is an intermediate form of data.

D. picture Command

The Picture command causes the calling of the servo 1 module 44. This module retrieves the data produced by the READDACS module 38 (save data) which was produced by playing the organ and prints the data on the printer. This is an elementary form of data output.

E. organ Command

This command calls the organ module 46 which takes the save data produced by the READDACS module 38 and writes this data to the organ which causes the data to be played back on the organ.

F. print Command

Referring to FIG. 2C, the Print command (1) causes the KTITL module 48 to be called which module causes the title of the composition to be put out in storage 60. (2) The Print module then calls the klef module 50 to put out the klefs, the treble clef and the base clef. (3) The Print module calls the KTIME module 52 which puts out the time and key signature. (4) The print module then gets the first measure and (5) calls the BLDIDX to build spacing layout of the first measure which begins the outline of the first measure. (6) The Print module calls the KXLOX and the KXADJ modules 54 to set up the note values. (7) The print module then calls the KTYPE module 56 which establishes the stem direction.

The print module then analyzes the data to determine the effect of the time signature on the values of the notes in the measure. This is accomplished by the FPLOT module 58 which modulates these values so that each bar contains the exact number of beats which are indicated by the time signature. This is accomplished in steps 8- 11 which calls out the bars, prints the measure, gets the next measure by looping back to step 5 and finally, in step 11, outputting the completed composition to the device, either a printer 62, disk 64, or display 66. FIG. 3 correlates FIGS. 2A- 2C.

What has just been described can be summarized with respect to FIG. 4. The left-most column of FIG. 4 shows each command which may be entered by the user the remaining columns show the data levels associated with the commands.

The translate command (TRANS) uses the save data which is elementary data as input and outputs SPAD data which is intermediate data as an output.

The play command takes the input from the organ and outputs save data or elementary data.

The dump command takes the SPAD data, or intermediate data, and dumps it to the printer as output.

The picture command takes the save data, which was played by the organ, and outputs it onto a display.

The organ command takes the save data as input and outputs this data to the organ as a playback.

The print command takes the SPAD data, intermediate data, and outputs music data to the output device, a printer, disk, or display unit.

DETAILED DESCRIPTION

The following is a detailed description of a computer system in which the invention is embodied.

Referring to FIG. 5, an overall block diagram of the apparatus embodying the invention is shown. An organ 70 is attached to a computer 88 which may be, for example, an IBM System/360 Model 50 computer, described in IBM/360 Model 50 Functional Characteristics (Form No. GA22-0898) and operating procedures (Form No. GA22-6908). The organ is attached to the computer through an IBM 2701 Parallel Data Adapter (PDA) 86 more fully described in IBM 2701 Data Adapter Unit, Principles of Operation, Form No. A22-6864; Original Equipment Manufacturers Information, Form No. A22-6844. The above manuals and other related manuals can be obtained by contacting any IBM branch office.

The organ 70 may be, for example, an organ of the type known as the Schober Consolette II organ manufactured by the Schober Organ Corporation, 43 West 61st Street, New York City, 10023, and described in "How Schober Organs Work" by Richard H. Dorf, and the Schober Electronic Organ service manual, Percussion Group (No. 24PN4SM, 1967) which may be obtained by writing to the above address. The organ has the percussion option modified with respect to the organ key contacts and the organ keying circuits as described and shown in FIG. 5. These modifications break away the 64 lines from the organ contacts 74 which normally drive the organ keying circuits 78 and data flow circuits 82 are placed in series with these contacts. In addition, a foot pedal switch 76 is added to accommodate an additional foot pedal at the organ, the purpose of which is to provide timing to the computer. The organ keying circuits 78 drive the organ sound system 80 to produce sound in response to depression of the organ key contacts 74.

The data flow circuits 82 are more fully described in FIG. 6. The data flow circuits 82 are connected to control circuits 84 which, in turn, are connected to the PDA 86. The control circuits 84 are more fully described with respect to FIG. 7. Briefly, the data flow circuits and control circuits provide for scanning of the organ key contacts and inputting the bytes of data which are the results of this scan to the PDA which, in turn, converts the bytes into Data words which are an input compatible with the computer 88. Various demand and response lines are required by the PDA and these are interfaced with the organ by means of the control circuits 84.

Referring now to FIG. 6, the data flow circuits will now be described. The data flow circuits perform two basic functions. The first is to capture the closure of the organ key contacts, which close whenever a key on the keyboard is depressed, to present that information to the computer and secondly, to take information from the computer and drive the organ keying circuits for playback.

The 64 lines from the organ key contacts drive the input to a buffer register 90 which is split up into four words, 16 bits each, in order to be compatible with the parallel data adapter. The output of the buffer register 90 is connected to drivers 102 which drive the organ keying circuits and also to a data selector which is comprised of gates 98 and a decoder 100. The output of the data selector is 16 bits wide and drives the parallel data adapter.

An input to the buffer 90 is supplied by the output from a demultiplexer which is comprised of gates 92 and a decoder 94. Each of the four sets of gates 92 supplies a 16 bit wide output which is wired to each of the four sets of 16 lines from the organ key contacts. Thus either the organ keys or the demultiplexor supplies 16 bit words to buffer 90. The input to the de-multiplexer is 16 bits wide and is connected to the output of the parallel data adapter.

A and B pulses are derived from the control circuit of FIG. 7 described subsequently. The A and B pulses provide a count of four corresponding to 00, 01, 10, and 11. During a write operation, the write select line is energized, activating decoder 94. The decoder 94 decodes the A and B input to select one of the sets of gates 92 to thereby provide four words of 16 bits each from the PDA to be stored sequentially in word 0, word 1, word 2, and word 3 of the buffer register 90. The buffer register drives the organ keying circuits by means of drivers 102.

During a read select operation, the decoder 100 is activated and decodes the inputs A and B which select one of the four sets of gates 98 to thereby provide the contents of buffer register 90 to the PDA in a series of four words of 16 bits each. Thus, first word 0 is presented to the PDA, then word 1, followed by word 2, and finally word 4.

Timing controls 96 are provided to decode the pulses A and B to provide lines G0, G1, G2, and G3 to the corresponding sections of buffer 90, that is, words 0, 1, 2 and 3 respectively. The pulses G0, G1, G2 and G3 are held up when the organ playback switch is off and the playback line is negative. In this condition, the outputs of buffer 90 follow the input.

During a write operation, single shot SS1 generates the G0, G1, G2, and G3 pulses.

Referring now to FIG. 7, the operation of the control circuits will be described. In FIG. 7, logic blocks labelled "I" are inverters which change a DC voltage of one polarity appearing at the input of the inverter to the opposite polarity. Reference should be made to the timing diagram of FIG. 8 which shows the relationship between the various inputs and outputs of the control circuit. The write select, read select, write ready, and read ready lines are generated by the IBM 2701 Parallel Data Adpater. The write ready and read ready lines are ORed together in OR circuit 104 to provide the ready line. The ready line fires a single shot 106, the output of which drives word counter 110 and provides an output SS1 to the data flow circuits of FIG. 6. The fall of single shot 106 drives a single shot 108, the output of which drives counter 116.

Both counters 110 and 116 are held reset and are released when either write select or read select becomes positive thereby causing an output from OR circuit 105 causing the output not any select to drop and thereby release the counters.

The purpose of word counter 110 is to provide binary outputs which are decoded by the data select circuit 112 or 114. The circuit 112 derives four pulses from the output of single shot 108 to provide a read demand signal which passes through OR circuit 118 to become the demand signal to the PDA. Therefore, during a read select operation, four pulses are provided corresponding to each of the four words to be transferred to the PDA.

The decoder 114, on the other hand, only decodes three pulses from the output of single shot 108 to provide three write demand pulses whenever the write select line is positive. These pulses also pass through the OR circuit 118 to become the demand to the PDA. During a write operation, the fourth word is transferred by means of the EOR -- end of record pulse provided to the PDA.

The purpose of counter 116 is to provide binary outputs A and B which drive the data flow circuits of FIG. 6. These pulses provide energization for the gates which gate the four words to or from the PDA depending on whether it is a read or write operation. A count of four is derived from the counter 116 to produce the EOR pulse. The AND circuit 120 is energized when the demand line is negative and a count of four is positive thus providing the fourth and final pulse on a write operation.

The operation of the data flow circuits of FIG. 6 and the control circuits of FIG. 7 will be summarized with respect to the timing diagram of FIG. 8. The ready line rises when the write select or the read select lines are made positive and stays up until the PDA receives a signal on the demand line during either a read operation or a write operation. Single shot 1 is fired by the rise of the ready line. The rise of single shot 1 output advances counter 1 from the 00 state to the 01 state. Single shot 1 generates the G0 pulse which provides the latch set gates during write for the buffer register 90 of the FIG. 6.

Single shot 2 is fired by the fall of the output of single shot 1. The fall of single shot 2 advances counter 2 and gates the demand pulse to the PDA. Counter 1 controls the data selector circuits 112 and 114 to pass an SS2 pulse through to create the demand pulse to the PDA.

Counter 116 generates the A and B controls for the data selector 98 and de-multiplexer 92 in the PDA data path shown in FIG. 6.

The counters are held reset when neither read nor write select are up.

The end of record sequence is as follows: (1) EOR comes on late in the fourth cycle during a read or write operation; (2) this causes the read or write select to drop; (3) the drop of select resets the counter 116 which in turn, (4) terminates the EOR.

The G0, G1, G2 and G3 pulses are held up when the organ playback switch is off. The latch outputs of data buffer 90 follow the inputs when in this condition. The playback switch must be off when recording into the computer.

PHASE = COMMAND LANGUAGE (FIGS. 9-22)

The command module sets up entry points to the service routines which are going to be called during the course of the processing shown at block 300, FIG. 9. The service routine TYPEINIT is called (block 302) to open the terminal to accept input from the user. At this point a WTO request is sent to the terminal asking the user to input a command which will then be processed (block 304). At block 306 a scan request call is initiated by the command module. The scan request module (SCANRQST) scans the user input to determine whether the command is valid or not. This is shown at FIG. 12.

At block 404 on FIG. 12 the first character is scanned to determine whether it is alpha-numeric. If no, a message is sent to the user's terminal which says that its entered an invalid request and return is to the beginning of the command module. Another WTO is sent to the terminal. Block 406 shows that the scan request module then initializes switches and defaults which will later be filled in with the data depending upon what command the user has entered.

Block 408 is a decision block where the scan request module tests to determine if the request is in a table of valid commands. If no, a message is sent to the user's terminal showing that the user has made an invalid request. If yes, it must be determined which command has been entered. If the exit command was entered (block 410), the scan request module determines if a dump was requested. If a dump is requested, an abend call is generated at block 412.

The abend module is a service routine provided in the operating system. Control at this time is returned to the operating system under which the user is running. If a dump was not requested, then control is immediately returned to the operating system under which the user is running.

If the command is Picture, block 414, the scan request module sets the Verb switch equal to Picture. Then it determines whether Picture has further attributes, block 416. If it does not, a message is sent to the user's terminal saying that he has entered a command which contains invalid syntax, block 418. If a Picture command has attributes, then the scan request module saves the member name, block 420, and scans for further attributes, block 422. If the Picture has futher attributes, then the user has made some error and the invalid syntax message is sent to the user's terminal. If there are no more attributes, then control is returned to the caller which in the case is the command module, FIG. 9.

Referring to FIG. 15, if the user's request is Play, the scan request module initializes the time interval as a default of 10 milliseconds. In other words, the sampling interval at the organ is every 10 milliseconds. This is shown on FIG. 15, block 902. Then the verb switch is set equal to Play, block 904.

A scan is set up for the next key word in the command shown at block 906. If the first letter is not alphabetic (block 908), the message "key word not in table" is sent to the user again returning control to the command module (block 910). If the first letter was alphabetic, then a key word scan is set up (block 912).

If the key word is SAVE, the verb switch is tested, FIG. 17, block 1100. If it is not Play and it is not Trans nor Dump (block 1102), then the message "invalid combination of key words" is sent to the user and control is returned to the command module.

If the verb switch is Play (block 1100) and the option is not specified (block 1104), the I/O SAVE switch is set (block 1108). An equal sign is searched for, block 1110. If an equal sign is not there (block 1112), the user has defaulted the SAVE name to Temp. If the equal sign is there, the data set name is saved in Save Name (block 1114), a location in storage and the scan is continued on FIG. 22, block 1606. The next letter is scanned (block 1608) and if it is a comma, the user has again entered an invalid syntax and control is returned to command module. If it is not a comma, and it is a right parenthesis (block 1610), all files are closed (block 1612) and return is made to the caller. In this case, the command module. If it is not a right parenthesis, the user has made another error. The invalid syntax message is sent and control is returned to the command module.

If the key word is SPAD, FIG. 18, block 1202, the verb switch is tested to see if it is set to play. If it is, the user has made another error and an invalid syntax message is sent. If it is not play, it is tested for Trans. If it is Trans, block 1204, the I/O SPAD switch is set equal to write, block 1206. If it is not Trans, it is tested for print or dump, block 1208. If it is not print or dump, then an invalid combination of key words message is sent and return is made to the command module. If it is print or dump, then the I/O SPAD switch is set equal to read, block 1210. After setting the I/O SPAD switch, the attributes are tested (block 1212). If there are no further attributes, then an error has occurred. Invalid syntax is sent to the user and the command module receives control. If there are attributes, the SPAD name is saved and the scan will be continued, block 1214. The scan is continued at FIG. 22 and again a comma is checked for and if it was a right parenthesis all files are closed and return is made to the caller.

If the key word is PICTKEY, (FIG. 15), the verb switch is tested for play, block 1300, FIG. 19. If it is not play, an error has occurred and the message invalid combination of key words is sent to the user. If it is play, but there is no option specified, block 1302, the verb switch is set equal to Picture (block 1304), the Trans default is turned off (block 1306) and the scan is continued at FIG. 22.

If "Trans" is specified (block 1308, FIG. 19), the user has made an error and the message invalid combination of key words is sent to his terminal (FIG. 22, block 1614). Control is returned to the command module. If the transaction was not specified, the verb switch is set equal to Picture (block 1310) and the scan is continued.

If the key word is TIMEKEY (FIG. 15), the verb switch is tested for Play (FIG. 20, block 1400). If it is not Play, an error message is sent saying "invalid TIMEKEY word specified" (block 1402) and return is made to the command module. If the verb switch is Play, the time is converted to binary, block 1404. The interval is set equal to this result (block 1406) and the scan continued, FIG. 22.

If the key word is DUMP, FIG. 20, the verb switch is tested for M DUMP, block 1408. If it is M DUMP, the user has made another error and an invalid combination of key words message is sent to the terminal. If it is M DUMP, then the DUMP is turned off to the printer (block 1410) and the key word scan continued FIG. 22.

If the key word is TRANS the verb switch FIG. 15, is tested for Play, block 1502, FIG. 21. If the verb switch is not play or the option is specified (block 1504), then the message invalid combination of key words is sent to the user's terminal and control is given to the command module. If the verb switch is Play and the option is not specified, the scan switch is set equal to option, block 1506, the verb switch is set equal to TRANS, block 1508, the Spad switch is set equal to write, block 1510, and an equal sign is checked for, block 1512. If an equal sign exists, the SPAD name is set equal to the data set name specified, block 1514, and the scan is continued at FIG. 22.

If the key word is PARMKEY, FIG. 15, the verb switch is tested for PRINT or TRANS, FIG. 22, block 1600. If it is not PRINT or TRANS, an invalid combination of key words message is sent to the user, block 1614. If it is PRINT or TRANS, the scan request module computes the number of parameters (block 1604) and continues to scan as previously described.

If the key word is DELSAVE, FIG. 22, block 1616, the save name is set equal to the data set name that is going to be deleted and the service routine DELETE SAVE, block 1618 is called specifying the save name that it would delete. Control is returned to the command module.

If the key word is DELSPAD, block 1620, FIG. 22, the spad name is set equal to the data set name and the service module DELETE SPAD (block 1622) is called specifying the Spad name to be deleted. Control is then returned to the command module.

All valid key words have now been discussed for the scan for key word shown at FIG. 15, block 906 for the case where the request is PLAY. If the request is TRANS, the verb switch is set equal to TRANS (block 916) and the scan for key word is again initiated, block 906. If the request is ORGAN, the verb switch is set equal to ORGAN, block 918, the I/O save switch is set equal to I/O Read, block 920, and control is returned to the command module, FIG. 12. If the request is PRINT, the verb switch is set equal to PRINT (block 922) and the scan for key word routine is again initiated. If the request is DUMP, FIG. 16, the verb switch is set equal to DUMP (block 1000) and the search for key word routine is initiated again, block 906, FIG. 15. If the request is LIST, the attribute is tested, block 1002. No attributes then the "invalid syntax" message is sent (FIG. 12) and return is made to the command module. If there are attributes and the syntax is correct (block 1006), the LIST directive service routine lists all saved data (block 1006) and the command module receives control. If the request is DELETE and there are no attributes (block 1008), again the error message is sent. If the syntax is correct (block 1010), then the scan for key word routine, block 906, FIG. 12, is again initialized. This completes the discussion of all valid requests that can be entered in the command module for command phase, as scanned by the SCANRQST module 306, FIG. 9.

Returning now to FIG. 9, if the play command is entered by the user, block 308, the service routine FILLHEAD, block 310, is called. This service routine fills in the key signature, the meter and the time signature. At this point all necessary data sets are opened (block 312) and the verb is tested (block 314). If the verb is an invalid verb, the message "feature not supported" is sent, block 316.

If the verb is TRANS, the TRANS module is attached (FIG. 10, block 400) and a wait is issued to wait for the completion of the translation, block 402. A message is then sent saying that the request was complete, block 406, and the data set is closed, block 408.

If the verb is Play, FIG. 11, the DCB is checked to see if it is open, block 500. If it is not open, a switch is set (block 502) to say that it is open and the I/O routine KDIO is called to open the DCB for input (block 504). Then the TRANS verb switch is checked to see if the TRANS routine is needed (block 506). If it is not needed, then the Picture switch is tested (block 508). If the Picture routine is not needed, the save routine is checked (block 510). If it is not needed, then the message feature not supported is sent to the user (block 512).

If the TRANS routine is needed (block 506), the TRANS module is attached, FIG. 13, block 700, the READDACS module is attached, block 702, and the message ENTER STOP is sent to the user. The user can now begin playing his composition at the organ. The organ is activated by setting the oval switch down and the percussion switch to a value other than off. After playing, the user types in STOP, block 706, at the input terminal. At block 708 the READDACS module is complete and a message is sent from the TRANS module saying "play terminated" (block 710). The appropriate data set is closed (block 712) and return is made to the command module.

Referring to FIG. 11, if the TRANS module is not needed in the Play command but the Picture is needed, then the service routine 01, block 514, is attached. The previously described flow on FIG. 13 is invoked to attach READDACS and send the message to the user telling him to enter STOP.

If the Save routine is needed, then the service routine 02, block 516, FIG. 11, is attached to save the user's input data.

If the verb is DUMP, FIG. 9, the service routine SERVO4 is attached, block 800, FIG. 14, and flow continues at FIG. 10. A wait for completion is issued, block 402, FIG. 10, and the message "completed" appears at the terminal when the service module completes dumping the data sets.

Referring again to FIG. 9, if the user enters the PRINT command, the PRINT module is attached, block 802, FIG. 14, and a wait for completion is issued, FIG. 10. When the PRINT module completes the printing of the data set, the message Completed appears at the user's terminal. The appropriate data sets are closed, block 408, and return is made to the command module.

If the verb is PICTURE, FIG. 9, the PICTURE module is attached, block 804, FIG. 14 (service module SERVO1), and again a wait for completion is issued, FIG. 10.

If the verb is ORGAN, FIG. 9, the command module tests the DCB to determine whether the DCB had been previously opened, block 806, FIG. 14. If yes, then the wait for completion is issued, FIG. 10, and the completion message would again appear. If the DCB was not opened, the initialize switch is set, block 808, FIG. 14, indicating this fact and the I/O module is called to open the DCB for input from the organ block 810.

At this point, the organ module is attached, block 812. When the organ module completes playing back the data, the wait is completed and the message completed appears at the user's terminal, block 406, FIG. 10. The command module again receives control. This concludes the discussion of all valid verb selections in the command module.

PHASE = TRANSLATION LANGUAGE (FIGS. 23-28)

The translation phase may be invoked by one of two ways. First, it can be specified in the Play command (FIG. 11, block 506) or second, it can be given as a command itself, FIG. 10, block 400. The translation phase first initializes all defaulted parameters, block 1702. The sharps are given a value of 3 and the flats are given a value of 2, block 1704. Major scales are given a value of 1 and minor scales are given a value of 2, block 1706. The line vector which determines whether a note is beginning on a black or white key is determined at block 1708. If it is a white key, for instance, A major, the line number is not altered, block 1710. This means that no prefix is added to the first note. If it is not a white key, and if it is a sharp key (block 1712), a value is determined by taking one from the line number to give it a sharp value which will be later on computed. If it is a flat key, a value is added to the line. Each note of the scale is computed from this vector so that all notes have sharps and flats throughout the five octave range, block 1716.

Block 1718 shows the call to the GETDAX module. A sample from the save data set which is operated upon by the translation phase is passed to the translation module. The foot pedal value which is the 64th bit is scanned to determine when to start the composition. If the foot pedal is not depressed, block 1720, then the next sample is obtained from the save data set. If the foot pedal is depressed, block 1802, FIG. 24, the measure number starts out equal to zero, block 1804. The initialize counters, block 1806, contains the correct initial values.

The jth note is examined block 1808. A series of examinations are made to determine whether the note is on, block 1808, if it has been tied, blocks 1810, 1812, and if it is stopped, block 1814. A note which is stopped is placed into SPAD into the measure that is being worked upon shown by the measure number. If a note is still on and it has been on before, then this note is considered to be tied and the next note is operated upon until 60 is reached by the counter, there being 60 notes in the sample space (block 1818). After the 60th note is reached, the sample has been completely translated. At this point, the GETDAX module is called again (block 1820) to get the next sample. If it is the last sample, block 1822, a call is generated, block 1824, to the PUT SPAD module to issue an end message to the user. Exit is then generated, block 1826, to the command language modules.

If it is not the last sample, then the pedal is tested to see if it had been lowered, FIG. 25, block 1902. If the pedal had been lowered then another measure is started, block 1904. If the pedal was just raised, block 1906, that means that it can be ignored since only the lowered position signifies a new measure. The beats in the measure are compared and if the beats are greater than the number of pedals, block 1910, a return is made to FIG. 24 to determine if the jth note again had been on and the determination will be made upon each note in the sample states up until 60. This is shown in blocks 1808-1818. Again the GET DAX module is called, block 1820, and if it is the last sample, blocks 1824, 1826 are called. If it is not the last sample and in this particular case the number of beats has exceeded the pedal, then the measure is complete (block 1912, FIG. 25) and all starting values are initialized, all notes stalled are put out as ties, block 1914, the resolution value is computed (block 1916) and the measure is outputted, block 1918. If the interval for this particular measure is too large, for example, in a 4/4 measure if it contains 5 quarter notes (there was one extra beat), a message "sample interval too large" is sent, block 1922. The translation phase then picks up the next measure.

If the interval is not too large, the flow continues on FIG. 26. Block 2002 shows that the data array contains all notes. The following steps determine the note values within each measure. If the duration of the note is determined to be zero at block 2024, the note is deleted from the measure. This is because of the fact that this could have been a slight playing error which is perceived by the exactness of the sampling procedure which occurs every 10 milliseconds.

If the duration is not zero and the note length is greater than the measure, block 2020, the note is skipped and later tied. If the note length is not greater than the measure, flow continues on FIG. 21. At block 2102 the note is either tied or dotted. If it is dotted, the duration is computed by the algorithm shown in block 2004 and the note is tied to the previous note. If the note is not a tied note or if it is a new note, the next note in the measure is processed.

Referring to FIG. 28, when all notes in the measure have been processed, the notes then are positioned within the measure, block 2202, and a pause made to PUT SPAD with the measure number shown in block 2214. The measure number count is increased by one, block 2216, and then the next measure is processed by return to FIG. 24.

When all measures have been processed, a call is made to PUT SPAD, block 1824 (FIG. 24) to end the composition and the exit routine in the command module is entered, block 1826.

PHASE = I/O (FIG. 29)

The first module in the I/O phase is the READDACS module. This module is called through the play command and therefore, the organ is being played while this module is executing. The first operation in the READDACS module, FIG. 29, block 2302, shows the interval being converted to timer units. The interval default value is 10 milliseconds. A call is generated to the KDIO module, block 2304, which tells the I/O module if the DCB needs to be opened (a code of zero), the DCB is going to be written out (a code of 1), or the DCB is going to be read (a code of 2). The next decision block 2306 determines if the data has changed. If the data has not changed, the time counter is stepped by 10 milliseconds (block 2308) and a wait is issued (block 2312). A scan is made to determine if the stop command has been issued (block 2312). If it has, then a return is made to the command language routines. If it has not, then another call is generated to the KDIO module. Again a determination is made as to whether or not the data has changed. In this particular case if it has changed, a save data is updated to contain the next sample (block 2314). A buffer comparison is made to determine if the buffer has been exceeded (block 2316). If it has, then a pointer is reset (block 2318). If it has not, the pointer is updated (block 2320) and a determination is made to see if the KDIO module is waiting (block 2322). If it is not waiting, then a wait is issued in the READDACS module again. If the KDIO module is waiting, then the ECB is posted (block 2324) and the wait is issued.

If the command stop has been issued, then a return is made to the command language module as has been previously discussed.

Referring to FIG. 30, the KDIO module of the I/O phase is described. This module is entered with two parameters, the first containing the code and the second containing the input area address. Block 2402 shows the decision on the code. If the code is zero, an open is issued on the DCB (block 2404) and return is made to the command language. If the code is one or two, the code is stored in the CCW (channel command word) after the input area address is stored there (block 2406). Then the register is set up with the address of the IOB (block 2408) and an EXCP is issued to the organ (block 2410). A wait is issued for the I/O to complete (block 2412) and a successful completion is tested for 7F in the CCW. If the 7F is present in the CCW, a return is made to the READDACS module. If it is not a 7F, then an ABEND 277 is issued (block 2418).

Referring to FIG. 31, the organ module may be invoked by the command "organ" which specifies the save data set name. A message appears at the user's console "song played by" with the song player's name inserted. This is followed by a message "song originally played by" (block 2504). Then the organ module determines the time interval between samples and a call is made to the GET SAVE module (block 2508) and a return sample is saved (block 2510). The stop command is tested for (block 2514) and if it was issued, a return is made. If it was not issued, a call is made to the KDIO module passing a code of one to write out the sample to the organ. At this point, notes will sound. A wait is issued for I/O to complete (block 2518). Again a sample is received from the GET SAVE module. Again the stop command is tested for and if the stop command is given, the organ module returns to the command language modules.

PHASE = ARTWORK (FIGS. 32, 33)

This phase can be entered by saying PRINT (SPAD = DSNAME, PARM(φ)). The PRINT module initializes data structures, calls the Ktitle module to put out the song title, block 2604, calls the clef module to put out the clef, block 2606, calls the Ktime module to put out the time signature, block 2608. It calls GET SPAD to get a measure of SPAD, block 2610. If there is no SPAD data (block 2612), a message no SPAD data appears at the user's console (block 2614) and return is made to the command language (block 2618). If there is SPAD data, the build IDX module is called to lay out notes in the first measure (block 2620). If the measure fits on the current line (block 2622), a test is made to see if there is room for two measures (block 2702, FIG. 33). If there is room for two measures, then processing continues to determine tentative locations by calling the KXlocation module, block 2710. The KXADJ module 2712 is called to modify these locations, the Ktype module 2714 is called to determine the stem direction, the Pnotes module 2716 is called to put out notes, and the Fplot module 2718 puts out the by-line. A read is generated for the next measure (block 2722) and a call is made to GET SPAD (FIG. 32) to get another measure of SPAD. This measure is tested to see if there is SPAD data. Again the build IDX is called to lay out notes in the measure and as previously discussed, the measures are tested to determine if they fit. If they do not fit, then a new line may be put out (block 2624, FIG. 32). If a new line is put out, then a switch (block 2719) is detected to determine if it is equal to two. If it is equal to two, the user may only wish to put out one line of data and a return is made to the command language. Then a continuing modification of locations occurs as previously discussed.

If it is determined that the measure has a zero length (block 2724), the Fplot module (block 2726) is called to put out bar lines. A read is generated to read the next measure (block 2730). If the I switch is equal to 2 (block 2728), a call is generated to BSP out to print that particular measure (block 2732). This continues until all measures have been processed. When all measures are processed, an exit is generated (block 2734).

Program Source Listing

The following source listings are appended hereto and correspond to blocks of FIGS. 2A-C as indicated below:

Listing Name Block No. in FIGS. 2A-C ______________________________________ Command Main Program Block 24 Read and Scan Request From Block 26 Terminal Trans Block 32 KDIO Block 36 READDACS Block 38 Organ Routine Block 46 Main Graphic Program Blocks 48-58 ______________________________________

While the invention has been particularly shown and described with reference to a preferred embodiment thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention.