JP2007140067A - Musical sound generator, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a musical sound generator capable of notifying the existence of performance keys that has become an operation period, irrespective of the existence of operation on operation elements. <P>SOLUTION: The musical sound generator 10 is connected to electronic musical instrument 20 having a keyboard 22. Performance information showing keys to sequentially operate as the performance progresses and an operation period in which the keys should be operated are stored in a ROM 13 in key units. A CPU 11 refers to the performance information and specifies the operation period and the keys to be operated in the period to generate musical sound in the period as a whole. The performance operation carried out by a user is recognized from an input MIDI data, and musical sound is generated according to the pressed keys, while the keys are being depressed that can be said as being appropriate within the operation period. In periods other than this, a kind of musical sound that is different from that musical sound is generated. Thus, the operation period and the period, while the keys are being depressed that can be said as being appropriate are made recognizable by the musical sound generated. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a musical sound generating apparatus that generates a musical sound corresponding to a performance operator operated in a group of performance operators.

  Musical tone generators that generate musical sounds according to operations on a group of performance operators such as a keyboard can be realized in various forms. Some musical tone generators having such performance operators are equipped with a performance guide function for visually guiding performance operators to be operated as the performance progresses. The guide by the performance guide function is a unit of performance operators that indicates a performance operator that should be operated sequentially in accordance with the progress of the performance in the group of performance operators and an operation period during which the performance operator should be operated. It is performed with reference to the performance information indicated by. The operation period is a period that is a timing at which the operation should be canceled from a timing at which the operation to the performance operator should be started.

  Examples of the musical sound generating device equipped with the performance guide function include those described in Patent Documents 1 and 2, for example. Display devices used for visual guides are ones in which a light emitting element is arranged for each performance operator (Patent Document 1) and ones that can indicate a performance operator to be operated at one place (area) (Patent Document 1) 1, 2).

  In the conventional musical tone generators described in Patent Documents 1 and 2, music can be played correctly by performing operations on the group of performance operators according to a guide by a display device. Whether or not a performance operator guided in the group of performance operators has been operated at the correct timing depends on whether the performance operator is actually operated and the timing at which the display device is guided. ) Can be confirmed. However, in order to perform the confirmation, the user must always pay attention to a display device that changes the guide contents as needed as the performance progresses. This is a heavy burden on the user and may make it difficult to concentrate on the performance. Therefore, it can be said that it is important to be able to confirm whether or not the performance operator has been correctly operated without looking at the display device.

  An example of a conventional musical sound generating device that can confirm whether or not the performance operator has been correctly operated without looking at the display device is disclosed in Patent Document 3, for example. In the conventional musical sound generating device described in Patent Document 3, a different sound is generated depending on whether or not the performance operator operated by the user is a performance operator within the operation period. As a result, if the user operates the performance operator to be operated at the operation timing, the tone (normal sound) corresponding to the performance operator is sounded, otherwise the warning sound having a different tone from that tone Is pronounced.

  By changing the sound to be sounded as described above, it is possible for the user to quickly check whether or not the performance operator that has been in the operation period has been operated from the sound that is sounded. However, since the sound of the normal sound or warning sound is generated by the operation of the performance operator, the presence of the performance operator whose operation period has elapsed while the performance operator is not operated and the operation period are sounded. Cannot recognize from sound. From this, when it is possible to confirm by sound whether or not the performance operator has been correctly operated, it may be assumed that the user has not operated the performance operator during the operation period.

Patent Document 4 describes a conventional musical sound generator that controls the volume of a musical sound that is generated by operating a performance operator. By controlling the volume, it is possible to notify whether or not the operation of the performance operator has been appropriately performed. However, like the conventional musical tone generator described in Patent Document 3, the presence of a performance operator that has been operated while the performance operator has not been operated or the operation period is determined by the user from the sound produced. It cannot be recognized.
JP-A-10-97181 JP 2004-85821 A Japanese Utility Model Publication No. 60-150577 JP 2004-205892 A

  An object of the present invention is to provide a musical sound generating device capable of notifying the presence of a performance operator that has become an operation period by sound regardless of whether or not the performance operator is operated.

  The musical sound generating device of the present invention is based on the premise that a musical sound corresponding to a performance operator operated in the performance operator group is sounded, and in accordance with the progress of the performance in the performance operator group. Performance information acquisition means for acquiring performance information to be operated in sequence, performance information indicating operation periods in which the performance operators should be operated in units of the performance operators, and operations on the performance operators Based on the operation detection means for detecting the operation period, the operation period indicated by the performance information acquired by the performance information acquisition means, the performance operator, and the detection result of the operation detection means for the operation on the performance operator. One or more types of musical sounds to be generated are determined, and sound generation control means for generating the determined one or more types of musical sounds at least within the operation period is provided.

  The sound generation control means selects different musical tones depending on whether or not the timing at which the operation detecting means detects the start of operation for the performance operator during the operation period is within the allowable range with the start timing of the operation period. It is desirable that the sound be generated within the operation period. In addition, when the detection period during which the operation detection unit has detected an operation on the performance operator during the operation period is within the operation period, a performance operator to be operated is selected during the period outside the detection period within the operation period. It is desirable to sound a kind of musical sound notifying that it is not operated. When the performance operator group is a keyboard, the operation detecting means also detects the speed when the keys constituting the keyboard are pressed, and the sound generation control means detects the speed detected by the operation detecting means. It is desirable to operate the musical sound to be sounded under the circumstances in consideration.

  The program of the present invention is equipped with a plurality of functions for realizing each means included in the musical tone generator.

  The present invention provides a performance operator that should be operated sequentially in accordance with the progress of performance in the group of performance operators, and performance information that indicates an operation period during which the performance operator should be operated in units of performance operators. , And a musical tone is generated in a situation where there is a performance operator indicating the operation period. The type of musical sound is selected and determined according to the operation performed on the performance operator that has become the operation period.

  Specifically, for example, when an operation is started at a timing that can be said to be appropriate, a musical sound for notifying that is selected, and otherwise, to notify that the operation has started at an inappropriate timing Select a musical tone. At this time, if the operation is started after the operation period arrives (after the operation period starts), the operation is delayed from the start of the operation period until the operation is actually started. Make a sound to notify you. On the other hand, if the operation is canceled before the operation period expires (before the operation period ends), a musical sound for notifying that the operation has been canceled at an inappropriate timing is displayed in the operation period. Until it passes, at least let it sound. One or more types of musical sounds to be generated are selected and determined, and are generated during the operation period (from the start to the end of the operation period). For this reason, the user can easily recognize the presence of the performance operator during the operation period by sound regardless of whether or not the performance operator is operated. In addition, it is possible to easily confirm the period during which the user has appropriately performed the operation.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
