JP2007041174A - Concert embodying method, network concert system, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technique for supporting players so as to have efficient practice in concert using a network. <P>SOLUTION: When a concert by three players A to C is virtually actualized, the concert is actualized by a musical performance comprising three stages. Musical performance information obtained by a musical performance by the player A in the first stage is sent to the player B who plays in the following second stage to provide an environment wherein the player B can play while listening to the musical performance by the player A. To the player C who plays in the final third stage, the musical performance information by the musical performance by the player A is sent from the player B together with musical performance by himself or herself to provide an environment wherein the player C can play while listening to the musical performance by the players A and B. Thus, the players of the respective stages are provided with environments wherein they play in concert while listening to musical performances by players of upper stages. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a technique for virtually enabling ensemble by a plurality of performers using a network.

  Ensemble performed by two or more musical instruments can be enjoyed and enjoyed by many people because it allows you to enjoy the fun and fulfillment that is different from when you play alone. In the ensemble, it is desirable that all members (performers) who perform it gather in the same place. However, this is often difficult due to the circumstances of individual members, time and geographical circumstances. For this reason, as described in Patent Document 1, for example, a device that can support music activities for performing ensembles has been devised.

  In the conventional network ensemble system described in Patent Document 1, performance information indicating the performance content performed by each member is acquired via the network, and is recorded in association with each other. As a result, the performance performed by each member can be confirmed as a result of the ensemble. Patent Document 2 describes a technique for transmitting performance information via a network so that occurrence of musical problems can be avoided.

  In the conventional net ensemble system, each member performs in parallel by notifying the start of performance. To that end, each member basically performed according to their own ideas.

  As is well known, it is necessary to consider the overall unit in an ensemble. The sense of unity is difficult to obtain if each member performs a performance (single solo) according to his / her own thoughts. By confirming the ensemble results, each member can perform with a sense of unity. However, for that purpose, the confirmation of the ensemble result must be performed as needed, so that the time allocated to the performance (performance for the ensemble) becomes shorter. Since it is usually necessary to check the ensemble results many times in order to accurately grasp the performance of the performance by other members, it is normal (to be in the same place) to be able to perform according to the performance of other members. It will take much longer than an ensemble).

As described above, in the conventional net ensemble system described in Patent Document 1, it has been difficult to perform efficient practice so that a desired ensemble can be realized. The way of thinking and sensibility usually varies depending on the performer, and in order to be able to perform a concert with a sense of unity, it is a fact that many ensembles must be practiced. Therefore, it is considered extremely important to be able to practice ensemble efficiently.
JP 2004-212632 A JP 2000-181447 A

  An object of the present invention is to provide a technique for supporting so that efficient practice of ensemble can be performed using a network.

  The ensemble realization method of the present invention is a method for virtually enabling ensemble by a plurality of performers using a network, and for each performer who desires an ensemble, the performer performs the ensemble. Other performers who should transmit performance information indicating the performance details performed are set in advance as transmission subjects, and the performances of the performers themselves are set on the respective terminal devices used by the performers in which the transmission target exists. The performance information is transmitted to the network, and, depending on the setting, the other performers are used for each terminal device used by the performer who is the transmission target person and the other performers who are the transmission target person. The performance information transmitted and received from the terminal device used by the player is further transmitted on the network, and each performer who is the transmission target is combined with the performance of one or more performers by the performance information received by the terminal device. Kanade respectively to perform the virtually realizing the ensemble with.

  A network ensemble system according to a first aspect of the present invention is a system for virtually realizing a ensemble for a user of a terminal device connected via a network. Information receiving means for receiving performance information indicating the performance contents performed from the terminal device in real time, and when a plurality of users perform ensembles, according to the relationship in which performance information preset between the plurality of users should be transmitted and received, And information transmitting means for transmitting the performance information received by the information receiving means to the terminal device used by the user specified by the user of the terminal device that has transmitted the performance information as necessary.

  The network ensemble system according to the second aspect of the present invention, in addition to the configuration of the first aspect, information for storing performance information received by the information receiving means from the terminal device that the user is performing for the ensemble. Storage means.

  The program of the present invention is based on the premise that the program is executed by a data processing apparatus used for construction of a network ensemble system that virtually realizes an ensemble for users of terminal devices connected via a network. , A function for receiving performance information indicating the performance performed by the user on the musical instrument from the terminal device in real time, and when a plurality of users perform ensembles, transmission and reception of performance information set in advance between the plurality of users According to the relationship to be performed, a function of transmitting performance information received by the receiving function to a terminal device used by the user specified by the user of the terminal device that has transmitted the performance information as necessary is realized.

  In the present invention, for each performer who desires an ensemble, another performer who should transmit performance information indicating the performance performed by the performer for the ensemble is set in advance as a transmission target, and the transmission target A player who has both a performer and another performer who is the subject of transmission exist in the terminal device used by the performer who has the present Each terminal device to be used is further caused to transmit performance information transmitted and received from the terminal device used by other performers on the network.

  By performing transmission / reception of such performance information, performance information obtained by the performance of one or more other performers is sent via the network to each performer who is a transmission target. For this reason, the environment which can perform the performance combined with the performance of one or more other players who can be reproduced by the performance information sent is provided. By providing the environment, a performer who is a transmission target can substantially perform an ensemble with other performers. As a result, a performance that provides a sense of unity, or a performance that realizes a desired musical expression as a whole becomes easier.

  This means that a more desirable performance can be more easily performed on the ensemble. This makes it possible to practice with higher quality than when performing ensemble practice (performance) without listening to the performances of other performers. Since more performers can perform a higher quality performance on the ensemble, the confirmation of the ensemble result can be performed more easily and in a shorter time. They all work to make more efficient practice.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
FIG. 1 is a diagram for explaining a configuration of a network system constructed using the net concert system according to the present embodiment.

  As shown in FIG. 1, the network system includes a server 2, a plurality of personal computers (PCs) 3 that are terminal devices used by each viewer, and a terminal device used by each performer. A plurality of PCs 4 are connected and constructed.

  The network 1 includes, for example, the Internet and a public network that connects the PC 3 or 4 to the Internet. Each musical instrument PC 4 is connected to an electronic musical instrument 5 on which the user performs. The PC 4 transmits performance information indicating the contents of performance operation to the electronic musical instrument 5 to the server 2. The server 2 provides a service for receiving performance information transmitted from the PC 4 and automatically transmitting it to other PCs 4 or 3 as necessary. With this service, the user of the PC 3 can view the performance performed by the user of the PC 4. The network concert system according to the present embodiment is realized on the server 2.

  FIG. 2 is a diagram for explaining the configuration of the server 2. As shown in FIG. 2, the server 2 includes a CPU 21 that performs overall control, a RAM 22 that the CPU 21 uses for work, a ROM 23 that stores a startup program executed when the power is turned on, and the network 1. A network interface 24 for performing communication, a keyboard, a pointing device (mouse, etc.), a medium driving device for accessing a recording medium such as a CD-ROM or DVD, an input device 25 comprising these interfaces, and a display device The display unit 26 displays an image, an auxiliary storage device 27 that is a hard disk device, for example, and a bus 28 that connects the units 21 to 27 to each other.

  When the power is turned on, the CPU 21 reads out and executes the startup program stored in the ROM 23, thereby accessing the auxiliary storage device 27 by its control. By the access, the OS (operating system) stored in the auxiliary storage device 27 is read, and control is transferred to the OS. Thereafter, an application program (hereinafter abbreviated as “application”) running on the OS is executed. The service is realized by executing a corresponding application.

FIG. 3 is a diagram illustrating the configuration of the PC 4 and the electronic musical instrument 5.
As shown in FIG. 3, the PC 4 includes a CPU 41, a RAM 42, a ROM 43, a network interface 44, an input device 45, a display unit 46, a MIDI interface (I / F) 47, an auxiliary storage device 48, and a bus 49. It has become. Thereby, it has almost the same configuration as the server 2. The MIDI I / F 47 that does not exist in the server 2 is used to transmit / receive MIDI data to / from the electronic musical instrument 5.

  As shown in FIG. 3, the electronic musical instrument 5 generates a MIDI I / F 51 for transmitting / receiving MIDI data to / from the PC 4, a keyboard 52 as a performance operation target, and waveform data of a musical sound to be emitted. And a sound source / sound system (hereinafter abbreviated as “sound source system”) 53 for emitting sound.

  The keyboard 52 of the electronic musical instrument 5 detects, for example, a user's operation on a key, and outputs a key with the detected operation and operation information indicating the operation content to the MIDI I / F 51. The I / F 51 generates, for example, MIDI data corresponding to the operation information and outputs the MIDI data to the sound source system 53 and the MIDI I / F 47 of the PC 4. The MIDI data input from the I / F 47 is also output to the sound source system 53. Thereby, a musical sound is emitted according to a performance operation performed by the user on the keyboard 52 and a musical sound is emitted according to the MIDI data output from the PC 4. Thus, the PC 4 and the electronic musical instrument 5 connected thereto constitute a performer system that can transmit and receive performance information indicating the performance contents performed by the user to the electronic musical instrument 5 via the network 5. In the present embodiment, MIDI data is adopted as the performance information.

  The other PC 3 has the same configuration as the PC 4 or a system corresponding to the sound source system 53. Here, for convenience of explanation, it is assumed that the sound source system 53 is mounted instead of the MIDI I / F 47 in the configuration shown in FIG. Based on this assumption, the code of PC4 is used as the component code.

  When the PCs 3 and 4 are powered on, the CPU 41 reads out and executes the startup program stored in the ROM 43, thereby accessing the auxiliary storage device 48 by its control. By the access, the OS (operating system) stored in the auxiliary storage device 48 is read, and control is transferred to the OS. Thereafter, control is performed in accordance with a user instruction via the input device 45. The activation / termination of an application program (hereinafter abbreviated as “application”) operating on the OS is realized by its control.

FIG. 4 is a diagram for explaining a method of realizing a virtual ensemble. The realization method is a case where an ensemble by three members of performers A to C is virtually realized.
In the present embodiment, as shown in FIG. 4, virtual ensembles by three members of performers A to C are realized by performances performed in three stages. The performance information obtained when the performer A performs in the first stage is sent to the performer B performing the next second stage performance so that the performance can be performed while listening to the performance (the performers A and A). To performer B). The performer C who performs in the final third stage listens to the performances of the performers A and B by sending performance information based on the performance of the performer A together with performance information based on the performance of the performer B. However, the player C is provided with an environment in which performance can be performed (environment in which the ensemble with the performers A and B can be performed). When the performer C performs in the third stage, the final result of the ensemble by all the performers A to C is obtained. The viewer D is a person to whom performance information obtained by the performance of each of the performers A to C is sent as a result, and any of the performers A to C can be the viewer D.

  In this way, in the present embodiment, performance information on the performance performed in the performance stage located upstream from the performer in each performance stage is provided to the first stage ( Other than the performer A who performs at the most upstream performance stage), the performance (ensemble) according to the performance can be performed while listening to the performance performed at the upstream performance stage. For this reason, for a performer other than the first stage, a performance that gives a sense of unity (a desired musical expression is realized) as a whole, that is, a performance that is more appropriate for an ensemble. It becomes possible to perform easily. Thereby, the performance for the ensemble can be practiced more efficiently.

  If a performer other than the first stage can perform a higher quality performance on the ensemble, there are fewer undesirable performance methods and performance points on the ensemble. For this reason, the confirmation of the ensemble result can be performed more easily, and the time required for the confirmation can be further shortened. This also means that you can practice more efficiently.

  The performer A in the first stage is performed by other performers while listening to the performance. Therefore, the performer A performs a performance that other performers should perform, performs a performance as a base of the ensemble, or most. It is desirable to be a good performer. By making such a person a performer A, a more desirable ensemble result can be obtained more easily.

  In this embodiment, only one performer is provided at each performance stage, but there may be a plurality of performers at performance stages other than the first stage. In that case, it is not necessary for all the plurality of players to play the same type of instrument or part. The number of performance stages may be two or more, and may be appropriately determined in consideration of the ensemble, the number of performers, the number of parts to be played, and the like. Since the performance information transmitted on the network 1 is clear from the transmission source (performer), the performance information is collected for each performer even if there are a plurality of performers at any performance stage. be able to.

  When each performer performs a performance divided into performance stages, the other party to whom performance information should be sent to each performer and the other party to whom performance information should be sent from that performer are automatically specified according to the performance stage of that performer. can do. For this reason, in the present embodiment, an implementation method as shown in FIG. 4 is adopted, but other performers who should transmit performance information to the performers may be individually set for each performer. good. Several flow patterns (for example, showing the relationship between the performance position and the performance position where performance information is transmitted and received) are prepared, and the performance position of each performer may be specified on the pattern. good. Of course, other methods may be employed.

  The ensemble as shown in FIG. 4 is realized by the CPUs 21 and 41 of the server 2 and the PC 4 (PC 3) respectively executing dedicated applications. Hereinafter, an operation for realizing the ensemble will be described in detail for each of the server 2 and the PC 4 with reference to the explanatory diagrams of FIGS.

  The server 2 provides a service (ensemble service) that enters between the PCs 4 and realizes transmission / reception of performance information as shown in FIG. For the user of PC3 (viewer D), a service (viewing service) is provided that provides performance information stored as an ensemble result. In order to provide these services, data as shown in FIG. 5 is managed. FIG. 5A shows a data structure of a user database (DB) for managing users of PCs 3 and 4 that provide services, and FIG. 5B shows a structure of a ring buffer for transmitting and receiving data between the PCs 4. Show.

  As shown in FIG. 5A, the user DB stores data iFD, cUserID, cStat, and cUserMode for each user. The data iFD is a communication identification number that is different for each user, and the PCs 3 and 4 add it to the data to be transmitted. Data cUserID is a user ID, data cStat is data for managing whether or not the corresponding user is connected (logged on), and data cUserMode is data for managing the mode of the corresponding user. As the user mode, only the performers A to C and the viewer D are considered here.

  As shown in FIG. 5B, the ring buffer includes a portion indicating “buffer” (hereinafter referred to as “data buffer”), a portion indicating “iSize” (hereinafter referred to as “size buffer”), and It is composed of three parts, “iUDDBid” (hereinafter referred to as “user buffer”). The data buffer stores the main body (substance) of data received from the PC 4. The size buffer stores the size of data stored in the data buffer. In the user buffer, identification information (here, data iFD) indicating the user who has transmitted the data stored in the data buffer is stored. Thereby, the ring buffer can refer to the data body, the data size, and the index value indicating the record in the user DB storing the data of the user who transmitted the data as a set. In FIG. 5A, “0” or “n” in [] represents the index value. The data size and identification information are extracted from the received data.