<First Embodiment>
FIG. 1 is a diagram for explaining the configuration of a musical sound generator according to the first embodiment.

  As shown in FIG. 1, the musical sound generator 10 stores a CPU 11 that controls the entire apparatus 10, a RAM 12 that the CPU 11 uses for work, a program executed by the CPU 11, various control data, waveform data, and the like. ROM 103, for example, a keyboard or pointing device (such as a mouse), a medium driving device for accessing a recording medium such as a CD-ROM or DVD, an input unit 14 including those interfaces, and a display for displaying an image on the display device A MIDI interface (I / F) 16 for transmitting and receiving MIDI data between the unit 15 and an external device, and an audio interface (I / F) for outputting digital data (peak value) of a musical tone to be generated to the external device F) 17.

  The MIDI I / F 16 is connected to an electronic musical instrument 20 having a MIDI interface (I / F) 21 and a keyboard 22 capable of transmitting / receiving MIDI data to / from the MIDI I / F 16. A peak value is input to the audio I / F 17. A sound source system 30 that can be converted into sound is connected. The MIDI I / F 21 has a function of generating MIDI data indicating the operation contents for the keyboard 22. As a result, the musical tone generator 10 according to the present embodiment inputs MIDI data from the MIDI I / F 21 of the electronic musical instrument 20, generates a peak value of a musical tone that is requested to be generated by the MIDI data, and uses it as a sound source. By outputting to the system 30, the musical sound is generated. The sound source system 30 includes at least a D / A converter, an amplifier, and a speaker, for example.

  The musical sound generator 10 is realized by, for example, mounting an application program (hereinafter referred to as “application”) for operating as the musical sound generator 10 on a personal computer (PC). For example, the application is recorded on a recording medium accessible by the medium driving device constituting the input unit 14 and provided. The application may be distributed via a network such as the Internet.

  A writable memory (for example, a flash memory) is employed as the ROM 13 so that an application can be installed (installed). On the recording medium on which the application is recorded, a large number of various waveform data for generating the peak value of the musical sound are recorded. The waveform data includes data for tone generation with different timbres. Waveform data with the same tone color is prepared for each pitch. The PC that implements the musical sound generation device 10 may be one in which an auxiliary storage device such as a hard disk device is mounted in addition to or instead of the ROM 13. The application is hereinafter referred to as “musical sound generation application”.

  Various waveform data can be stored in the ROM 13. Further, it is possible to copy from a recording medium as required. Here, for the sake of explanation, it is assumed that the data is stored in the ROM 13 for convenience.

  The waveform data stored in the ROM 13 is copied to the RAM 12 and used. This is because the RAM 12 generally has a higher access speed than the ROM 13. As a result, it is possible to generate a peak value of a musical tone to be generated at a higher speed.

  By preparing waveform data for each pitch, sampling data (crest value) constituting the waveform data is simply read out sequentially. Thus, it is not necessary to perform interpolation according to the speed of reading data (step width).

  The user performs a performance by operating the keyboard 22 of the electronic musical instrument 20. In the performance, it is required to sequentially press the keys to be pressed (operated) among the keys constituting the keyboard 22 as the performance progresses. In the present embodiment, tone generation control is performed so that the user can recognize whether or not the key to be pressed has been properly (accurately) pressed. For the key to be pressed and the operation period in which the key should be pressed (the period from key pressing to key release, hereinafter referred to as “key pressing time”), refer to the performance information indicating them in units of keys (musical tones). To be specific.

  FIG. 7 is a diagram for explaining a musical sound generated by the musical sound generation control. In FIG. 7, when the key pressing time of a certain key indicated by the performance information arrives, that is, when the user presses the key a time earlier than the time point when the key should be pressed (case 1), the time b from the timing A musical tone that is generated when the user presses the key after a delay (case 2) and when the user does not release the key even when the key should be released (case 3) is shown.

  In case 1, the key pressing time of the user is before the timing at which the key should be released before the time a at which the key should be pressed. When the user presses the key for such a key pressing time, if the time a is short enough to be coincident with the timing to press the key, the musical sound assigned to the key pressed by the user (hereinafter “ After that, a musical tone having a tone different from the musical tone (hereinafter referred to as “warning sound”) is produced until the key pressing time indicated by the performance information is completed. If the time a is not short enough to coincide with the timing at which the key is to be pressed, a warning sound is generated throughout the key pressing time indicated by the performance information.

  In case 2, the key pressing time of the user is before the timing at which the key should be released after the time b at which the key should be pressed. When the user performs key pressing at such a key pressing time, if the time b is short enough to match the timing to be pressed, the key pressing indicated by the performance information within that time b and after the user releases the key. A warning sound is generated until the time expires, and a set sound is generated during the remaining time, that is, the user's key pressing time. If the time b is not short enough to coincide with the timing at which the key is to be pressed, a warning sound is generated throughout the key pressing time indicated by the performance information.

  In case 3, the key pressing time of the user is after the timing to release the key from the timing to press the key. When the user presses the key during such a key pressing time, the set sound is generated during the key pressing time indicated by the performance information, and any musical tone is played from the timing when the key should be released until the user actually releases the key. Is not pronounced. In other words, it is silent.

  In this way, in this embodiment, depending on whether or not the timing at which the user has pressed the key can be regarded as appropriate, the type of musical sound is selected by the key pressing and sounded, and the timing at which the user releases the key. The sound of the warning sound or the set sound being sounded is muted. For this reason, the user can easily recognize whether or not he / she pressed and released the key at an appropriate timing from the generated musical sound. Even if the key is not pressed, a warning sound is generated during the key pressing time indicated by the performance information (the same as when the time b in case 2 is considered not short), so there is a key to be pressed. And the key pressing time can be recognized by the user. Hereinafter, in order to avoid confusion, the key pressing time by the user is expressed as “actual key pressing time”, and the key pressing time indicated by the performance information is expressed as “correct key pressing time”.

  In order to perform sound generation control as shown in FIG. 7, various data shown in FIGS. 2 to 6 are managed in this embodiment. Here, the data will be described in detail with reference to FIGS. For convenience of explanation, it is assumed that the sound generation control is performed unless otherwise specified in the following description. Informing the user of the performance contents by sound generation control is referred to as a “sound generation guide”.

  FIG. 2 is a diagram for explaining the configuration of timbre data. The timbre data is data prepared for each timbre in order to manage the waveform data in timbre units. As shown in FIG. 2, the timbre data includes data iID indicating the corresponding channel number, data iNoteOnCnt indicating the number of tones being generated, and the storage location of the pitch data of the first pitch (for example, the lowest pitch) among the corresponding pitch data. Data pTD, data pPrev indicating the storage location of the previous tone color data, and data pNext indicating the storage location of the next tone color data.

  FIG. 3 is a diagram for explaining the configuration of pitch data. The pitch data is data prepared for each tone color and for each pitch. As the data pTD, data indicating the storage location of the pitch data of the leading pitch in the corresponding tone color is stored in each tone color data. As shown in FIG. 3, the pitch data includes data iPitch (pitch number (note number)) indicating the corresponding pitch, data pSD indicating the storage location of the corresponding source data, and data pPrev indicating the storage location of the previous pitch data. , And data pNext indicating the storage location of the next pitch data.

  FIG. 4 is a diagram for explaining the configuration of the source data. The source data is data prepared for each waveform data. As shown in FIG. 4, the source data includes data pDAta indicating the start address of the waveform data copied to the RAM 12 of the corresponding waveform data, data fileName indicating the file name (original storage location) of the waveform data, and the waveform data. Data fLength indicating the entire length, data minVel indicating the lower limit value of the velocity range to which the waveform data corresponds, data maxVel indicating the upper limit value thereof, data pPrev indicating the storage location of the previous pitch data, and the next pitch data Data pNext indicating the storage location is provided.

  The type of musical sound to be generated is changed by changing the waveform data used for the sound generation. For this reason, the data pDAta, fileName, and fLength are stored for each type of musical sound to be generated.

  FIG. 5 is a diagram for explaining the structure of the pronunciation data. The sound generation data is data prepared for each musical sound to be generated during performance indicated by the performance information. As shown in FIG. 5, the sound generation data includes data iID as identification information, data iTone indicating the corresponding timbre data (channel) (for example, data iID in the corresponding timbre data), data iPitch indicating the pitch of the musical tone, Data iOnVel indicating velocity, data iStatus indicating the state of the musical tone of the pitch (-1 is muted, 0 is muted, 1 is the key press time indicated by the performance information, and the user presses the key. In the key state, the value of 2 is the key pressing time indicated by the performance information, and the user is not pressing the key (the key pressing is delayed), and the value of 3 is the key pressing time indicated by the performance information. And the data pME indicating the storage location of the corresponding performance data, corresponding to a state where the user is pressing the key (a state where the key is pressed early), respectively. Data pSD indicating the storage location of the source data, data lOnStart indicating the sound generation start time by the corresponding performance data, data lOffStart indicating the mute start time, data lNoteOn indicating the key pressing time (timing) by the user, and the key release time (timing) ) Indicating data 1NoteOff, data fRelease indicating the attenuation rate during the silencing process, data pPrev indicating the storage location of the previous sounding data, and data pNext indicating the storage location of the next sounding data. The data iOnVel is a velocity value extracted from the MIDI data input from the electronic musical instrument 20. As is well known, the velocity value represents the speed at which a key is pressed, that is, the strength with which a musical sound is produced.

  The selection of the waveform data, that is, the selection of the data pDAta, fileName, and fLength to be targeted is performed according to the data iStatus (value). As a result, a musical tone of a type corresponding to the value of the data iStatus is generated.

  The pronunciation data is created sequentially during performance and updated as needed. Other data, that is, timbre data, pitch data, and source data are created before the performance starts and are not updated during the performance.

  In the performance information, data is prepared for each tone to be generated. The data is performance data. The performance data includes, as shown in FIG. 6, data lTime indicating the timing (pronunciation start time) at which the tone of the musical sound should be started, data lGate indicating the pronunciation time at which the pronunciation should be continued, data Pitch indicating the pitch, Data Vel indicating the velocity, data pPrev indicating the storage location of the previous performance data, and data pNext indicating the storage location of the next performance data are provided.

  The sound generation start time indicated by the data lTime is, for example, the time elapsed since the start of performance. It is copied to the pronunciation data as data lOnStart. Thus, the data lOffStart is a time after the sounding start time indicated by the data lGate.

  Hereinafter, with reference to various flowcharts shown in FIGS. 8 to 13, the operation of the musical sound generating apparatus 10 that manages the above-described data and performs sound generation control will be described in detail. The operation is realized by the CPU 13 reading the musical tone generating application from the ROM 13 to the RAM 12 and executing it.

  FIG. 8 is a flowchart of the entire process. This shows a flow of excerpts of processes executed between starting and ending the musical tone generating application. First, the overall process will be described in detail with reference to FIG.

  First, in step 101, a driver for the MIDI I / F 16 is loaded from the ROM 13 to the RAM 12 and activated. In the subsequent step 102, a driver for the audio I / F 17 is similarly loaded and activated. Thereafter, an audio data output thread for outputting the peak value (audio data) of the tone to be generated from the audio I / F 17 is activated (step 103), and stored in the ROM 13 as a tone definition file. 4 is read and developed in the RAM 12 (step 104), and the waveform data (denoted as “tone color data” in the figure) is read from the ROM 13 and loaded into the RAM 12 for each pitch (step 105). The initialization is completed by the load, and the process proceeds to step 106 to wait for data input by the input unit 14 or the MIDI I / F 16. Here, regarding the data input by operating the input unit 14, only an end instruction of the musical sound generating application, a start of the pronunciation guide, and a stop (end) thereof are assumed.

  When a user presses or releases a key constituting the keyboard 22 of the electronic musical instrument 20, the MIDI I / F 21 generates the contents of the performance operation and MIDI data corresponding to the key on which the operation was performed. Then, it is output to the MIDI I / F 16 of the musical tone generator 10. When a keyboard or a pointing device constituting the input unit 14 is operated, the operation content is notified from the input unit 14 to the CPU 11. Thereby, the process proceeds from step 106 to step 107, and it is determined whether or not the input is an end command of the musical tone generating application. If the user performs an operation for terminating the application on the input unit 14, the determination is yes and the process proceeds to step 114. Otherwise, the determination is no and the process moves to step 108.

  In step 108, it is determined whether or not the input is MIDI data. If the MIDI I / F 16 has input MIDI data, the determination is YES, the process proceeds to step 109, and after performing the MIDI IN process corresponding to the input, the process returns to step 106. On the other hand, if not, the determination is no and the process proceeds to step 110.

  In step 110, it is determined whether or not a reproduction start command for instructing the start of the pronunciation guide has been input. When the user performs an operation for inputting the command to the input unit 14, the determination is YES, the process proceeds to step 111, the reproduction process for the pronunciation guide is started, and then the process returns to step 106. Otherwise, the determination is no and the process moves to step 112.

  In step 112, it is determined whether or not a playback stop command for instructing to stop the pronunciation guide is input. When the user performs an operation for inputting the command to the input unit 14, the determination is YES, the process proceeds to step 113, and a reproduction stop flag that is a variable for managing execution of the reproduction process is turned on. That is, after substituting a value indicating the stop of execution, the process returns to step 106. Otherwise, the determination is no and the process returns to step 106 without executing the process of other steps.

  In step 114 where the determination in step 107 is YES and the process proceeds to step 114, the audio data output thread is terminated. The termination is performed, for example, by substituting a value for instructing termination into the thread termination management variable. Thereafter, various data shown in FIGS. 2 to 6 stored in the RAM 12 are deleted (step 115), the driver of the audio I / F 17 is terminated (released) (step 116), and the driver of the MIDI I / F 16 is turned on. End (open) (step 117). After erasing various drivers and data from the RAM 12 in this manner, a series of processing is terminated, that is, the musical tone generating application is terminated.

  FIG. 9 is a flowchart of the MIDI IN process executed as step 109 described above. Next, the IN process will be described in detail with reference to the flowchart shown in FIG.

  This IN process is a process for dealing with MIDI data input via the MIDI I / F 17. There are many types of MIDI data, but here, only data related to the present invention, that is, only two types of MIDI data of note-on message and note-off message will be described.

  As described above, the data lOnStart (data lTime in the performance data) in the sound generation data indicates the time from the start of the performance. Since the timing at which the key should be pressed is represented in such a time, the count for counting the time is started from 0 when the reproduction process is activated. The counting, that is, the time measurement is performed by using, for example, a hard timer built in the CPU 11. Unless otherwise specified, the current time is used to indicate the time thus measured.

  First, in step 201, it is determined whether or not the input MIDI data is a note-on message instructing the start of tone generation. If the MIDI data is not a note-on message, the determination is no and the process moves to step 212. Otherwise, the determination is yes and the process moves to step 202.

  In step 202, a channel number, a note number (pitch), and a velocity value are extracted from the input MIDI data, and substituted into variables ich, iPit, and iVel, respectively. In the subsequent step 203, an index value indicating the storage location of the pronunciation data located at the head of the pronunciation data is substituted for the variable nd. In steps 204 to 209, the process proceeds after the substitution, processing for creating or updating the corresponding pronunciation data is performed according to the input MIDI data.

  First, in step 204, it is determined whether or not the pronunciation data indicated by the value of the variable nd does not exist. This time, the pronunciation data corresponding to the input MIDI data is sequentially changed by changing the data pNext in the pronunciation data designated by the value of the variable nd to the variable nd. While searching. Since there is no subsequent sound data in the sound data located at the end, the value of the data pNext remains the initial value. For this reason, when the value newly assigned to the variable nd is the initial value, the determination is YES and the process proceeds to step 210. Otherwise, the determination is no and the process moves to step 205. The determination of YES here means that the user has pressed the key before the timing to press the key.

  In step 205, the value of the data iStatus in the pronunciation data designated by the value of the variable nd (denoted as “nd.iStatus” in the figure. The same notation is used for other data hereinafter) is equal to 2, and nd. It is determined whether or not the pitch number indicated by iPitch matches that of variable iPit. If at least one of them does not match, the determination is no, the process moves to step 206, and the variable nd is set to nd. After pNext is substituted, the process returns to step 204 above. If not, that is, if they match together, the determination is yes and the process moves to step 207.

  In step 207, the nd. It is determined whether or not the time obtained by subtracting the time indicated by lOnStart is smaller than a constant DELAY_ALLOW indicating the allowable maximum time. Here, the time represents the time b when the key depression is delayed (case 2 in FIG. 7). Therefore, if the time b is sufficiently short, the determination is YES, and nd. The value of iStatus is updated to 1 (step 208), and nd. iTone is the value of variable iCh, nd. iNoteOn is set to the current time, nd. iOnVel is the value of the variable iVel, ne. After the pSD is updated to the data pSD in the pitch data that matches the set sound data iPitch (step 209), the series of processing ends. Otherwise, the determination is no and the process moves to step 206 above.

  In this way, while incrementing the value of the variable nd, it is confirmed whether or not the sounding data specified by that value corresponds to the input MIDI data, and the sounding data that has been confirmed to be compatible is updated. Like to do. As a result of the update, if the time b is within the allowable range, it is assumed that the user has pressed the key at an appropriate timing, and thereafter, the warning sound is switched to the set sound (case 2 in FIG. 7). On the other hand, if the confirmation cannot be made, the determination in step 204 is YES, and the process proceeds to step 210.

  In step 210, an index value indicating the storage location of newly created pronunciation data is substituted for the variable nd. Also, nd. As pPrev, the index value of the pronunciation data that has been located last is stored, and the data pNext in the pronunciation data is updated to the value of the variable nd. nd. As pNext, a value indicating the sound data positioned at the end is stored. In the following step 211, nd. iStatus is 3, nd. The value of variable iPit is stored as iPitch. Also, nd. fRelease, nd. pNext, nd. lOnStart, nd. lOffStart, nd. For example, predetermined initial values are stored as lNoteOff. Thereafter, the process proceeds to step 209.

  As described above, if the time b is not within the allowable range, the pronunciation data corresponding to the input MIDI data cannot be confirmed from those already created. For this reason, the determination in step 204 is YES, and new pronunciation data is created. As a result, even if the user presses the key within the key pressing time, if the user presses the key at an inappropriate timing, the warning sound continues to be generated after the key press (the case of FIG. 7). 2).

  In step 212 where the determination in step 201 is NO and the process proceeds to step 212, it is determined whether or not the input MIDI data is a note-off message instructing the end of tone generation. If the MIDI data is a note-off message, the determination is yes and the process moves to step 213. Otherwise, the determination is no and the series of processing ends here.

  In step 213, a channel number and a pitch number (note number) are extracted from the input MIDI data, and substituted for variables iCh and iPit, respectively. In the subsequent step 214, the index value of the pronunciation data located at the head is substituted for the variable nd. In step 215, the process proceeds after the substitution, it is determined whether or not there is sound generation data designated by the value of the variable nd. If the pronunciation data does not exist, the determination is yes, and the series of processing ends here. As a result, the input MIDI data is invalidated. On the other hand, if not, the determination is no and the process proceeds to step 216.

  In step 216, nd. It is determined whether or not the value of iPitch matches the value of variable iPit. If they match, the determination is yes and the process moves to step 218. If not, the determination is no and in step 217 the variable nd is set to nd. After pNext is substituted, the process returns to step 215.

  In step 218, nd. It is determined whether the value of iStatus is 1. If the value is 1, the determination is YES, and it is assumed that the user has released the key before the time to release the key (cases 1 and 2 in FIG. 7). The value of iStatus is updated to 2, and in step 220, nd. After updating lNoteOff to the current time, a series of processing ends. Otherwise, the determination is no and the process moves to step 221.

  In step 221, nd. It is determined whether the value of iStatus is 3. If the value is 3, the determination is YES, and nd. After updating the value of iStatus to −1, the process proceeds to step 220 described above. Otherwise, the determination is no and the process moves to step 217. The determination of YES here means that the user has not released the key whose timing should be released (case 3 in FIG. 7).

FIG. 10 is a flowchart of the reproduction process activated in step 111 in the overall process shown in FIG. Next, the reproduction process will be described in detail with reference to FIG.
First, in step 301, an index value indicating the storage location of the performance data located at the head in the performance information is substituted into the variable me. In the subsequent step 302, it is determined whether or not the reproduction stop flag is on. If the flag is turned on by the input of the reproduction stop command, the determination is YES, and after updating the values of all the sound generation data iStatus to 0 in step 303, the series of processing is terminated. Otherwise, the determination is no and the process moves to step 304.

  In step 304, 1 is substituted for a variable AllOff for confirming the presence of a musical tone being sounded, and the index value of the pronunciation data located at the head is substituted for a variable nd. In the next step 305, it is determined whether or not there is sound generation data designated by the value of the variable nd. If the pronunciation data does not exist, the determination is yes and the process proceeds to step 314. Otherwise, the determination is no and the process moves to step 306. In steps 306 to 313, processing for updating the sound generation data focusing on the key release time by the user is performed with reference to the performance data.

  First, at step 306, nd. It is determined whether or not the iStatus value is other than 0, that is, whether or not a musical sound is not generated by the sound generation data specified by the value of the variable nd. If the musical sound is not sounded, the determination is no, and in step 307, the variable nd is set to nd. After pNext is substituted, the process returns to step 305. Otherwise, the determination is yes and the process moves to step 308.

  In step 308, 0, which is a value indicating that the musical sound is being generated, is substituted into the variable AllOff. In the next step 309, nd. It is determined whether the mute start time indicated by lOffStart is before the current time. If the current pronunciation data corresponds to a key that should already be released, the relationship is established, so the determination is yes and the process moves to step 310. Otherwise, the determination is no and the process moves to step 307.

  In step 310, nd. It is determined whether the value of iStatus is 1. If the value is 1, the determination is YES, and it is assumed that the user has not released the key whose timing should be released (case 3 in FIG. 7). After updating the value of iStatus to 3, the process proceeds to step 307. Otherwise, the determination is no and the process moves to step 312.

  In step 312, nd. It is determined whether the value of iStatus is 2. If the value is 2, the determination is YES, and it is assumed that the key released by the user before the timing to release the key has reached that timing (cases 1 and 2 in FIG. 7). . After updating the value of iStatus to −1, the process proceeds to step 307. Otherwise, the determination is no and then step 307 is executed.

  In step 314, where the determination in step 305 is YES and the process proceeds, the value of the variable AllOff matches 1 and there is no performance data specified by the value of the variable me (the performance data targeted immediately before is the last). Whether or not). If the value is equal to 1 and the performance data does not exist, the determination is YES, and it is determined that it is time to end the pronunciation guide, and a series of processing ends here. Otherwise, the determination is no and the process moves to step 315. In step 315 and subsequent steps, a process for generating sound data by referring to the performance data or updating the sound data focusing on the key pressing time by the user is performed.

  First, in step 315, me. It is determined whether or not the sounding start time indicated by lTime is before the current time (time from the start of playback). If the sounding start time (timing to press the key) is before the current time, the determination is yes and the process proceeds to step 316. Otherwise, the determination is no and the process returns to step 302 above.

  In step 316, the index value of the pronunciation data located at the head is substituted for the variable nd. In step 317, the process proceeds after the substitution, it is determined whether or not there is sound generation data designated by the value of the variable nd. If the pronunciation data does not exist, the determination is yes and the process proceeds to step 324, and if not, the determination is no and the process proceeds to step 318.

  In step 318, nd. The value of iStatus matches 3, and nd. The iPitch value is me. It is determined whether or not the value matches the Pitch value. If at least one of them does not match, the determination is no, the process proceeds to step 319, and the variable nd is set to nd. After pNext is substituted, the process returns to step 317. If not, that is, if they match together, the determination is yes and the process moves to step 320. The determination of YES means that the target sound generation data is created by the user pressing the key before the key should be pressed (case 1 in FIG. 7).

  In step 320, nd. It is determined whether the time a obtained by subtracting the time indicated by lNoteOn is smaller than the constant DELAY_ALLOW. If the time a is sufficiently short, the determination is yes, and nd. Update the value of iStatus to 1 (step 321), nd. iOnStart is set to the current time, ne. lOffStart is set to me. a value obtained by adding the values of lGate, nd. pME is updated to the value of variable me (step 322), and me. After substituting next (step 323), the process returns to step 302. Otherwise, the determination is no and the process moves to step 319.

  In step 321 above, nd. By updating the value of iStatus to 1, if the time a is sufficiently short, the set sound is generated from the beginning. If the update is not performed, a warning sound is generated instead of the set sound. The pitch of the warning sound may be fixed.

  In step 324 where the determination in step 317 is YES and the process proceeds to step 324, an index value indicating the storage location of the newly created pronunciation data is substituted for the variable nd. nd. The index value of the pronunciation data that has been positioned last is stored as pPrev, and the data pNext in the pronunciation data is updated to the value of the variable nd. nd. As pNext, a value indicating the sound data positioned at the end is stored. In the following step 325, nd. iStatus is 2, nd. i.Pitch me. Pitch, nd. p.SD as me. Each index value corresponding to Pitch is stored. Also, nd. fRelease, nd. NoteOn, nd. lNoteOff, nd. For example, a predetermined initial value is stored as pNext, and after that, the process proceeds to step 322.

  FIG. 11 is a flowchart of processing realized by execution of the audio data output thread activated in step 103 in the overall processing shown in FIG. Next, the processing will be described in detail with reference to FIG. This output thread is used to generate a peak value (audio data) of a musical tone to be generated and output via the audio I / F 17 at a sampling period.

  First, in step 401, initialization is performed such that initial values are substituted into various variables, and an area for temporarily storing audio data (output buffer) to be output via the audio I / F 17 is secured in the RAM 12. In the next step 402, it is determined whether or not an end is instructed. As described above, in step 114 of the overall process shown in FIG. 8, a value for instructing the end is substituted for the end management variable of the audio data output thread. For this reason, if the value is assigned to the variable, the determination is YES, and the series of processing ends here. Otherwise, the determination is no and the process moves to step 403.

  In step 403, output data creation processing is executed for creating (generating) the audio data of the musical sound to be generated and storing it in the output buffer. In the next step 404, processing for sequentially outputting the audio data stored in the output buffer at the sampling period is executed. After the execution, the process returns to step 402. Thereby, while the musical tone generating application is activated, the processing loop formed in steps 402 to 404 is repeatedly executed.

  Next, the output data creation process executed as step 403 will be described in detail with reference to the flowchart shown in FIG. In the creation process, audio data for a plurality of sampling periods is created at a time and stored in an output buffer. “LSamples” in the figure is a constant indicating the number of audio data created at one time.

  First, in step 501, 0 is substituted for variable i. In the subsequent step 502, it is determined whether or not the value of the variable i is less than a constant lSamples. The value of the variable i is incremented every time audio data for one sampling period is created. For this reason, when all the audio data to be created at one time has not been created, the value of the variable i satisfies the relationship of less than the constant lSamples, so the determination is YES and the process moves to step 503. If not, that is, if all the audio data to be created has been created, the determination is no, and the series of processing ends here.

  In step 503, a value (= lTime + i / lSR) obtained by adding the value obtained by dividing the value of the variable i by the constant lSR to the value of the variable lTime is substituted into the variable lSTime. The value assigned to the variable lTime is a value indicating the time when the next audio data is to be output, and the constant lSR is a value indicating the sampling rate of the audio data stored in the output buffer. Accordingly, the value obtained by dividing the value of the variable i by the constant lSR is a value (value indicating time) obtained by multiplying the value of the variable i by the sampling period. For this reason, a value indicating the time at which target audio data is to be output is substituted into the variable lSTTime. After the substitution, the process proceeds to step 504.

  In step 504, 0 is substituted into a variable iValue for creating audio data for one sampling period. In the next step 505, an index value for designating the storage location of the pronunciation data located at the head of the pronunciation data storage area is substituted for the variable nd. In the next step 506, it is determined whether or not pronunciation data exists at the storage location specified by the value of the variable nd. If the pronunciation data does not exist, the determination is no and the process proceeds to step 516. Otherwise, the determination is yes and the process moves to step 507.

  In step 507, nd. It is determined whether or not the value of iStatus matches any one of -1, 1, and 2. If the value does not match any of them, the determination is no and the process moves to step 510. Otherwise, the determination is yes and the process moves to step 508. nd. By excluding the sound generation data whose iStatus value is 3 from the sound generation target, the sound generation of the musical sound outside the normal key pressing time is avoided (cases 1 and 3 in FIG. 7).

  A determination of YES in step 507 means that the musical sound corresponding to the pronunciation data currently being watched should be pronounced. Therefore, in step 508, a sampling data reading process for reading sampling data for generating the musical sound from the RAM 12 is executed. As a result, the sampling data is substituted into the variable iVtmp. The waveform data from which the sampling data is read is specified by referring to the source data specified by the data pSD. For this reason, waveform data for generating a set sound or a warning sound is selected according to the data pSD.

  In step 509 following step 508, nd. It is determined whether the value of iStatus is -1. If the value is −1, that is, if a musical sound corresponding to the pronunciation data currently being watched is being muted, the determination is yes and the process moves to step 512. Otherwise, the determination is no and a value obtained by adding the value of the variable iVtmp to the previous value (= iValue + iVtmp) is substituted for the variable iValue (step 510), and the variable nd. pNext is substituted (step 511). After the substitution, the process returns to step 506.

  In this way, for musical tones that are to be sounded and not being muted, the sampling data substituted into the variable iVtmp by executing the sampling data reading process in step 508 is added to the value of the variable iValue so far. Thus, the sound is generated according to the sampling data (waveform data) until the mute process is started.

  In steps 512 to 515 in which the determination in step 509 is YES and the process proceeds to step 512 to 515, processing for gradually decreasing the volume of the musical sound to be generated is performed until it can be considered that the sound has been muted. Since the value of the sampling data constituting the waveform data changes greatly, whether or not it can be regarded as silenced is determined based on the value of the data fRelease that is updated during the silencing process. “RED_OFF” and “RELEASE” in the figure are a constant set for the determination and a constant set for the data fRelease update, respectively.

  First, in step 512, the variable iVtmp is set to nd. The value (= iVtmp * fRelease) obtained by multiplying the value of fRelease, that is, the value of the data fRelease in the pronunciation data of interest, by the previous value is substituted. In the following step 513, it is determined whether or not the value of the data fRelease (nd.fRelease) is less than a constant RED_OFF. If the value is less than the constant RED_OFF, the determination is yes and the process proceeds to step 514. After performing an operation of resetting the data iStatus to 0 and other data, the process proceeds to step 510. Otherwise, the determination is no, the data fRelease is updated to a value obtained by multiplying the previous value by the constant RELEASE in step 515, and then the process proceeds to step 510.

  The determination of NO in step 406 means that the creation of audio data for one sampling period has been completed. Therefore, in step 516 where the determination is NO and the process proceeds to step 516, the value of the variable iValue is set as audio data for one sampling period, and the storage location specified by the value of the variable i in the output buffer together with the value of the variable lTime. To store. After the storage, the value of variable i is incremented in step 517, and then the process returns to step 502.

  FIG. 13 is a flowchart of the sampling data reading process executed as step 508 described above. Finally, the reading process will be described in detail with reference to FIG.

  First, in step 551, nd. Substitute the value of iStatus. In the next step 552, the variable lT is changed from the value of the variable lStime to nd. A value obtained by subtracting the value of lOnStart, that is, a value indicating the time elapsed since the start of the sound generation of the musical sound being generated by the sound generation data designated by the value of the variable nd is substituted. Thereafter, in step 553, nd. The value of pSD is assigned to the variable sd.

  In step 554 following step 553, the result of multiplying the variable lPos by the constant lSR multiplied by the value of the variable lT is obtained as sd. The remainder (= (lT *) obtained by dividing by the value specified by the value of the variable id in fLength (denoted as “sd.fLength [id]” in the figure. The notation is used hereinafter). lSR)% sd.fLength [id]) is substituted. Thereafter, the process proceeds to step 555, where sd. The waveform data specified by the value of the variable id in pData (denoted as “sd.pData [id]” in the figure. The notation is used hereinafter) is, for example, an array variable or a buffer. Store in pW. Here, a buffer is assumed as pW. After the waveform data is stored in the buffer pW, the process proceeds to step 556.

  In step 556, the sampling data designated by the value of the variable lPos in the waveform data stored in the buffer pW (the data of the value of the variable lPos from the beginning) is read and substituted into the variable iVtmp. In the next step 557, the variable iVtmp is set to nd. The value of iVel is set to sd. A value obtained by multiplying the value obtained by dividing the value of MaxVel by the value so far is substituted. In this manner, after updating the sampling data substituted for the variable iVtmp according to the ratio between the velocity value when the user actually presses the key and the upper limit value of the velocity range of the waveform data, the series of processing ends.