The user DB is stored in the auxiliary storage device 27 and is read out to the RAM 22 for reference / update. The ring buffer is an area secured in the RAM 22.
FIG. 7 is a flowchart of overall processing executed by the server 2. The overall process is an excerpt of the process executed by the server 2 to provide the ensemble service and the viewing service. The service providing application is read out from the auxiliary storage device 27 to the RAM 22 and executed by the CPU 21. Next, the entire process will be described in detail with reference to FIG.

  First, in step 101, initialization such as reading of a user DB, initialization of various variables and a ring buffer, and preparation for transmission / reception with PCs 3 and 4 as clients is performed. In the next step 102, a thread to be executed in parallel is activated. As one of the threads, there is a transmission thread whose flowchart is shown in FIG. The transmission thread is for realizing transmission / reception of data between the PCs 4.

  In step 103 following step 102, 1 is substituted into the variable iCont. After the substitution, the process proceeds to step 104 to determine whether the value of the variable iCont is 1. If the value is 1, the determination is yes and the process proceeds to step 105. If not, the determination is no and the series of processes ends here. As described above, the variable iCont is for managing the termination of the application, and a detailed description thereof is omitted. However, according to the termination instruction from the administrator, another application or the OS may substitute a value other than 1. It has become.

  In step 105, it waits to receive data from the PCs 3 and 4 (hereinafter collectively referred to as “client”). When the data is received by the network interface 24, the determination is YES, the process proceeds to step 106, and 0 is substituted for the variable fd. In the next step 107, it is determined whether or not the value of the variable fd matches the value of the data iFD included in the received data. If the values match, the determination is yes and the process moves to step 109. Otherwise, the determination is no, the value of the variable fd is incremented at step 108, and then the determination process at step 107 is performed again. Thereby, the value of the data iFD included in the received data is specified.

  In step 109, it is determined whether or not the received data is a logoff request. If the logoff is requested, the determination is yes and the process proceeds to step 110, where the data cStat stored in the record of the user who requested logoff of the user DB is updated to the logoff and the logon is performed. After the network interface 24 transmits information for notifying the user who has logged off to the client used by the user, the process returns to step 105. Otherwise, the determination is no and the process moves to step 111.

  In step 111, a value (denoted as “ring buffer pointer” in the figure) indicating a place where received data is to be stored in the data buffer constituting the ring buffer is substituted into the variable buf. Corresponding to the storage of the received data in the data buffer, values indicating the locations where the data should be stored in the size buffer and the user buffer (both expressed as “ring buffer pointer” in the figure) are variables iSizePtr and iUDPTr. (Steps 112 and 113). After the substitution, the process proceeds to step 114, where the received data is stored from the location specified by the value of the variable buf in the data buffer, and the size (indicated at the location specified by the value of the variable iSizePtr in the size buffer). Value). The process proceeds to step 115 after the storage.

  In step 115, 0 is substituted for variable j. In the following step 116, data iFD stored in a record having the value of the variable j of the user DB as an index value (denoted as “udb [j] .iFD” in the figure. Other data uses the same notation) It is determined whether or not the value of the value matches the value of the variable fd. If the values match, the determination is yes and the process moves to step 118. Otherwise, the determination is no, and after the value of variable j is incremented in step 117, the determination process in step 116 is performed again. Thereby, the index value of the record corresponding to the user who has transmitted the received data is specified.

  In step 118, the value of variable j is stored as the index value of the record corresponding to the user who sent the received data at the location specified by the value of variable iUDBPPtr in the user buffer. In the next step 119, in each of the data buffer, the size buffer, and the user buffer, a value (denoted as “ring buffer pointer” in the figure) indicating the location where the next data is to be stored is updated. After the update, the process proceeds to step 120.

  When a client user makes a request other than logoff to the server 2, data corresponding to the request is transmitted from the client to the server 2. In step 120 and subsequent steps, processing for dealing with such data is performed. Here, only a logon request, a mode change request, a recording request, and a playback request are assumed as the requests. The recording request is for requesting recording (storing) of the ensemble result to be viewed by the viewer D, and the reproduction request is for requesting reproduction of the ensemble result.

  First, in step 120, it is determined whether the received data is a request for logon. If the log-on is requested, the determination is yes, the process proceeds to step 121, the authentication process is executed, and then the process returns to step 105. Otherwise, the determination is no and the process moves to step 122 to determine whether or not the received data is a request for changing the user mode. If it is a request to change the mode, the determination is YES, and after executing the user mode update process for responding to the request in step 123, the process returns to step 105. Otherwise, the determination is no and the process moves to step 124.

  In the user mode update process of step 123, the data cUserMode stored in the record having the value of the variable j as the index value in the user DB is updated to the one representing the mode specified by the received data. By performing such an update, the user of the client can arbitrarily change to one of the performers A to C and the viewer D. The record with the changed user mode is sent to all clients used by the logged-on user.

  In step 124, it is determined whether or not the received data is a request for recording or reproduction. If the recording or reproduction is requested, the determination is YES, the process proceeds to step 125, the requested recording or reproduction is started, and the process returns to step 105. Otherwise, the determination is no and the process returns to step 105.