In this way, the waveform data corresponding to the value of the variable id (nd.iStatus) is referred to, and the sampling data read out and operated from the waveform data is finally substituted into the variable iVtmp and passed to the output data creation process. . For this reason, a musical tone of a type corresponding to the value of the data iStatus is generated.
<Second Embodiment>
In the first embodiment, two types of musical tones, a set sound and a warning sound, are generated according to the timing when the user actually presses the key to be pressed (FIG. 7). On the other hand, in the second embodiment, three types of musical sounds are generated according to the timing when the user actually presses the key.

  The configuration of the musical sound generating device in the second embodiment is basically the same as that in the first embodiment. The operation is largely the same or basically the same. For this reason, only the parts different from the first embodiment will be described using the reference numerals given in the first embodiment as they are.

  FIG. 14 is a diagram for explaining a musical sound generated by the musical sound generation control in the second embodiment. In FIG. 14, similar to FIG. 7, musical sounds that are pronounced according to cases 1 to 3 are shown. The contents of these cases 1 to 3 are the same as those in FIG.

  As shown in cases 1 and 3 in FIG. 14, in the second embodiment, a musical tone is generated if the user presses the key outside the normal key pressing time. Outside the normal key pressing time, a different kind of musical sound (referred to as “mistouch sound” for convenience) is generated differently from the set sound and warning sound.

  In case 1, the mistouch sound is emitted until the normal key pressing time comes regardless of whether the time a is sufficiently short. After the key pressing time has arrived, if the time a is sufficiently short, the sound is switched to the sound of the set sound, and thereafter, the sound is switched to the sound of the warning sound at the same timing as in the first embodiment, and the key pressing time is changed. The warning sound is sounded until it passes. On the other hand, if the time a is not sufficiently short, the mistouch sound is generated until the actual key pressing time elapses, and at the same time, a warning sound is generated over the entire normal key pressing time. Then, the sound is switched to the warning sound until the normal key pressing time elapses. For this reason, regardless of whether the time a is sufficiently short, the difference between the normal key pressing time and the actual key pressing time can be easily recognized from the generated musical sound.

  In case 2, if the time b is sufficiently short, a warning sound and a setting sound are generated in the same timing and order as in the first embodiment. When the time b is not sufficiently short, a warning sound is generated over the entire normal key pressing time as in the first embodiment. At the same time, a mistouch sound is generated over the entire actual key pressing time. Therefore, regardless of whether or not the time b is sufficiently short, regardless of whether or not the time a is sufficiently short, the difference between the normal key pressing time and the actual key pressing time can be easily made from the generated tone. Can be recognized.

  In case 3, the set sound is generated during the normal key pressing time as in the first embodiment. After the normal key pressing time has elapsed, the sound generation is continued by switching to the mistouch sound until the actual key pressing time has elapsed. For this reason, it is possible to easily recognize the difference between the timing at which the key is released and the timing at which the key is to be released from the generated musical sound.

  As described above, when the time a or b is not sufficiently short, a plurality of (two in this case) sound generation data are created. In cases 1 and 2, the pronunciation data for generating a warning sound over the entire key pressing time is created from the corresponding performance data, and the pronunciation data for generating a mistouch sound together with the warning sound is created from the user's operation. . In the first embodiment, sound generation control as shown in FIG. 7 is realized by using only one of them. On the other hand, in the second embodiment, the sound generation control as shown in FIG. 14 is realized by using them together. For this reason, in the second embodiment, the output data creation process shown in FIG. 12 differs from the first embodiment. Hereinafter, the different parts will be described in detail.

In the output data creation process shown in FIG. 12, it is determined in step 507 whether the value of the data iStatus (nd.iStatus) matches any of −1, 1, and 2. In the second embodiment, it is determined whether or not the value is zero. Thereby, if the value is 3, a mistouch sound is generated.
<Third Embodiment>
In the first and second embodiments, the sound generation control (including the avoidance of sound generation) to be generated is performed by paying attention to the timing when the user actually presses the key to be pressed. Yes. On the other hand, in the third embodiment, sound generation control is performed by paying more attention to the velocity when the user presses the key. By paying more attention to the velocity, the user can easily recognize whether or not the speed of the key press performed (velocity) is appropriate.

  The configuration of the musical tone generator in the third embodiment is basically the same as that in the first embodiment. The operation is largely the same or basically the same. Therefore, like the second embodiment, only the parts different from the first embodiment will be described using the reference numerals given in the first embodiment as they are.

  In the third embodiment, as shown in FIG. 5, whether or not the velocity indicated by the data Vel in the performance data coincides with the velocity at the time of the user's key depression within the allowable range as the data constituting the sound generation data. Data iVelAgree showing is prepared. The specific value is 1 if they match within the allowable range, and 0 otherwise. The initial value is 0. By controlling the volume of the musical sound to be generated according to the value of the data iVelAgle, it is possible to recognize whether or not the speed of the key depression performed is appropriate. In the present embodiment, if the value of the data iVelAgree is 1, the volume is reduced.

  The determination as to whether or not the velocity indicated by the performance data matches the actual velocity of the key depression within the allowable range, and the update of the data iVelAgree according to the determination result is shown in the MIDI IN process shown in FIG. 9 and FIG. This is realized by adding the flowchart shown in FIG. 15 to the reproduction processing shown.

  In the flowchart shown in FIG. 15, in step 601, the data Vel stored in the performance data indicated by the data pME in the pronunciation data specified by the value of the variable nd (represented as “nd.pME.Vel” in the figure) It is determined whether the absolute value of the subtraction value obtained by subtracting the value of the variable iVel (velocity pressed by the user) from the value of the velocity indicated by the performance data to be played is less than a constant ALLOW_VEL set as an allowable range. If the absolute value is less than the constant ALLOW_VEL, the determination is yes, the process moves to step 602, and the value of the data iVelAgree is updated to 1. Otherwise, the determination is no, and the process that moves after the execution of the process of step 602 is executed next without updating the data iVelAgree as out of the allowable range.