FIG. 8 is a flowchart of the authentication process executed as step 121 described above. Next, the authentication process will be described in detail with reference to FIG.
In the present embodiment, as described above, in order to use the service provided by the server 2, a dedicated application is executed by the client. The application is recorded on a recording medium such as a CD-ROM together with a different ID (data cUserID) for each application, and is distributed to those who desire ensemble using the network. The application transmits the data cUserID assigned to itself when a logon request is made.

  The data iFD stored in the user DB is assigned to the user who requested the logon according to the situation at that time. For this reason, when the received data is for a logon request, no data corresponding to the data iFD is added to the received data. In order to cope with such received data, although not particularly shown, in step 107, if the data cUserID is added to the received data, the determination is YES. Further, in the processing loop formed in the above steps 116 and 117, the data iFD of the record having the value of the variable j as an index value is sequentially referred to until the record in which no data is stored is found, so that the data iFD is obtained. An assignable value (for example, the minimum value) is specified, and the specified value is substituted into the variable fd. The authentication process is executed under a situation where such a value is assigned to the variable fd.

  First, in step 201, 0 is substituted for variable j. In the following step 202, a record having the value of the variable j in the user DB as an index value is referred to, and it is determined whether or not data is stored in the record. The user DB allows a record in which data is stored to be specified by one of continuous index values. That is, when one record from which data has been erased due to the deletion of user registration is generated, the data of each record having a larger index value is copied to the record having a smaller index value than before. For this reason, when all the records in which data is stored are referred to, no data is stored in the record to be referred to next by the value of the variable j. As a result, the determination is yes and the process proceeds to step 208. Otherwise, the determination is no and the process moves to step 203. The determination of YES means that an unregistered user has made a logon request.

  In step 203, it is determined whether the data cUserID of the record to be referenced is the same as the data cUserID existing in the received data. If they are the same, the determination is yes and the process moves to step 205. Otherwise, the determination is no, the variable j is incremented in step 204, and the process returns to step 202. The determination of YES means that a registered user has made a logon request.

  In step 205, the value of the variable fd is stored as data iFD (indicated as “udb [j] .iFD” in the figure) of the record having the value of the variable j of the user DB as the index value. In the next step 206, 1 is stored as the data cStat of the record, indicating a value of 1 indicating the logon state. At the next step 207, the value 1 representing the player A is stored as the data cUserMode of the record, and the received data is stored at the location specified by the value before the update at step 119 of the variable iUDPTr in the user buffer. The value of the variable j is stored as the index value of the record corresponding to the user who has transmitted. After the storage, the user DB is transmitted to the client of the authenticated user. The user's record is sent to all other users' clients who are logged on. After performing such transmission, the series of processing ends.

  In the overall process, the value of the variable j is stored in the user buffer in step 118 as the index value of the record corresponding to the user who sent the received data. However, if the received data is for a logon request, since the data iFD is not added to the received data, the value of the variable j is not a correct index value. For this reason, in the authentication process, the index value stored in the user buffer is updated to the correct index value.

  In step 208, where the determination in step 202 is YES and the process proceeds, 0 is substituted for variable j. In the next step 209, a record having the value of the variable j in the user DB as an index value is referred to, and it is determined whether or not it is a record in which no data is stored (unregistered area). If no data is stored in the referenced record, the determination is yes, and in step 211, udb [j]. The value of variable fd as iFD, udb [j]. After storing the data cUserID added to the received data as cUserID, the process proceeds to step 206 above. Otherwise, the determination is no, and after the value of variable j is incremented in step 210, the determination process of step 209 is performed again.

  FIG. 9 is a flowchart of processing realized by execution of the transmission thread. The transmission thread is activated at step 102 in the overall process shown in FIG. Next, the transmission thread will be described in detail with reference to FIG. The transmission thread is for realizing transmission / reception of data between the PCs 4 as described above (FIG. 4).

  First, in step 301, 1 is substituted into a variable iSendThread for managing the end of the transmission thread. In the subsequent step 302, it is determined whether or not the value of the variable iSendThread is 1. If the value is not 1, the determination is no and the process moves to step 318. Otherwise, the determination is yes and the process moves to step 303. Although a detailed description is omitted, substitution of a value other than 1 to the variable iSendThread is performed by, for example, an application that realizes the overall process shown in FIG. To do. The application of 1 again is performed by the application in response to the start request of the ensemble.

  As described above, data to be transmitted and received between clients is temporarily stored in the ring buffer (FIG. 5). In step 303, it is determined whether or not there is data to be transmitted in the ring buffer. If such data does not exist in the ring buffer, the determination is yes and the process returns to step 302 above. Otherwise, the determination is yes, and after substituting 0 for the variable i in the next step 304, the process proceeds to step 305.

  In step 305 and the subsequent steps, while sequentially incrementing the value of the variable i, the reception data to be transmitted stored in the ring buffer is transmitted to the user whose data is stored in the record having the value as the index value. Processing is performed.

  First, in step 305, it is determined whether or not the value of the variable i is less than the number of users MAX_USER registered in the user DB. The value assigned to the variable i as an initial value is 0, and the value is sequentially incremented and updated. For this reason, when transmission of reception data to be transmitted to all users who should consider transmission of reception data, the value of the variable i is equal to or greater than the number of users MAX_USER. As a result, the determination is no and the process returns to step 303. Otherwise, the determination is yes and the process moves to step 306.

  In step 306, it is determined whether the received data to be transmitted stored in the ring buffer is for a user mode change request. If the request is for that request, the determination is YES, and in step 307, the received data is transmitted to the user whose data is stored in the record having the value of variable i as the index value, and further in step 308. After incrementing the value of the variable i, the process returns to step 305. On the other hand, if not, the determination is no and the process proceeds to step 309.

  In step 307, if the index value stored in the ring buffer together with the received data matches the value of the variable i, the received data is not transmitted. As a result, transmission of the data to the client that has received the data is avoided.

  In step 309, it is determined whether or not the received data to be transmitted is for instructing recording or reproduction. If it is for such an instruction, the determination is yes and the process proceeds to step 307. Otherwise, the determination is no and the process moves to step 310.

  Thus, in this embodiment, received data other than performance information (MIDI data) is transmitted to other users. This makes it possible to grasp the user mode of other users who are logged on and the requests made by other users. This is because it is necessary to grasp the movements of other users in order to perform an ensemble. By transmitting the received data for recording instructions, a performer performing an ensemble can start the ensemble at the start of recording. Viewer D can know the start of such an ensemble.

  In step 310, the index value stored in the ring buffer together with the received data is substituted into the variable iUDFfr. In the next step 311, the data cUserMode stored in the record having the value of the variable iUDFfr of the user DB as the index value is substituted for the variable a. In the next step 312, the data cUserMode stored in the record having the value of the variable i of the user DB as the index value is substituted for the variable b. Step 313 then proceeds. Based on the above assumption, the shift to step 313 means that the received data to be transmitted is MIDI data. Time data indicating the timing to be processed is added to the MIDI data.

  In step 313, it is determined whether or not the user mode indicated by the value of the variable a is the player A and the user mode indicated by the value of the variable b is the player B. The received data is MIDI data (including performance information) transmitted from the user's PC 4 in which the performer A is the user mode, and the user mode of the user considering the transmission of the received data is the performer B. If YES, the determination is yes and the process proceeds to step 307. Otherwise, the determination is no and the process moves to step 314.

  In step 314, it is determined whether or not the user mode indicated by the value of the variable a is the player B and the user mode indicated by the value of the variable b is the player C. The received data is MIDI data (including performance information) transmitted from the user's PC 4 with the performer B as the user mode, and the user mode of the user considering the transmission of the received data is the performer C. If YES, the determination is yes and the process proceeds to step 307. Otherwise, the determination is no and the process moves to step 315.

  In step 315, it is determined whether or not the user mode indicated by the value of the variable a is the player C and the user mode indicated by the value of the variable b is the viewer D. The received data is MIDI data (including performance information) transmitted from the user's PC 4 with the performer C as the user mode, and the user mode of the user considering the transmission of the received data is the viewer D. If yes, the determination is yes and the process proceeds to step 316. Otherwise, the determination is no and the process moves to step 308.

  In this way, the performance information transmitted from the PC 4 to the server 2 is transmitted only to the user who is specified by the user and should transmit it. Thereby, the flow of performance information as shown in FIG. 4 is realized.

  In step 316, it is determined whether recording is being performed. If the recording is being performed, the determination is yes, and in step 317, the received data is stored in a buffer reserved for recording, and then the process proceeds to step 307. Otherwise, the determination is no, and the process proceeds to step 307 without executing the process of other steps.

  Similarly, in step 318 where the determination in step 302 is NO and the process proceeds, it is determined whether recording is being performed. If the recording is being performed, the determination is YES, and the received data (performance information) stored in the buffer reserved for recording is stored as a file in step 319, and then the series of processing ends. Otherwise, the determination is no and the series of processing ends here.

  FIG. 10 is a flowchart of processing realized by executing the playback thread. The playback thread is activated at step 125 in the overall process shown in FIG. 7 when data for playback instruction is received. Next, the playback thread will be described in detail with reference to FIG. The playback thread is for sending performance information stored as a file as described above to the clients of all logged-on users at any time so that the ensemble results can be played back and viewed. Transmission of performance information is started by instructing the start of reproduction after instructing reproduction.

  The performance information is obtained by adding time data to MIDI data. The PC 4 adds the generation time (indicating value) of MIDI data as the time data. The generation time is the time when the performance operation is performed if the MIDI data is generated by the performance operation on the keyboard 52, and the time when the MIDI data is received if the MIDI data is received. . The time is obtained from a hard timer mounted on the CPU 21. The same applies to PC4 (PC3).

  First, in step 401, 1 is substituted into a variable iPlayThread for managing the end of the playback thread. In the subsequent step 402, it is determined whether or not the value of the variable iPlayThread is 1. If the value is not 1, the determination is no, and the series of processing ends here. Otherwise, the determination is yes and the process moves to step 403. Although a detailed description is omitted, the assignment of a value other than 1 to the variable iPlayThread is performed in step 125 by a reproduction stop request from the client, for example.

  In step 403, it is determined whether the value of the variable iPlayStart is 1. If the value is not 1, the determination is no and the process returns to step 402 above. Otherwise, the determination is yes and the process moves to step 404. Substitution of 1 to the variable iPlayStart is performed in step 125 by a reproduction start request from the client, for example. By repeatedly executing the processing loop formed in steps 402 and 403, it waits for the reproduction start request to be made.

  In step 404, the file to be reproduced is opened. In the subsequent step 405, 0 is substituted into a variable iC for managing performance information to be transmitted, and 1 is substituted into a variable iFirstData. Thereafter, in step 406, a value indicating the current time is substituted into the variable lTimeOffset, and then the process proceeds to step 407.

  A file obtained by recording is stored for a predetermined period, for example. For this reason, when there are a plurality of files to be reproduced, the file to be reproduced can be selected. Here, detailed description thereof is omitted.

  In step 407, it is determined whether the value of the variable iPlayStart is 1. If the value is 1, the performance information specified by the value of the variable iC is read from the file in step 408, and the process proceeds to step 409. Otherwise, the determination is no and the process returns to step 402 above.

  In step 409, it is determined whether there is performance information designated by the value of the variable iC. When the reproduction (transmission) of the performance information is completed, there is no performance information specified by the value of the variable iC, so the determination is YES and the process returns to step 402 above. Thereby, the reproduction of the performance information is started again from the beginning. On the other hand, if not, the determination is no and the process proceeds to step 410.

  In step 410, the time data in the performance information read in step 408 is substituted into a variable lMidiTime. In the subsequent step 411, a value indicating the current time is substituted into the variable lTime. In the next step 412, it is determined whether or not the value of the variable iFirstData is 1. If the value is 1, the determination is YES, the value of the variable lTimeiSet is subtracted from the value of the variable lTimeOffset, and the value obtained by adding the constant CONSTA to the subtraction result (= lTimeOffset-lNidiTime + CONSTA) is set to the variable lDiv in step 413. Further, after substituting 0 into the variable iFirstData in step 414, the process proceeds to step 415. Otherwise, the determination is no and the process moves to step 415 next.

  Time data indicating the time of occurrence is added to the MIDI data. For this reason, the value obtained by subtracting the value of the variable lMidiTime from the value of the variable lTimeOffset indicates the time difference between the current time on the server 2 and the generation time of the first MIDI data. The constant CONSTA added to the value is for absorbing fluctuations in time required for communication via the network 1.

  In step 415, it is determined whether or not the value obtained by subtracting the value of the variable lDiv from the value of the variable lTime is greater than the value of the variable lMidiTime. If the magnitude relationship is established, the determination is YES, and after substituting 0 for the variable j in step 417, the process proceeds to step 418. Otherwise, the determination is no and the process returns to step 407.

  The variable lDiv is assigned a value as described above. For this reason, the above magnitude relationship is established before the timing at which the midi data of the performance information read in step 408 is to be processed. Thereby, in this embodiment, even if the time required for communication fluctuates, the transmission of the MIDI data transmitted to the client is reliably prevented from being delayed.

  In step 418, it is determined whether the value of the variable j is less than the number of users MAX_USER. If the value is less than the number of users MAX_USER, the determination is no and the process moves to step 419. Otherwise, the determination is yes, and after the value of variable iC is incremented in step 416, the process returns to step 407.

  In step 419, it is determined whether or not the value of the data cStat of the record having the value of the variable j of the user DB as the index value is 1, that is, whether or not the user whose data is stored in the record is logged on. If the user is logged on, the determination is yes, the performance information read in step 408 is transmitted to the user in step 420, the value of variable j is further incremented in step 421, and the process returns to step 418. . Otherwise, the determination is no and the process moves to step 421.