The flowchart shown in FIG. 15 is added / inserted between steps 208 and 209 in the MIDI IN process shown in FIG. 9, and added / inserted between steps 321 and 322 in the reproduction process shown in FIG. For example, if the value of the data iVelAgree is 1, the value of the variable iVel is multiplied by a coefficient (for example, 0.5) smaller than 1 for the volume control of the musical sound to be generated. This can be realized by storing the data as iOnVel, or by mounting an update function of the data iOnVel according to the value of the data iVelAgree in the sampling data reading process executed as step 508 shown in FIG.
<Fourth embodiment>
In the first to third embodiments, performance information prepared in advance is used. On the other hand, in the fourth embodiment, performance information indicating performance results actually performed can be stored and used.

  The configuration of the musical sound generating device in the fourth embodiment is basically the same as that in the first embodiment. The operation is largely the same or basically the same. Therefore, like the second and third embodiments, the reference numerals used in the first embodiment are used as they are, and only different portions from the first embodiment are described.

  In the fourth embodiment, a plurality of electronic musical instruments 20 can be connected to the MIDI I / F 16. The performance results are saved for each person who performed the ensemble. Therefore, in addition to the various data shown in FIGS. 2 to 6, the various data shown in FIGS. 16 to 18 can be managed. First, the data shown in FIGS. 16 to 18 will be described in detail. Data stored as performance results will be called recorded data. The recorded data includes stored data indicating performance results in musical tone units.

  FIG. 16 is a diagram for explaining the configuration of the recording data management data. The recorded data management data (hereinafter abbreviated as “management data”) is management data prepared for each performance (recording). As shown in FIG. 16, data Date indicating recording (performance) start date and time, data pUserList indicating storage location of corresponding participating user data (location of data at the top), and data indicating storage location of corresponding recording data pRecData, data prev indicating the storage location of the previous management data, and data next indicating the storage location of the next management data. Here, as in the above-described embodiments, an index value (pointer value) is assumed to indicate the storage location.

  FIG. 17 is a diagram illustrating the configuration of participating user data. The participating user data (hereinafter abbreviated as “user data”) is data prepared for each ensemble player. As shown in FIG. 17, data UserName indicating the corresponding ensemble player name (participating user name), data iCh indicating the played track, data pTone indicating the corresponding timbre data, and data indicating the storage location of the previous user data prev and data next indicating the storage location of the next user data.

  FIG. 18 is a diagram for explaining the configuration of stored data. The stored data is data prepared for each musical tone unit. Data iCh, data iPitch indicating the pitch of the musical tone, data iOnVel indicating the velocity thereof, data iResult indicating the performance judgment result of the musical tone (0 is an unpressed key, 1 is an appropriate key pressed, 2 is a value Delayed key press, value of 3 represents early key press, value of 4 represents incorrect key press (mistouch), respectively, data lOnStart indicating sounding start time by corresponding performance data, data indicating mute start time lOffStart, data lNoteOn indicating the key pressing time (timing) by the user, data lNoteOff indicating the key release time (timing), data prev indicating the storage location of the previous saved data, and data indicating the storage location of the next interpolation data next. Data iResult is also added to the pronunciation data shown in FIG.

Hereinafter, with reference to FIGS. 19 to 24, processing executed in the present embodiment will be described in detail.
FIG. 19 is a flowchart of the MIDI IN process executed as step 109 in FIG. The IN process is executed instead of the IN process shown in FIG. The same or basically the same processing contents as the steps shown in FIG. Accordingly, first, only parts different from the first embodiment will be described with reference to FIG.

  In the present embodiment, first, the determination process of step 212 is executed. If the determination is NO, the determination process of step 201 is executed next, and if the determination is YES, the process proceeds to step 213. If it is determined NO in step 201, the series of processing is ended here, and if it is determined YES, the process proceeds to step 202.

  After executing the process of step 219 or 222, the process proceeds to step 701. In step 701, nd. The current time is stored as lNoteOff, and in the subsequent step 702, nd. It is determined whether the iResult value is 2 or 3. If the value is either 2 or 3, the determination is YES, the process proceeds to step 703, and the element specified by each value of the variable nd of the array variable iReduce and the data iCh (“iReduce” in the figure). The value of “[nd.iCh]” is updated to a value obtained by adding 0.5 to the previous value (indicated as “iReduce [nd.iCh] + = 0.5” in the figure), Terminate the process. If not, that is, if the value is neither 2 nor 3, the determination is no and the process moves to step 704.

  In step 704, nd. It is determined whether the value of iResult is 4. If the value is 4, the determination is YES, the process moves to step 705, and the element specified by each value of the variable nd of the array variable fReduce and the data iCh (“fReduce [nd.iCh]” in the figure). The value of the notation is updated to a value obtained by adding 0.5 to the previous value (indicated as “fReduce [nd.iCh] + = 0.5” in the figure), and then the series of processes is terminated. Otherwise, the determination is no and the series of processing ends here.

  In the present embodiment, when the determination in step 205 is YES, the process proceeds to step 706, and the variable lDif is changed from the current time (indicating value) to nd. A value (corresponding to time b) obtained by subtracting the value of lOnStart (sounding start time) is substituted. In the following step 707, it is determined whether or not the value of the variable lDif is less than the constant DELAY_ALLOW. If the delay in timing of pressing the key is within the allowable range, the determination is yes and the process proceeds to step 708. Otherwise, the determination is no and the process moves to step 206.

  In step 708, nd. iStatus is 1, nd. 2 is stored as iResult respectively. After the storage, the process proceeds to step 709 to determine whether the value of the variable lDif is less than the constant DELAY_OK. If the value is less than the constant DELAY_OK, the determination is yes, and in step 710 nd. 1 is stored as iResult, and nd. lNoteOn as the current time (performance time from the beginning of the song), nd. After storing the value of the variable iVel as iOnVel, a series of processing ends. Otherwise, the determination is no and the process moves to step 711 next.

  The constant DELAY_OK is a value smaller than the constant DELAY_ALLOW. Therefore, if the timing at which the user presses the key is closer to the timing at which the key should be pressed, nd. The value of iResult is updated from 2 to 1.

  In the present embodiment, after the process of step 210 is executed, the process proceeds to step 712. In step 712, nd. iStatus is 2, nd. the index value of the source data corresponding to the value of the variable iPit as pSD, nd. The value of the variable iPit as iPitch, nd. iResult is 4, nd. The value of variable iCh, etc. is stored as iTone. Thereafter, the process proceeds to step 711.

  FIG. 20 is a flowchart of the reproduction process shown in FIG. The reproduction process is executed instead of the reproduction process shown in FIG. The same reference numerals are assigned to the same or basically the same processing contents as the steps shown in FIG. Accordingly, only parts different from the first embodiment will be described with reference to FIG.

  In the present embodiment, after executing the processing of step 311, the process proceeds to step 801, where nd. It is determined whether the iResult value is 0 or not. If the value is 0, the determination is yes, the process moves to step 802, and the element iReduce [nd. After incrementing the value of iCh], the process proceeds to step 307. Otherwise, the determination is no and the process moves to step 307.

  After executing the process of step 324, the process proceeds to step 803. In step 803, nd. iStatus is 2, nd. the index value of the source data corresponding to the value of the variable iPit as pSD, nd. i.Pitch me. Pitch, nd. iResult is 0, nd. The value of the variable iCh, etc. are stored as iCh. Thereafter, the process proceeds to step 804, where nd. lOnStart as me. lTime, nd. lOffStart as me. a value obtained by adding the sounding times indicated by lGate, nd. The value of the variable me and the like are stored as pME. In the next step 805, the value of the variable nd of the array variable iOrgCnt and the element specified by each value of the data iCh (indicated as “iOrgCnt [nd.iCh]” in the figure) are incremented. Thereafter, the process proceeds to step 323.

  In the present embodiment, when the determination in step 318 is YES, the process proceeds to step 806. In step 806, the variable lDif is changed from the current time (indicating value) to nd. A value obtained by subtracting the value of lNoteOn (key press time) (corresponding to time a) is substituted. In the subsequent step 807, it is determined whether or not the value of the variable lDif is less than the constant DELAY_ALLOW. If the timing of pressing the key is within the allowable range, the determination is yes and the process proceeds to step 808. Otherwise, the determination is no and the process moves to step 319.

  In step 808, nd. iStatus is 1, nd. 3 is stored as iResult respectively. After the storage, the process proceeds to step 809 to determine whether the value of the variable lDif is less than the constant DELAY_OK. If the value is less than the constant DELAY_OK, the determination is yes, and in step 810, the nd. After storing 1 as iResult, the process proceeds to step 804. Otherwise, the determination is no and the process moves to step 804 next.

  FIG. 21 is a flowchart of the data storage process. The saving process is a process for saving the performance result as recorded data, and is executed after the reproduction process shown in FIG. 20 is stopped (terminated). Next, the storing process will be described in detail with reference to FIG.

  First, in step 901, it is determined whether or not a recording flag, which is a variable for managing performance results, is set. When the user gives an instruction to save the performance result, a value considered to be set is substituted for the recording flag, so the determination is YES and the process proceeds to step 902. Otherwise, the determination is no and the series of processing ends here. In this embodiment, when the storage is instructed, the performance results of all the ensemblers are stored.

  In step 902, an index value indicating a location (free position) where new management data can be stored in the variable recList, an index value indicating a location where new user data can be stored in the variable usrList, and new saved data can be stored in the variable recDat. The index value of the place is substituted respectively, and recList. The value of the variable usrList is stored as pUserList. In the next step 903, usrList. iCh, usrList. As pTone, the track number of the target user (ensemble player) and data indicating the timbre data corresponding to the timbre are stored. Thereafter, the process proceeds to step 904.

  In step 904, it is determined whether or not there is a next connected keyboard, that is, another user who should save the performance result. If such a user exists, the determination is YES, the process proceeds to step 905, and an index value indicating a place where user data can be newly stored is substituted into the variable pNxt. Next, the value of the variable pNxt, pNxt. The value of the variable usrList is stored as prev, and then the value of the variable pNxt is substituted into the variable usrList, and the target ensembler is changed to another person before returning to Step 903. Thereby, user data is stored for all users. On the other hand, if not, the determination is no and the process moves to step 906.

In step 906 and subsequent steps, processing for creating and storing saved data from the pronunciation data is performed.
First, in step 906, an index value for designating the pronunciation data at the head position is substituted for the variable nd. In the subsequent step 907, recDat. iCh as nd. iCh, recDat. As iPitch, nd. iPitch, recDat. iOnVel as nd. iOnVel, recDat. nd. iResult, recDat. iOnStart as nd. iOnStart, recDat. iOffStart as nd. iOffStart, recDat. iNoteOn as nd. iNoteOn, recDat. iNoteOff as nd. iNoteOff is stored respectively.

  In step 908 following step 907, it is determined whether or not there is sound generation data positioned next to the sound generation data specified by the variable nd. If there is no next sounding data, that is, if the storage of the stored data is completed, the determination is no, and the series of processing ends here. Otherwise, the determination is yes, the process moves to step 909, and an index value indicating the location where the next stored data is stored is substituted into the variable pNxt, and recDat. Next, the value of the variable pNxt, pNxt. The value of variable recDat is stored as prev, and then the value of variable pNxt is stored in variable recDat and nd. After pNext is assigned, the process returns to step 907.

  As described above, in the present embodiment, performance results can be saved as saved data (recorded data). Therefore, it is possible to reproduce the recorded data and to generate a pronunciation guide using the recorded data. Next, with reference to FIG. 22 and FIG. 23, the process performed in order to implement | achieve them is demonstrated in detail. The process for realizing the former is called “recorded data reproduction process”, and the process for realizing the latter is called “recorded data guide reproduction process”. These processes are started when the entire process shown in FIG. 8 is executed, similarly to the reproduction process shown in FIG. When the stop is instructed, the corresponding reproduction stop flag is turned on. In addition, a desired part can be selected. The selection is performed by designating the track number, and the designated track number is substituted into the variable iMyCh.

FIG. 22 is a flowchart of the recorded data reproduction process. First, the reproduction process will be described in detail with reference to FIG.
First, in step 1001, an index value indicating the storage location of the stored data located at the head of the recording data is substituted into the variable rd. In the following step 1002, it is determined whether or not the reproduction stop flag is on. If the flag is turned on, the determination is yes, and after updating the values of all the sound generation data iStatus to 0 in step 1003, the series of processing ends. Otherwise, the determination is no and the process moves to step 1004.

  In step 1004, 1 is substituted into the variable AllOff, and the index value of the pronunciation data located at the head is substituted into the variable nd. In the next step 1005, it is determined whether there is sound generation data specified by the value of the variable nd. If the pronunciation data does not exist, the determination is yes and the process proceeds to step 1014. Otherwise, the determination is no and the process moves to step 1006.

  In step 1006, nd. It is determined whether or not the iStatus value is other than 0, that is, whether or not a musical sound is not generated by the sound generation data specified by the value of the variable nd. If the musical sound is not sounded, the determination is yes, and in step 1008, 0 is substituted into the variable AllOff, and the process proceeds to step 1009. Otherwise, the determination is no and the process proceeds to step 1007 where the variable nd is set to nd. After pNext is substituted, the process returns to step 1005.

  In step 1009, nd. It is determined whether or not the value of iCh matches the value of the variable iMyCh. If the values match, the determination is yes and the process moves to step 1012. Otherwise, the determination is no and the process moves to step 1010.

  In step 1010, nd. It is determined whether the key release time indicated by lNoteOff is before the current time. If the key release time is before the current time, the determination is YES, and the corresponding musical sound should be muted. After storing −1 as iStatus, the process proceeds to step 1007. Otherwise, the determination is no and the process moves to step 1007.

  In step 1012, nd. It is determined whether the mute start time indicated by lOffStart is before the current time. If the start time is before the current time, the determination is YES, and the corresponding musical sound should be muted. After storing −1 as iStatus, the process proceeds to step 1007. Otherwise, the determination is no and the process moves to step 1007.

  In step 1014 where the determination in step 1005 is YES and the process proceeds to step 1014, the value of the variable AllOff matches 1 and there is no storage data specified by the value of the variable rd (the storage data targeted immediately before is the last one). Whether or not). If the value matches 1 and the stored data does not exist, the determination is yes, and the series of processing ends here. Otherwise, the determination is no and the process moves to step 1015.

  In step 1015, the variable lTime is set to rd. The value of lNoteOn (key pressing time) is substituted. In the following step 1016, it is determined whether or not the key pressing time indicated by the value of the variable lTime is before the current time (time from the start of reproduction). If the key pressing time (timing to press the key) is before the current time, the determination is yes and the process proceeds to step 1017. Otherwise, the determination is no and the process returns to step 1002.

  In step 1017, the index value of the pronunciation data located at the head is substituted for the variable nd. nd. The index value of the pronunciation data that has been positioned last is stored as pPrev, and the data pNext in the pronunciation data is updated to the value of the variable nd. nd. As pNext, a value indicating the sound data positioned at the end is stored. In step 1018 to which the process proceeds after the storage, nd. iStatus is 2, nd. prd as rd. iPitch, rd. data corresponding to iCh, nd. rd. iPitch, nd. iResult is 0, nd. iCh as rd. Each iCh is stored. In the next step 1019, nd. current time as lOnStart, nd. lOffStart, at the current time, rd. From the value of lOffStart, rd. A value obtained by adding a value (sounding time) obtained by subtracting the value of lOnStart is stored. Thereafter, in step 1020, the rd. After substituting next, the process returns to step 1002.

  FIG. 23 is a flowchart of the recorded data guide reproduction process. Next, the guide reproduction process will be described in detail with reference to FIG. In FIG. 23, the same reference numerals are given to the same or basically the same steps as the processing contents of the steps executed in the reproduction processing shown in FIG. Accordingly, only different portions from the reproduction process shown in FIG. 20 will be described in detail.

  In this recording data guide reproduction process, first, in step 1101, an index value for designating the storage data located at the head of the recording data is substituted for the variable rd, and the channel number (track number) designated by the user for the variable iMyCh. Is assigned. Thereafter, the process proceeds to step 302.

  After substituting 0 for the variable AllOff in step 308, the process proceeds to step 1102, where nd. It is determined whether or not the value of iCh matches the value of the variable iMyCh. If these values match, the determination is yes and the process moves to step 1105. Otherwise, the determination is no and the process moves to step 1103.

  In step 1103, nd. It is determined whether the key release time indicated by lNoteOff is before the current time. If the key release time is before the current time, the determination is YES, and the corresponding musical sound should be muted. After storing −1 as iStatus, the process proceeds to step 309. Otherwise, the determination is no and the process moves to step 309.

  In step 1105, nd. It is determined whether the mute start time indicated by lOffStart is before the current time. If the start time is before the current time, the determination is yes and the process moves to step 310. Otherwise, the determination is no and the process moves to step 309 above.

  In step 1106 where the determination in step 801 is YES and the process proceeds to step 1106, the element iReduce [iMyCh] is set to the nd. pME. A value obtained by adding the values of fPtiority is substituted. Thereafter, the process proceeds to step 307. The array variable iReduce is prepared, for example, for counting the number of times a key to be pressed is not pressed for each track (channel).

  In step 1107, in which the determination in step 314 is NO and the process proceeds, the variable lTime is set to rd. Substitute lOnStart. In the following step 1108, rd. It is determined whether or not the value of iCh matches the value of the variable iMyCh. If these values match, the determination is yes and the process proceeds to step 1109 where the variable lTime is set to rd. After substituting lNoteOn, the process proceeds to step 315. Thereby, the timing at which the key should be pressed is changed from the performance result to that of the performance data. On the other hand, if not, the determination is no and the process moves to step 315. Note that such timing change may not be performed. In that case, steps 1108 and 1109 may be omitted, the process of step 1107 may be executed, and then the process may proceed to step 305.

  If the determination in step 315 is YES, the process proceeds to step 1110, where rd. It is determined whether the value of iCh matches the value of variable variable iMyCh. If these values do not match, the determination is no, and in step 1115, the index value of the pronunciation data located at the head is substituted into the variable nd, and the value of the element iOrgCnt [iMyCh] is further incremented, and then the process proceeds to step 317. To do. Otherwise, the determination is yes and the process moves to step 324, and after the process is executed, the process moves to step 1111.

  In step 1111 nd. iStatus is 2, nd. prd as rd. iPitch source data index value, nd. rd. iPitch, nd. iResult is 0, nd. iCh as rd. iCh, etc. are stored respectively. Thereafter, the process proceeds to step 1112, where nd. The value of the variable lTime as lOnStart, nd. lOffStart, rd. From the value of lOffStart, rd. The value obtained by adding the value obtained by subtracting the value of lOnStart to the current time, etc. are stored. In the next step 1113, the variable rd is set to rd. Next is substituted. After the substitution, the process proceeds to step 1114 and rd. The value of iCh matches the value of variable variable iMyCh, and rd. It is determined whether the value of iResult matches 4. If these values match, the determination is yes and the process of step 1113 is executed again. If not, that is, if at least one of them does not match, the determination is no and the process returns to step 302 above.

  FIG. 24 is a flowchart of output data creation processing in the present embodiment. The creation process is executed as step 403 shown in FIG. 11 instead of the creation process shown in FIG. Next, with reference to FIG. 24, the creation processing in the present embodiment will be described in detail. Here, as well as others, only the parts different from the first embodiment will be described by assigning the same reference numerals to the same or basically the same processing contents of the steps shown in FIG.

  In the present embodiment, after executing the sampling data reading process in step 508, the process proceeds to step 1200, and rd. It is determined whether the value of iCh matches the value of variable variable iMyCh. If the values do not match, the determination is no and the process moves to step 509. Otherwise, the determination is yes and the process moves to step 1201, and nd. The iStatus value is determined. If it is determined that the value is 2, the process proceeds to step 1202, and a value twice as much as the previous value is substituted for the variable iVtmp. If it is determined that the value is 3, the process proceeds to step 1203, and a value ½ of the previous value is substituted for the variable iVtmp, and then the process proceeds to step 509. Thereby, the volume control is performed so that the volume of the musical sound is reduced if the key is depressed at a timing when the key should not be depressed, and is increased when the key is not depressed at the timing when the key is depressed. Such volume control may be applied to the second or third embodiment.

  In the present embodiment (first to fourth embodiments), the present invention is applied to a data processing apparatus such as a PC. The application is realized by causing the data processing apparatus to execute a musical tone generating application corresponding to the program according to the present embodiment. Such an application may be developed for musical tone generators such as electronic musical instruments and tone generators. The developed application may be distributed by being recorded on a recording medium such as a CD-ROM, a DVD, or a removable flash memory. Part or all of the program may be distributed via a communication network such as a public network. In such a case, the user can apply the present invention to the device by acquiring the program and loading it into the data processing device or the musical sound generating device. Therefore, the recording medium may be accessible by a device that distributes the program.

It is a figure explaining the structure of the musical tone generator by 1st Embodiment. It is a figure explaining the structure of timbre data. It is a figure explaining the structure of pitch data. It is a figure explaining the structure of source data. It is a figure explaining the structure of pronunciation data. It is a figure explaining the structure of performance data. It is a figure explaining the musical sound sounded by the sound generation control of a musical sound. It is a flowchart of the whole process. It is a flowchart of a MIDI IN process. It is a flowchart of a reproduction process. It is a flowchart of the process implement | achieved by execution of an audio data output thread | sled. It is a flowchart of an output data creation process. It is a flowchart of a sampling data reading process. It is a figure explaining the musical sound sounded by the sound generation control of a musical sound (2nd Embodiment). 10 is a flowchart of a portion added to a MIDI IN process and a reproduction process in the third embodiment. It is a figure explaining the structure of recording data management data. It is a figure explaining the structure of participating user data. It is a figure explaining the structure of preserve | saved data. It is a flowchart of a MIDI IN process (4th Embodiment). It is a flowchart of a reproduction | regeneration process (4th Embodiment). It is a flowchart of a data preservation | save process. It is a flowchart of a recording data reproduction process. It is a flowchart of a recording data guide reproduction process. It is a flowchart of an output data creation process.

Explanation of symbols