Next, the operation of the PC 4 will be described in detail.
The server 2 transmits the user DB (FIG. 5) to the client on which the user has logged on. Further, as shown in FIG. 6, the data to be transmitted by the server 2 as needed is divided into a header and a data body to which the server 2 is added, and stored in a RAM 42 or a buffer which is an area secured in the auxiliary storage device 48. ing. The header stores the data size, the contents of the data body, the sender information of the data body, and the like.

  As described above, in this embodiment, in order to use the service provided by the server 2, a dedicated application is executed by the client. Hereinafter, the operation of the PC 4 realized by executing the application will be described in detail with reference to the flowcharts of FIGS. The application is stored in the auxiliary storage device 48 by setting the recording medium storing the application in the medium driving device constituting the input device 45 and instructing the installation.

  FIG. 11 is a flowchart of the entire process executed by the PC 4. The entire process is realized by executing the application. First, the entire process will be described in detail with reference to FIG. The application is read from the auxiliary storage device 48 to the RAM 42 and executed, for example.

  First, in step 501, initialization such as initialization of various variables and securing of the buffer shown in FIG. 6 is performed. In the next step 502, the user waits for an input performed by operating the input device 45. When the input is performed, the process proceeds to step 503.

  In step 503, it is determined whether or not the input is for a connection request with the server 2. If the user performs an operation for requesting connection to the input device 45, the determination is YES, and after performing connection processing for connecting to the server 2 in step 504, the process returns to step 502. If this is not the case, that is, if the user performs an operation for another purpose such as a playback instruction, a recording instruction, or a user mode change instruction, the determination is NO, and in order to respond to the operation in step 503 After performing other processing, the process returns to step 502.