10 Musical sound generator 11 CPU
12 RAM
13 ROM
14 Input unit 15 Display unit 16, 21 MIDI interface (I / F)
17 Audio increment (I / F)
20 Electronic musical instrument 22 Keyboard 30 Sound source system

Claims (5)

In a musical sound generating device that generates a musical sound according to a performance operator operated in a group of performance operators,
Acquire performance information indicating the performance operators to be operated sequentially in accordance with the progress of the performance in the group of performance operators and the operation period for which the performance operators should be operated in units of the performance operators. Performance information acquisition means to perform,
Operation detecting means for detecting an operation to the performance operator group;
Based on the operation period indicated by the performance information acquired by the performance information acquisition means, the performance operator, and the detection result of the operation detection means by the operation detection means, the type of musical sound to be generated within the operation period is determined. Sound generation control means for determining one or more and generating the determined one or more types of musical sounds for at least the operation period;
A musical sound generating device comprising: The sound generation control means selects different types of musical tones depending on whether or not the timing at which the operation detection means detects the operation start of the performance operator during the operation period is within an allowable range with the start timing of the operation period. And make it sound within the operation period,
The musical tone generator according to claim 1. When the detection period during which the operation detection unit has detected an operation on the performance operator during the operation period is within the operation period, the sound generation control unit operates during a period outside the detection period within the operation period. To play a kind of musical sound that informs you that you are not operating the performance controls
The musical tone generator according to claim 1 or 2, wherein When the performance operator group is a keyboard, the operation detection means also detects the speed at the time of pressing a key constituting the keyboard,
The sound generation control means performs an operation of a musical sound to be generated within the operation period in consideration of the speed detected by the operation detection means.
The musical tone generator according to claim 1, 2, or 3. A program to be executed by a musical sound generating device for generating a musical sound according to a performance operator operated in a group of performance operators,
Acquire performance information indicating the performance operators to be operated sequentially in accordance with the progress of the performance in the group of performance operators and the operation period for which the performance operators should be operated in units of the performance operators. Function to
A function for detecting an operation on the group of performance operators;
Based on the operation period indicated by the performance information acquired by the acquired function, the performance operator, and the detection result by the function for detecting the operation on the performance operator, the type of musical sound to be generated within the operation period A function for generating one or more of the determined sounds and at least one of the determined types of musical sounds for at least the operation period;
A program to realize