FIG. 12 is a flowchart of the connection process executed as step 504. Next, the connection process will be described in detail with reference to FIG.
First, in step 601, various variables and the like are initialized. In subsequent step 602, preparation for transmission for connection to the server 2 is performed. Due to the preparation, communication conditions for connection with the server 2 are determined, and the network interface 44 is set according to the determined communication conditions. In step 603 to which the process proceeds after preparation, a connection request to the server 2 is made using the network interface 44. In response to this connection request, the data cUserID assigned to the application is transmitted.

  In step 604 following step 603, it is determined whether or not the connection with the server 2 is established and the logon is approved. If the server 2 notifies that the logon has been approved, the determination is yes and the process moves to step 605. Otherwise, the determination is no and the series of processing ends here.

  In step 605, it waits for reception of the user DB transmitted by the server 2 to the user who has approved the logon, and stores it in the RAM 42 or the auxiliary storage device 48. Thereafter, the reception thread, the transmission thread, and the MIDI out thread are sequentially activated (steps 606 to 608), and 1 is assigned to the variable iOnConnect (step 609). A series of processing ends after the substitution.

  The variable iOnConnect is for specifying the connection state with the server 2, and 1 assigned thereto is a value indicating that the server 2 is connected. Hereinafter, various threads activated by the connection process will be described in detail.

  FIG. 13 is a flowchart of processing realized by execution of the reception thread. In the description of various threads, first, the reception thread will be described in detail with reference to FIG. The reception thread is a program for handling data received from the server 2.

  First, in step 701, 1 is substituted into the variable flag. The variable flag is a variable for managing the end of the receiving thread, and 1 assigned to the variable is a value indicating that the receiving thread is in a state where execution should be continued. After substituting 1 for it, the process proceeds to step 702 to determine whether the value is 1 or not. If the value is 1, the determination is yes, and it waits for data to be received from the server 2 in step 703. On the other hand, if this is not the case, the determination is no, and the series of processing ends here. The assignment of a value other than 1 to the variable flag is performed, for example, when the application terminates execution.

  When data is received from the server 2, the determination in step 703 is YES and the process proceeds to step 704. In step 704, the received data is stored in a temporary data storage buffer recv_buf. In the next step 705, 0 is substituted into the variable j. In step 706 which moves after the substitution, the value of the data iFD of the record having the value of the variable j of the user DB as the index value is the value of the sender information (here, data iFD) in the received data stored in the buffer recv_buf ( It is determined whether or not it matches “recv_buf [SEND_USER_ID]” in the figure. If the values match, the determination is yes and the process moves to step 708. Otherwise, the determination is no, and after the value of variable j is incremented in step 707, the determination process in step 706 is executed again.

  In step 708, the value of variable j is substituted into variable iUDDBid. In the subsequent step 709, it is determined whether or not the received data is MIDI data (performance information). If it is MIDI data, the determination is YES, the MIDI processing for responding to the received MIDI data is executed in step 710, and then the process returns to step 702. Otherwise, the determination is no and the process moves to step 711.

  In step 711, it is determined whether the received data is for a user mode change request. If it is for the change request, the determination is YES, and the user mode process for notifying the display unit 46 of the user mode after the change of the user who sent the change request is executed in step 712. After that, the process returns to step 702. Otherwise, the determination is no and the process moves to step 713.

  In step 713, it is determined whether or not the received data is record data in the user DB. When the data of the record is received, the determination is YES, and after executing the user DB process for storing and updating the data of the record in the saved user DB, the process returns to step 702. Otherwise, the determination is no and the process moves to step 715.

  As described above, when the server 2 updates the user DB, the server 2 transmits the record data whose contents are changed by the update to each client. Therefore, each client updates the user DB managed by itself in a manner linked to the update to the user DB performed by the server 2, and the server 2 realizes the updated user DB. Thus, since the server 2 and the client share the same user DB, the data to be transmitted / received between the clients can be automatically transmitted / received by setting the data stored in the record. Thus, for example, a setting change such as a timbre change by a player, addition / cancellation of a sound effect, or a change of a sound effect to be added is automatically made correspond to each client used by another user Will be able to. As a result, the user of each client can automatically listen to a performance closer to the actual performance of the performer, thereby obtaining high convenience.

  The setting change can be performed on the performance information to be reproduced. That is, it is possible to change the timbre of the original performance, or to add an acoustic effect whose type or content is different from the original. Even if the client user makes such a setting change, if the data indicating the setting contents when each performer has performed is left in the user DB, the setting contents before the change are automatically changed or the user's It can be returned by instruction.

  In step 715, it is determined whether the received data is for instructing recording or reproduction. If data for instructing recording or reproduction has been received, the determination is YES, recording / reproducing processing for notifying the instruction content by the display unit 46 is executed in step 716, and then the processing returns to step 702. Otherwise, the determination is no and the process moves to step 702 next.

  FIG. 14 is a flowchart of the MIDI process executed as step 710. Next, the MIDI processing will be described in detail with reference to the flowchart shown in FIG.

  First, in step 801, it is determined whether or not the value of the variable iFirstMidi is 1. If the value is 1, the determination is yes and the process proceeds to step 802, and if not, the determination is no and the process proceeds to step 806. Substitution of 1 to the variable iFirstMidi is performed in step 601 in the connection process shown in FIG.

  In step 802, 0 is substituted into the variable iFirstMidi. In the subsequent step 803, a value indicating the current time is substituted for the variable lStartTime. In subsequent step 804, the time data added to the received data is substituted into the variable ulM. After the substitution, the process proceeds to step 805. The time data is added after the MIDI data and transmitted.

  In step 805, a value obtained by subtracting the value of the variable ulM from the value of the variable lStartTime (= lStartTime-ulM) is substituted into the variable lTimeOffset. In the next step 806, the location specified by the value of the variable wPtr of the buffer (MIDI out buffer) reserved for the MIDI data to be output to the electronic musical instrument 5, and the location specified by the incremented value (see FIG. Among them, the MIDI data and the time data in the received data stored in the buffer recv_buf are respectively stored in “lMidiOutBuf [wPtr, wPtr + P1]”). In the next step 807, the value of the variable wPtr is updated. Here, the value is updated to a value obtained by adding 2 to the previous value. Thereafter, the series of processing is terminated.

  The variable wPtr is a variable to which an initial value (for example, 0) is substituted in step 601 in the connection process shown in FIG. The value obtained by subtracting the value of the variable ulM from the value of the variable lStartTime to be substituted for the variable lTimeOffset (= lStartTime-ulM) is the time data added to the first received MIDI data when the current time is used as a reference. This represents the shift amount (time difference) to be considered in the occurrence time shown.

  FIG. 15 is a flowchart of processing realized by the execution of the transmission thread activated in step 607 in the connection processing shown in FIG. Next, the transmission thread will be described in detail with reference to FIG.

  MIDI data to be transmitted to the server 2 is stored together with time data in a buffer (transmission buffer) reserved for transmission. “RPtrS” shown in FIG. 15 is a variable for managing a location where data is read from the buffer, and an initial value (for example, 0) is substituted in step 601 in the connection process shown in FIG. The notation “iMidiSendThreadCont” is a variable for managing the end of the transmission thread.

  First, in step 901, 1 is substituted into the variable iMidiSendThreadCont. In the following step 902, it is determined whether or not the value of the variable iMidiSendThreadCont is 1. If the value is not 1, the determination is no, and the series of processing ends here. Otherwise, the determination is yes and the process moves to step 903.

  Substitution of a value other than 1 to the variable iMidiSendThreadCont is performed in step 505 in the overall processing shown in FIG. 11 when the user requests a change to the viewer D as the user mode, for example. In step 505, when a change of the user mode from the viewer D to the performers A to C is requested, initialization is performed and a transmission thread is activated.

  In step 903, it is determined whether there is data to be transmitted in the transmission buffer. If there is no data to be transmitted, the determination is yes and the process returns to step 902. Otherwise, the determination is no and the process moves to step 904.

  In step 904, the data stored in the location specified by the value of the variable rPtrS in the transmission buffer (MIDI data represented as “ulMidiSendBuf [wPtrS]” in the figure) is substituted into the variable wParam. In the next step 905, data stored in a location specified by a value obtained by incrementing the value of the variable rPtrS of the transmission buffer in the variable lParam (time data expressed as “ulMidiSendBuf [wPtrS + 1]” in the figure). Is assigned. In the subsequent step 906, a header for MIDI data transmission is generated and set in the buffer send_buf. Thereafter, the values assigned to the variables wParam and lParamr are set in the buffer send_buf (step 907), the data set in the buffer send_buf is transmitted to the server 2 (step 908), and the variable rPtrS is set to 2 so far. The added value is newly substituted (step 909). Step 910 proceeds after the substitution.

  In step 910, it is determined whether the value of the variable rPtrS is equal to or greater than the maximum number SIZE that can store data in the transmission buffer. If the value is greater than or equal to the maximum number SIZE, the determination is yes, and after substituting 0 for the variable rPtrS in step 911, the process returns to step 903. Otherwise, the determination is no and the process returns to step 903 without executing the process of the other steps.

  FIG. 16 is a flowchart of processing realized by execution of the MIDI out thread started at step 608 in the connection processing shown in FIG. Finally, the out-thread will be described in detail with reference to FIG. The out thread is for realizing processing of MIDI data stored in the MIDI out buffer, storage of processed MIDI data, and storage of MIDI data input from the electronic musical instrument 5 in the transmission buffer.

  Transmission / reception of performance information to be transmitted / received between clients is performed under the control of the server 2. For this reason, the MIDI out thread is a target for transmitting both the received MIDI data and the MIDI data input from the electronic musical instrument 5 to the server 2. Since the generation time indicated by the time data added to the MIDI data is a past time in the PC 4 that transmitted the MIDI data, it is changed to the time when the MIDI data was processed. Thus, the received MIDI data and the time data of the MIDI data input from the electronic musical instrument 5 are based on the PC 4 that transmits them. Therefore, a client that receives the transmitted MIDI data can appropriately process all the MIDI data without distinguishing the MIDI data.

  “RPtr” shown in FIG. 16 is a variable for managing a location to read data from the transmission buffer, and an initial value (for example, 0) is substituted in step 601 in the connection process shown in FIG. The notation “iMidiOutThreadCont” is a variable for managing the end of the MIDI out thread.

  First, in step 1001, 1 is substituted into the variable iMidiOutThreadCont. In the subsequent step 1002, it is determined whether or not the value of the variable iMidiOutThreadCont is 1. If the value is not 1, the determination is no, and the series of processing ends here. Otherwise, the determination is yes and the process moves to step 1003.

  Substitution of a value other than 1 to the variable iMidiOutThreadCont is performed in step 505 in the overall processing shown in FIG. 11 when the user requests a change to the viewer D as the user mode, for example. In step 505, when a change of the user mode from the viewer D to the performers A to C is requested, initialization is performed and a MIDI out thread is started.

  In step 1003, a value indicating the current time is substituted into a variable lNowTime. In the subsequent step 1004, the value of the time data (denoted as “lMidiOutBuf [rPtr + 1]” in the figure) stored in the location designated by the constant lDelay and the value of the MIDI out buffer variable rPtr incremented is set to the variable lTimeOffset, respectively. The value obtained by subtracting the addition result from the value of the variable lNowTime (= lNowTime- (lTimeOffset + lDelay + lMidiOutBuf [rPtr + 1])) is substituted into the variable a. After the substitution, the process proceeds to step 1005.

  The constant lDelay is a constant determined to absorb a change in communication time related to transmission / reception via the network 1 and the server 2. Since the value of the variable lTimeOffset represents the shift amount (time difference) to be considered in the generation time indicated by the time data (iMidiOutBuf [rPtr + 1]), the value to be substituted for the variable a in step 1004 is added by the time data. When the timing for processing the processed MIDI data arrives, the value becomes 0 or more. The constant lDelay may be changed by the user of each client.

  In step 1005, it is determined whether or not the value of the variable a is 0 or more. If the value is less than 0, the determination is no and the process moves to step 1012. Otherwise, the determination is yes and the process moves to step 1006, where the MIDI data stored in the location specified by the value of the variable rPtr in the MIDI out buffer (indicated as “lMidiOutBuf [rPtr]” in the figure). It is determined whether or not it is related to the pronunciation of a musical sound. If the MIDI data is not related to the pronunciation of a musical sound, the determination is no and the process moves to step 1012. Otherwise, the determination is yes and the process moves to step 1007.

  In step 1007, the MIDI data is output to the electronic musical instrument 5 by the MIDI I / F 47. In the next step 1008, a value indicating the user mode of the user is substituted into the variable b. In the subsequent step 1009, the value of the variable b and the value indicating the user mode of the sender of the MIDI data processed in step 1007 (indicated as “USER_MODE_PLAYERMAX” in the figure. Data iFD stored in the header of the MIDI data is used. Are compared with each other by referring to the user DB), and it is determined whether or not the sender is a player who plays upstream from the user. If the sender is a player performing upstream from the user, the determination is yes and the process moves to step 1010. Otherwise, the determination is no and the process returns to step 1004.

  In step 1010, the magnitude relationship between the value of the variable b and the value indicating the user mode of the viewer D (indicated as “USER_MODE_AUDIOENCE” in the figure) is compared to determine whether or not the user is the viewer D. If the user is not the viewer D, the determination is YES, the MIDI data processed in step 1007 and the value of the variable lNowTime as time data are stored in the transmission buffer in step 1011, and the process returns to step 1004. Otherwise, the determination is no and the process returns to step 1004 without executing the process of other steps. By adding the value of the variable lNowTime as time data to the MIDI data, the generation time of the MIDI data is updated to the time processed by the PC 4 that transmits the MIDI data.

  In step 1012 in which the determination in step 1005 or 1006 is NO and the process proceeds to step 1012, it is determined whether MIDI data is input from the electronic musical instrument 5. If the MIDI data is input, the determination is yes and the process proceeds to step 1011, where the MIDI data and the value of the variable lNowTime as time data are stored in the transmission buffer. On the other hand, if not, the determination is no and the process returns to step 1002.

  In this embodiment, MIDI data is used as data indicating the contents of the performance operation. However, other data, for example, waveform data indicating the peak value of a musical sound, or encoded data thereof may be used. . Similarly, the time data may not indicate the time of occurrence. For example, it may indicate the difference in processing timing with the performance information transmitted immediately before. In the case where fluctuations occurring in the communication time required for transmission on the network 2 can be ignored, the time data need not be added.

  The object to be recorded as the ensemble result is MIDI data (performance information) transmitted from the user's PC 4 with the performer C as the user mode. However, the object may be arbitrarily selected. A plurality of users of the PC 4 may perform the selection. Since information indicating the sender is added to the performance information to be transmitted, it is easy to perform recording in accordance with the requests of a plurality of users in parallel.

  A program (application) for realizing the server 2 (net concert system) as described above 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 network such as a public network. In such a case, the user can construct a net concert system to which the present invention is applied by using the apparatus by acquiring the program and loading it into the data processing apparatus. Therefore, the recording medium may be accessible by a device that distributes the program.

It is a figure explaining the structure of the network system constructed | assembled using the network concert system by this Embodiment. It is a figure explaining the structure of the server carrying the network concert system by this Embodiment. It is a figure explaining the structure of the personal computer and electronic musical instrument which the player who performs an ensemble uses. It is a figure explaining the realization method of virtual ensemble. It is a figure explaining the data which the server carrying the network ensemble system by this Embodiment manages for ensemble realization. It is a figure explaining the preservation | save method of the data received with the personal computer. It is a flowchart of the whole process which the server carrying the network concert system by this Embodiment performs. It is a flowchart of an authentication process. It is a flowchart of the process implement | achieved by execution of the transmission thread started by the whole process shown in FIG. It is a flowchart of the process implement | achieved by execution of the reproduction | regeneration thread started by the whole process shown in FIG. It is a flowchart of the whole process which the personal computer of the player who performs an ensemble performs. It is a flowchart of a connection process. It is a flowchart of the process implement | achieved by execution of the reception thread started by the connection process shown in FIG. It is a flowchart of a MIDI process. It is a flowchart of the process implement | achieved by execution of the transmission thread started by the connection process shown in FIG. It is a flowchart of the process implement | achieved by execution of the MIDI out thread started by the connection process shown in FIG.

Explanation of symbols

1 Network 2 Server 3, 4 Personal Computer 5 Electronic Musical Instrument 21, 41 CPU
22, 42 RAM
23, 43 ROM
24, 44 Network interface 25, 45 Input device 27, 48 Auxiliary storage device 28, 49 Bus 47, 51 MIDI I / F
52 Keyboard 53 Sound source / Sound system

Claims (4)

A method for virtually enabling an ensemble by multiple players using a network,
For each performer who desires the ensemble, other performers who should transmit performance information indicating the performance contents performed by the performer for the ensemble are set in advance as transmission subjects,
According to the setting, each terminal device used by a player who has the transmission target person transmits performance information by the player's own performance on the network,
According to the setting, the terminal device used by the other performer is transmitted to each terminal device used by the performer who has both the transmission subject and the other performer who is the transmission subject. Further transmitting performance information received on the network,
Causing each performer who is the transmission target to perform the performance together with the performance of one or more performers according to the performance information received by the terminal device to virtually realize the ensemble,
The ensemble realization method characterized by the above. A system for virtually realizing ensemble for users of terminal devices connected via a network,
Information receiving means for receiving, in real time, performance information indicating performances performed on the musical instrument by the user from the terminal device via the network;
When a plurality of users perform an ensemble, the performance information received by the information receiving means is transmitted according to the relationship in which performance information set in advance between the plurality of users is to be transmitted and received. Information transmitting means for transmitting to the terminal device used by the user specified by the user, if necessary;
A network ensemble system comprising: Information storage means for storing performance information received by the information receiving means from a terminal device in which a user is performing for the ensemble;
The net ensemble system according to claim 2, further comprising: A program to be executed by a data processing apparatus used for construction of a network ensemble system that virtually realizes an ensemble for users of terminal devices connected via a network,
A function for receiving, in real time, performance information indicating the performance performed by the user on the musical instrument from the terminal device via the network;
When a plurality of users perform an ensemble, the performance information received by the receiving function according to the relationship in which performance information set in advance between the plurality of users should be transmitted and received is transmitted from the terminal device that has transmitted the performance information. A function to send to the terminal device used by the user specified by the user, if necessary,
A program to realize

Images