专利名称：电子音乐装置的利记博彩app
技术领域：
本发明，涉及一种具有进行经通信网络与其他电子音乐装置之间互相交换演奏数据的会话的功能的电子音乐装置。
背景技术：
以往，将处理MIDI(Musical Instruments Digital Interface)数据等、表示乐曲的演奏内容的演奏数据的装置，通过多个电缆连接起来，并在它们之间发送接收演奏数据，使其共同工作。
另外，在传输例如MIDI数据的情况下，以往使用专用的接口与电缆来进行。但是，近年来，提出了通过在其他通信协议上置载MIDI消息来进行传输，从而与以往的专用接口的情况相比，能够远距离传输大容量的数据。作为这样的技术，本申请人提出了使用IEEE(Institute of Electricaland Electronic Engineers)1394作为接口的通信标准mLAN(商标)。
另外，还提出了通过使用TCP(Transmission Control Protocol)或UDP(User Datagram Protocol)以及IP(Internet Protocol)作为通信协议，使得能够经互联网发送接收MIDI数据的方案。
关于这样的技术，记载在例如特开2004-301997号公报中。另外，该文献中，记载了在互联网上执行对MIDI数据进行交换的会话的情况下，连接用服务器给参加会话的终端分别分配ID并进行通知，在各个终端发送MIDI数据时，添加与该ID相同的频道编号来进行发送。
但是，上述的利用IEEE1394的通信标准，是一种预先指定特定的参加装置来形成会话组，并进行限定在该参加装置间的MIDI消息的交换的标准，存在无法“临时加入”会话组的问题。
另外，特开2004-301997号公报中所记载的技术中，在使各个终端参加会话时，由用户手动生成组，之后其他终端的用户选择该组来请求参加，存在需要这种复杂的操作的问题。
发明内容
本发明正是要解决上述问题，其目的在于在多个装置间发送接收演奏数据的情况下，提高用于数据的发送接收的会话形成的自由度，同时通过简单的操作让各个装置参加会话。
为了实现上述目的，本发明提供一种电子音乐装置，具有通过通信网络进行与其他电子音乐装置之间相互交换演奏数据的会话的功能，其中，设置有检索机构，其对管理上述会话的主机装置进行检索；在通过该检索没有发现主机装置的情况下，让自己作为主机装置工作，在发现主机装置的情况下，向该发现的主机装置发送包含有自身的识别信息的参加通知的机构；存储机构，其保存正在参加该会话的电子音乐装置的识别信息，来作为上述会话的信息；会话信息通知机构，其在作为主机装置工作的情况下，在从其他电子音乐装置接收到参加通知时，将该其他电子音乐装置的识别信息保存到上述存储机构中，同时在自身所管理的会话中给该其他电子音乐装置分配空置的频道并通知给该其他电子音乐装置，进而，根据保存在上述存储机构中的识别信息，将参加所述自身所管理的会话的各个电子音乐装置的识别信息以及对应的频道的信息，也通知给上述其他电子音乐装置；在没有作为主机装置工作的情况下，从上述发现的主机装置处接收作为对上述参加通知的应答发送来的频道的分配，同时，将该发现的主机装置所通知的识别信息保存到上述存储机构中的机构；以及，与由保存在上述存储机构中的识别信息所确定的其他电子音乐装置之间，互相交换上述演奏数据的机构。
这样的电子音乐装置中，可设有在作为主机装置工作的情况下，对应于从其他电子音乐装置接收到脱离通知这一情况，将该其他电子音乐装置的识别信息从上述存储机构中删除，根据保存在上述存储机构中的识别信息，将该存储机构中所保存的识别信息的变更内容，通知给参加上述自身所管理的会话的各个电子音乐装置的机构。
或者，可设有在不作为主机装置工作的情况下，对应于从作为对参加中的会话进行管理的主机装置的电子音乐装置接收到脱离通知这一情况，将该电子音乐装置的识别信息从上述存储机构中删除，同时，让自身作为对上述参加中的会话进行管理的主机装置工作，进而，根据保存在上述存储机构中的识别信息，将表示自身是主机装置的信息以及上述存储机构中所保存的识别信息的变更内容，通知给参加自身所管理的会话的各个电子音乐装置的机构。
图1为说明演奏数据通信管理系统的第1实施方式的构成的方框图。
图2为说明图1中所示的终端装置的硬件构成的图。
图3为说明图1中所示的管理服务器为了会话的管理而事先保存的信息的图。
图4为说明图1中所示的管理服务器所执行的与接收数据相关的处理的一部分的流程图。
图5为图4的后续的处理的流程图。
图6为说明参加通知的数据构成的图。
图7为说明状态通知的数据构成的图。
图8为说明设定变更通知的数据构成的图。
图9为说明脱离通知的数据构成的图。
图10为说明图1中所示的终端装置所执行的与接收数据相关的处理的流程图。
图11为同样与数据发送相关的处理的流程图。
图12为说明在管理服务器中所有终端装置均未登录的状态下，首个终端装置A进行参加通知的情况下的处理顺序例的图。
图13为说明图12中所示的处理结束时的组管理表以及终端装置管理表的状态的图。
图14为说明在图12的处理后，下个终端装置B进行希望与终端装置A会话的参加通知的情况下的处理顺序例的图。
图15为说明图14中所示的处理结束时的组管理表以及终端装置管理表的状态的图。
图16为说明在图14的处理后，下个终端装置C进行希望与终端装置A会话的参加通知的情况下的处理顺序例的图。
图17为说明在图16的处理后，在终端装置A中实施音源部的设定变更操作的情况下的处理顺序例的图。
图18为说明在图17的处理后，在终端装置A中实施会话的结束操作的情况下的处理顺序例的图。
图19为说明演奏数据通信管理系统的第2实施方式的概要构成的方框图。
图20为图19中所示的终端装置在会话参加时所执行的处理的流程图。
图21为说明节点信息表的例子的图。
图22为说明图19中所示的系统中，成为主机的终端装置所执行的与接收数据相关的处理的流程图。
图23为说明同样主机之外的终端装置所执行的与接收数据相关的处理的流程图。
图24为说明同样终端装置所执行的与数据发送相关的处理的流程图。
图25为说明第二个终端装置B向成为主机的终端装置A进行参加通知的情况下的处理顺序例的图。
图26为说明图25的处理后，下个终端装置C向终端装置A进行参加通知的情况下的处理顺序例的图。
图27为说明图26的处理后，在终端装置A中实施会话的结束操作的情况下的处理顺序例的图。
具体实施例方式
以下对照附图对本发明的实施方式进行说明。
首先，对演奏数据通信管理系统的第1实施方式进行说明。图1为说明该演奏数据通信管理系统的概要构成的方框图。
该图中所示的演奏数据通信管理系统1，在多个终端装置10之间发送接收作为演奏数据的MIDI数据的情况下，设置管理服务器100，通过该管理服务器，对MIDI数据的发送接收的相关会话(session)进行管理。另外，各个终端装置10相当于电子音乐装置，管理服务器100相当于演奏数据通信管理装置。
这里，会话是指，多个终端装置10与特定的组内的通信对象之间发送接收MIDI数据(互相交换)。然后，各个终端装置10，能够通过向管理服务器100进行请求，成为该组的成员来参加会话，从而成为可与同一组内的终端装置之间发送接收MIDI数据的状态。另外，管理服务器100，对进行会话的组的成员的信息进行管理，同时，对应于来自终端装置10的请求，将请求源的终端装置10登录到组中，在组的成员发生了变化的情况下，向组的各个成员通知必要的信息，通过这样，让各个成员能够正常进行会话。
另外，管理服务器100能够同时管理多个会话，这种情况下，对多个组管理成员的信息。另外，如果从终端装置10一侧看，则即使是与同一个管理服务器100进行通信的终端装置，也不和不同组的终端装置进行MIDI数据的发送接收，只与同一个组的终端装置之间进行MIDI数据的发送接收。
另外，演奏数据通信管理系统1中，MIDI数据的发送接收基本上不经管理服务器100，而是在各个终端装置10之间通过点对点(P2P)进行。
这里，点对点是指，各个终端间(个人间)直接进行数据的交换的通信网络(一般来说是互联网)的利用形态。本发明中，对于用来进行点对点通信的通信协议并没有特别的限制，但在进行MIDI数据的传输的情况下，最好是规定了用来保持数据的等时性的时间戳或同步时钟等的通信协议。另外，还可以对应于终端装置之间所交换的数据的种类，使用不同的通信协议。
接下来，图2中示出了图1中所示的终端装置10的硬件构成。
如图所示，终端装置10具有CPU11、ROM12、RAM13、非易失性存储器14、网络接口(I/F)15、演奏输入设备16、以及音源部17，它们均连接在系统总线18上。另外，声音系统19与音源部17相连接设置。
而且，CPU11是对终端装置10进行总括控制的控制部，通过执行存储在ROM12中的所需要的控制程序来实施控制动作，对向非易失性存储器14读写数据、经网络I/F15进行通信、用演奏输入设备16完成的演奏输入操作的检测、基于音源部17的MIDI数据的波形数据的生成等进行控制。
ROM12，是保存CPU11所执行的控制程序、以及无需变更的数据等的存储机构。该ROM12可通过闪存等可重写的非易失性存储机构构成，使得能够对这些数据进行更新。
RAM13，用作CPU11的工作存储器，或设置对音源部17中的MIDI数据的处理(波形数据的合成)中所使用参数的值进行存储的存储区域，或存储其他暂时使用的数据的存储机构。
另外，非易失性存储器14，是非易失RAM或HDD(硬盘驱动器)等的非易失性存储机构，存储有CPU11所执行的控制程序或自动演奏用MIDI乐曲数据等，容量比较大且即使切断电源也需要保持的数据。
网络I/F15，是用来经LAN(局域网)或互联网等网络与管理服务器100或其他终端装置10进行通信的接口，例如可以采用用于进行以太网(商标)方式的通信的接口。但是，终端装置10所使用的通信路径并不仅限于此，网络I/F15还可以对应于通信路径的规格以及所使用的通信协议等适当准备。另外，当然也可以对应多个规格设置多个通信I/F15。
演奏输入设备16，是键盘或弦、衬垫(pad)、吹口等，用来受理演奏操作的设备，用户对该演奏输入设备16所进行的操作，通过具有各种传感器的检测电路变换成电信号，传输给CPU11。然后，CPU11根据该信号，生成用来向音源部17指示对应于用户的演奏操作的发音的MIDI事件，并发送给音源部17。另外，在处于与其他终端装置通信中的情况下，也向该终端装置发送相同的MIDI事件。
音源部17，是GM(通用MIDI)对应的音源，根据从CPU11发送来的MIDI事件，用多个发音频道生成数字声音信号即波形数据的音源机构。该MIDI事件中，除了指示发音的开始或停止的数据之外，还包括指示音色等发音内容所涉及的设定的变更的数据。另外，MIDI事件中，还包括CPU11所生成的数据以及从其他终端装置10处接收的数据。然后，如后所述，让CPU11所生成的MIDI事件以及从其他终端装置10处接收到的MIDI事件能够通过频道进行区别，并且对每一个频道适当进行与发音内容相关的设定，通过这样，在音源部17中，作为全体，生成基于多个终端装置10的合奏的那种波形数据。
声音系统19，是扬声器等发音机构，具有依照音源部17所供给的波形数据进行发音的功能。
具有以上构成的终端装置10，具体来说，以键盘、电子风琴、电子钢琴为首，并且还包括打击乐器、弦乐器、管乐器等的电子乐器。或者，也可以是具有MIDI音序器或用来实现该功能的应用程序的PC(个人计算机)等，不具备演奏操作设备的装置。另外，即使是移动电话或PDA(Personal Digital Assistance)这样的便携式终端，如果具有处理MIDI数据的功能，也能够用作终端装置10。
而且，终端装置10只要具有发送MIDI数据的功能或接收MIDI数据的功能中的任意一方即可，并不需要具有发送接收这双方的功能。另外，关于音源部17以及声音系统19也不是必需的。
另外，管理服务器100的硬件，可以采用具有CPU、ROM、RAM、HDD、网络I/F等的公知的计算机。另外，由于上述各部的功能与上述终端装置10中的对应构成要素的情况一样，因此省略其详细说明。另外，虽然管理服务器100，最好具有处理能力较高的CPU或大容量的HDD，但并不仅限于此。另外，还可让任意一个终端装置10兼具管理服务器100的功能。
接下来，图3中示出了管理服务器100为了会话的管理所事先保存的信息的例子。
如这些图所示，管理服务器100，在HDD或RAM之类的存储机构中，保存有组管理表以及终端装置管理表，作为用于会话管理的信息。
另外，前者是用来对在管理服务器100的管理下进行会话的组的信息进行管理的表，与各个组的ID一起登录有其成员，也即参加会话的终端装置的信息，通过该终端装置的ID进行登录。这里，组ID是只在管理服务器100内部使用的信息。另外，虽然同时成为1个组的成员的终端装置10的数目没有特别的限制，但由于通用MIDI中所能够使用的频道数是16，因此可以相应限制为16台。
另外，后者是用来对在管理服务器100的管理下进行会话的终端装置10的信息进行管理的表，对各个终端装置10，对应于其ID，登录有在请求参加会话时所指定的通信对象的ID、该终端装置所使用的音源设定的信息、分配给该终端装置的频道的编号、以及该终端装置所属的组的ID。
另外，在管理服务器100的管理下完全没有进行会话的情况下，在哪一个表中都不登录信息。
另外，在图3所示的各个表中，装置的ID可以使用机器编号或登录编号等用来识别装置自身的信息，但也可以使用IP地址等在与相应的装置进行通信时所使用的地址信息。关于这一点将在后面进行详细说明。
另外，音源设定的信息，例如考虑将由MIDI程序变更事件(programchange event)设定的音色的信息，通过程序编号进行登录，但并不仅限于此。也可以登录多个项目的信息。
接下来，图4与图5中对上述管理服务器100的CPU所执行的接收数据的相关处理的流程图，以用来进行会话管理的处理的部分为中心进行说明。另外，以下说明的处理，只要没有特别的否定，均通过任意装置的CPU执行所需要的控制程序来实施。
管理服务器100的CPU，将从终端装置10等外部装置所接收到的数据，暂时保存在接收缓存中，以定期的时刻进行图4与图5的流程图中所示的处理，通过这样来进行对应于这些数据的处理。
而且，该处理中首先确认接收缓存(S11)。之后，如果有参加通知(S12)，则进行步骤S13至S20的与参加通知相关的处理。
这里，图6中示出了参加通知的数据结构之一例。
参加通知，是在终端装置10请求参加会话的情况下向管理服务器100发送的通知，如图6所示，包括表示是参加通知的信息、该通知的发送源的装置(通知源装置)的ID(自机ID)、希望通信的通信对象的ID、以及通信源装置中的音源设定信息。
另外，在将从终端装置10向管理服务器100的信息传输通过包传输来进行的情况下，表示是参加通知的信息既可以记录在包内，也可以利用包的ID。另外，自机ID，可以利用附加在包中的包发送源装置的ID的信息。如果ID使用IP地址，则能够利用包发送源装置的IP地址。
另外，音源设定信息，是在音源部17中进行通知源装置在会话中所发送的MIDI事件所涉及的发音时所必需的范围的设定内容(这里为1频道份的设定内容)的信息，不需要包括对通知源装置的音源设定的所有设定内容。
回到图4的说明，在上述参加通知所涉及的处理中，首先，如果通知源装置完成了在终端装置管理表中的登录，则直接忽略处理回到步骤S12(S13)。这是由于，因为这种情况下考虑到通知源装置已经参加了某个会话，所以防止同一个装置重复参加会话。另外，该判断也可以通过是否在组管理表中登录完成来进行。
另外，如果不是登录完毕，接下来便判断“通信对象ID”所表示的装置是否在终端装置管理表(或组管理表)中登录完成(S14)，如果没有登录，则由于无法在现状下与该装置进行会话，因此新生成1个组并将通知源装置登录到该组中(S15)，等待通信对象请求参加该会话。反过来说，在希望新生成组的情况下，可以在参加通知中记录虚拟的通信对象ID。另外，新组的ID可以是连号或随机数等，通过适当的方法来生成。另外，如果登录完成，则将通知源装置登录到通信对象所属的组中(S16)。这些登录，可以通过往组信息表中登录ID来进行。
另外，在任意一个情况下，均将所登录的组中空置的频道(CH)分配给通知源装置(S17)，同时将通知源装置的信息登录到终端装置管理表(S18)中。被登录的频道或组的信息，由步骤S15至S17确定。另外，频道的分配可以使用任意方法，例如，参照终端装置管理表，列出分配给同一组的终端装置的频道，从此外的频道中随机选择来实施频道的分配。不管怎么样，只要不给同一个组内的多个终端装置分配相同的频道，即能够进行唯一的分配即可。
之后，向通知源装置发送状态通知，通知同一个组的所有终端装置的信息(S19)，同时，向与通知源装置同一个组的(通知源装置以外的)所有终端装置发送状态通知，对通知源装置的信息进行通知(S20)。
之后，回到步骤S12重复进行处理，如果接收缓存中还有其他数据，则进行与该数据相关的处理。
另外，以上的步骤S13至S20的处理中，管理服务器100的CPU作为会话信息通知机构发挥作用。
这里，图7中示出了状态通知的数据结构。
如该图所示，状态通知是管理服务器100用来向终端装置10传送参加会话的终端装置10的信息而发送的通知，包括表示是状态通知的信息、表示该状态通知是通知哪一个装置的状态的信息(装置ID)、分配给该装置的频道的编号、以及该装置中的音源设定信息。
而且，该状态通知，能够根据登录在终端装置管理表中的信息来生成。另外，在发送对涉及多个装置的信息进行通知的状态通知的情况下(主要是步骤S19)，既可以对各个装置逐个发送状态通知，也可以在1个状态通知中包括多个装置的信息。终端装置10侧，根据该状态通知中所包括的信息进行音源的设定。
另外，可以通过包的ID来表示是状态通知，作为音源的设定的内容可以不包括全部设定内容，这几点均与上述参加通知的情况相同。
再次回到图4的说明，步骤S12中在没有参加通知的情况下，进入步骤S21，这里如果有设定变更通知，则进行步骤S22以及S23的与设定变更通知相关的处理。
设定变更通知，是在终端装置10变更了自身的音源设定(之中通过参加通知通知给管理服务器100的部分)的情况下，将该内容通知给管理服务器100的通知。之后，管理服务器100，接收到该通知之后，根据通知内容更新终端装置管理表的信息(S22)，同时向与通知源机器同一个组的全体终端装置发送设定变更通知，并通知音源设定的变更内容(S23)。
之后，回到步骤S12重复进行处理，如果接收缓存中还有其他数据，则进行与该数据相关的处理。
这里，图8中示出了设定变更通知的数据结构。
如该图所示，设定变更通知，是表示设定的变更内容的MIDI事件，这里为MIDI程序变更事件。而且，在从终端装置10向管理服务器100发送时，可以添加通知发送源的装置ID(自机ID)。自机ID，可以利用添加在包中的包发送源装置的ID的信息，这一点与上述参加通知的情况相同。
另外，MIDI程序变更事件中，包括表示该MIDI数据是MIDI程序变更事件的状态字节、表示变更设定的频道的频道编号、以及表示应当在该频道中新使用的设定的内容的程序编号的信息。
MIDI程序变更事件，是MIDI事件的一种，由于不在参加同一个会话的终端装置间经管理服务器100发送接收，因此即使管理服务器100不参与，各个终端装置也能够按照从其他终端装置处接收到的MIDI程序变更事件，在音源部中对适当的内容进行设定。
但是，如此处所示，通过将MIDI程序变更事件的内容也发送给管理服务器100，另外从管理服务器100向与通知发送源的装置同一个组的终端装置通知该内容，增加了数据的冗长性，即使在终端装置间的传输或管理服务器100向终端装置的传输的任意一个出现问题的情况下，也能够利用通过另一个路径所传输的数据，来在音源部中对适当的内容进行设定。另外，通过由管理服务器100侧掌握终端装置中的音源的设定内容，并根据步骤S19所发送的状态通知，能够向新参加会话的终端装置，通知组内的其他装置中的音源部17的设定状态，并进行适当的设定。
另外，只要是涉及音源的设定的信息即可，除了MIDI程序变更事件，其他事件例如MIDI控制变更事件，当然也可以作为上述的设定变更通知来进行发送接收。
再次回到图4的说明，在步骤S21中没有设定变更通知的情况下，进入图5的步骤S31，这里如果有脱离通知，则进行步骤S32至S35的与脱离通知相关的处理。
脱离通知，是终端装置10将从会话中脱离的意思传递给管理服务器100的通知。之后，管理服务器100接收到该通知后，从终端装置管理表以及组管理表中删除通知源装置的信息(S32、S33)。通过这样，还解除了通知源装置所对应的频道分配，成为能够将该频道分配给其他装置的状态。而且，在该删除的结果导致组中没有成员的情况下，从组管理表中将该组自身也删除(S34、S35)。
之后，回到图4的步骤S12重复进行处理，如果接收缓存中还有其他数据，则进行与该数据相关的处理。
这里，图9中示出了脱离通知的数据结构。
如该图所示，脱离通知包括表示是脱离通知的信息、以及该通知源装置的ID，而不需要特别具有除此之外的信息。另外，作为这些信息，可以利用包的ID或包发送源装置的ID，这一点与上述参加通知的情况一样。
另外，作出过脱离通知的终端装置10，若之后停止了与其他终端装置之间的MIDI数据的发送接收，则能够从会话中脱离。另外，对于MIDI数据的发送接收而言，若因从某个时刻起脱离的终端装置没有返回应答而引起通信错误，则能够识别出该终端装置脱离了会话。另外，由于分配给脱离的终端装置的频道的MIDI数据也不会再发送过来，因此该频道的设定内容即使不特意变更也不会发生问题。
因此，不需要从管理服务器装置100侧，向与脱离通知的发送源装置同一个组的装置进行与脱离相关的通知。另外，之所以从终端装置10向管理服务器100进行脱离通知，是因为要保持组管理表以及终端装置管理表的内容与实际的会话的内容相一致。
回到图5的说明，在步骤S31中没有脱离通知的情况下，进入步骤S36，这里如果有其他数据，则根据其内容进行处理(S37)，并回到图4的步骤S12。但是，如果没有其他数据，则由于已经结束了与接收缓存内的所有数据相关的处理，因此结束流程图中的处理。
管理服务器100，能够通过进行以上的处理，通过组管理表以及终端装置管理表，掌握各个终端装置所进行的会话的状况、以及各个终端装置中的音源的设定内容，另外能够在必要的情况下向终端装置通知这些信息。
接下来，图10中对终端装置10所执行的与接收数据相关的处理的流程图，以为了会话的执行而进行的处理的部分为中心进行了说明。
终端装置10，也将从管理服务器100或其他终端装置等外部装置处接收到的数据，暂时保存在接收缓存中，以定期的时刻进行图10的流程图中所示的处理，通过这样来根据这些数据实施处理。
另外，该处理中，首先确认接收缓存(S41)。之后，如果有包括自身ID作为装置ID的状态通知(S42)，则得知该通知是管理服务器100通知分配给终端装置10的频道的通知。因此，给演奏输入设备16，分配由该状态通知所通知的频道(S43)。也即，将CPU11根据演奏输入设备16的操作而生成的MIDI事件所附的频道编号，设定为由管理服务器100分配的频道的编号。再然后，在音源部17中，在该所通知的频道中进行自机所使用的设定(S44)。该设定，是在参加通知的发送时通知给管理服务器100的内容。然后，例如若进行音色的设定，则能够根据演奏输入设备16的操作，在音源部17中通过所期望的音色进行发音。
步骤S44之后，回到步骤S42重复进行处理，如果接收缓存中还有其他数据，则进行与该数据相关的处理。
另外，如果步骤S42中不存在包含自身ID的状态通知，则进入步骤S45。而且，这里如果存在包含其他机器的ID作为装置ID的状态通知，则得知该通知是管理服务器100通知分配给参加(或新参加)同一个会话的其他装置的频道以及该频道中的音源设定内容的通知。因此，如果其他机器还没有在发送目的地列表中登录，则进行登录(S46、S47)。另外，无论哪种情况，都按照通知内容，在音源部17中在所通知的频道中进行所通知的内容的设定(S48)，之后，回到步骤S42，重复进行处理。
另外，上述发送目的地列表，是登录参加同一个会话且成为发送MIDI数据的对象的终端装置的列表，登录有数据的发送时所使用的IP地址等地址信息。而且，在使用机器的ID作为地址信息的情况下，可以直接登录该地址信息，否则通过某种方法来取得地址信息。例如，在管理服务器100中事先保存ID与地址信息的对应关系，各个终端装置10，在进行往发送目的地列表中的登录时，向管理服务器100进行讯问等。但是，这样一来处理就变得复杂，多少需要额外的时间，因此在这一点上，可以说使用IP地址等地址信息作为各个终端装置的ID比较理想。另外，登录在发送目的地列表中的信息，也可不必是表示地址本身的信息，不管是什么样的信息，只要是能够以其为关键取得数据的发送中所需要的地址的信息，就称作地址信息。
另外，由于应从管理服务器100，向参加同一个会话的各个终端装置发送相同的状态通知，因此各个终端装置通过按照该状态通知进行音源部17的设定，能够统一音源部17的设定内容。因此，参加会话的所有终端装置，能够处于可对来自同一个终端装置的MIDI事件发相同的音的状态。如果不能够取得这样的统一，例如对各个频道而言每一个装置所设定的音色不同，则对同一个MIDI事件来说每个发送目的地发出不同的音，在利用会话进行合奏之类的用途中极为不妥。但是此系统中，能够避免这样的问题。
另外，如果步骤S45中不存在包含其他机器的ID的状态通知，则进入步骤S49。之后，如果有设定变更通知，则按照其内容在音源部17中进行设定(S50)。虽然如在管理服务器100侧的说明中所述，由于该通知与从参加同一个会话的终端装置处作为MIDI事件接收到的通知相同，因此这里不需要重新进行设定变更，但为了能够可靠地进行设定变更，而特意将处理设为双重。
另外，如果步骤S49中没有设定变更通知，则进入步骤S51。之后，如果有MIDI数据，则将该数据拆包后提供给音源部17(S52)。该MIDI数据中，若还有指示发音的开始或停止的指示，则还有指示音源部17的设定变更的指示。
另外，如果步骤S51中没有MIDI数据，则进入步骤S53。之后，如果关于往特定的发送目的地的MIDI数据的发送存在给定次数的发送错误，则将出错的发送目的地从发送目的地列表中删除(S54)。这是由于，在存在脱离了会话的终端装置的情况下，由于认为对该终端装置的MIDI数据的发送出错，因此这种情况下停止与该装置之间的通信。之所以采用给定的次数，是为了不将偶然产生的出错识别为从会话的脱离。
回到图10的说明，在步骤S53中没有发送错误的情况下，进入步骤S55，这里如果有其他数据，则根据其内容进行处理(S55，S56)。但是，如果没有其他数据，由于与接收缓存内的所有数据相关的处理已经结束，因此结束流程图中的处理。
另外，步骤S50、S52、S54、S56之后，分别回到步骤S42重复进行处理。
接下来，图11中对与终端装置10所执行的数据发送相关的处理的流程图，以为了会话的执行所进行的处理的部分为中心进行说明。
终端装置10，将根据演奏输入设备16的操作所生成的MIDI数据，或发送给管理服务器100的通知等，暂时保存在发送缓存中，以定期的时刻进行图11的流程图中所示的处理，通过这样进行这些数据的发送。
另外，发送给管理服务器100的通知中，有参加通知、设定变更通知、脱离通知等。其中，通过未图示的操作设备等的操作，确定通信对象的ID，并在指示出会话开始的时刻，取得基于终端装置10自身所生成的MIDI数据的发音中所使用的预定的设定内容(音色编号等)，根据这些信息来生成参加通知。
另外，设定变更通知，对音源部17中的分配给自身的频道的设定内容进行监视，并在该内容被变更了的情况下生成表示该意思的通知，或对写入在发送缓存中的MIDI数据的内容进行监视，在存在程序变更等涉及音源部17的设定内容的变更的情况下，复制该MIDI数据作为指向管理服务器100的包数据。在CPU11生成了与设定内容的变更相关的MIDI数据的情况下，可以同时进行指向管理服务器100的包数据的生成。
另外，脱离通知，通过未图示的操作设备等的操作，在指示了会话的结束的情况下生成。
之后，在图11所示的处理中，首先确认发送缓存(S61)。之后，如果有MIDI数据，则将该MIDI数据通过点对点方式，直接发送给登录在发送目的地列表中的装置、即参加同一个会话的所有终端装置(S62、S63)。另外，在没有MIDI数据的情况下，如果有发送给管理服务器100的通知，则将该通知发送给管理服务器100(S64、S65)。而且，不管在哪个情况下，都回到步骤S62，重复进行处理，并且如果发送缓存中还有其他数据，则进行与该数据相关的处理。另外，如果步骤S64中没有通知，则由于与发送缓存内的所有数据相关的处理已经结束，因此结束流程图中的处理。
终端装置10，通过进行以上的图10以及图11所示的处理，能够向管理服务器100请求参加会话，或根据从管理服务器100所取得的数据，设定自身所使用的频道、成为通信对象的装置的地址信息、以及该通信对象所使用的频道的信息，并根据这些设定进行MIDI数据的发送接收。
接下来，对照图12至图18，对管理服务器100与终端装置10通过上述处理所进行的工作顺序之一例进行说明。另外，这些图中为了分别区别多个终端装置，分别给不同的终端装置标注A、B、C的符号来进行说明。
首先，图12中示出了在管理服务器100中完全没有登录终端装置的状态下，首个终端装置(终端装置A)作出参加通知的情况下的处理顺序例。
这种情况下，终端装置A(设ID为“ID#1”)，将包含ID#1作为自机ID、包含ID#2(终端装置B的ID)作为通信对象ID、包含Prog#1作为音源设定信息的参加通知，发送给管理服务器100(S101)。
之后，接收到该通知的管理服务器100，通过图4的步骤S13以后的处理，由于指定为通信对象的ID#2的装置尚未登录，因此新生成组(设ID为“GRP#1”)(S102)，将终端装置A作为所生成的组的成员登录到组管理表中(S103)，并给终端装置A分配频道(S104)，同时，在终端装置管理表中登录终端装置A的信息(S105)，向终端装置A发送状态通知来通知所分配的频道(S106)。另外，由于登录有终端装置A的组中尚未登录其他终端装置，因此不作出对其他装置的状态通知。
之后，终端装置A根据步骤S106的通知，通过图10的步骤S43以后的处理，将CH#1分配给演奏输入设备16，在音源部17中在CH#1的频道中进行Prog#1的内容的设定(S107)。
图13中示出了该处理结束时的组管理表以及终端装置管理表的状态。
如该图所示，组管理表中新生成了组GRP#1，同时，添加了作为终端装置A的ID的ID#1，终端装置管理表中也登录了终端装置A的信息。频道编号，是管理服务器100动态分配的。另外，通信对象的信息，在登录到表中之后没有特别的意义。
接下来，图14中示出了在图12的处理后，下个终端装置(终端装置B)作出希望与终端装置A会话的参加通知的情况下的处理顺序例。
这种情况下，终端装置B(设ID为“ID#2”)，将包含ID#2作为自机ID、包含ID#1作为通信对象ID、包含Prog#2作为音源设定信息的参加通知，发送给管理服务器100(S111)。
之后，接收到该通知的管理服务器100，还是进行图4的步骤S13以后的处理，由于指定为通信对象的ID#1的装置已经登录在组GRP#1中，因此将终端装置B作为该组的成员登录到组管理表中(S112)，将不与终端装置A重合的频道分配给终端装置B(S113)，同时，在终端装置管理表中登录终端装置B的信息(S114)，向终端装置B发送状态通知，通知所分配的频道和同一个组的终端装置A的信息(S115)。
之后，终端装置B根据该通知，通过图10的步骤S43以后的处理以及S46以后的处理，将CH#2分配给演奏输入设备16，在音源部17中在CH#1、CH#2的频道中分别进行Prog#1与Prog#2的内容设定，并将终端装置A的地址信息登录到发送目的地列表中(S116)。
另外，管理服务器100，还向终端装置A发送状态通知，通知新登录到同一个组中的终端装置B的信息(S117)。之后，终端装置A通过图10的步骤S46以后的处理，根据该通知，在音源部17中在CH#2的频道中进行Prog#2的内容设定，并将终端装置B的地址信息登录到发送目的地列表中(S118)。
这样，通过以上，成为终端装置A与终端装置B能够互相点对点发送接收MIDI数据的状态，并开始通信(S119)。
图15中示出了该处理结束时的组管理表以及终端装置管理表的状态。
如该图所示，组管理表中添加了作为终端装置B的ID的ID#2，作为组GRP#1的成员，终端装置管理表中也登录了终端装置B的信息。另外，终端装置B作为通信对象指定的ID#1的装置是组GRP#1的成员这一情况，可以通过参照终端装置管理表得知，也可直接参照组管理表得知。
接下来，图16中示出了在图14的处理后，下个终端装置(终端装置C)作出希望与终端装置A会话的参加通知的情况下的处理顺序例。
这种情况下，终端装置C(设ID为“ID#3”)，将包含ID#3作为自机ID、包含ID#1作为通信对象ID、包含Prog#3作为音源设定信息的参加通知，发送给管理服务器100(S121)。另外，在令通信对象ID为ID#2的情况下，以下的动作也一样。
然后，接收到该通知的管理服务器100，还是进行图4的步骤S13以后的处理，由于指定为通信对象的ID#1的装置已经登录在组GRP#1中，因此将终端装置C作为该组的成员登录到组管理表中(S122)，将不与终端装置A以及终端装置B重合的频道分配给终端装置C(S123)，同时，在终端装置管理表中登录终端装置C的信息(S124)，并向终端装置C发送状态通知，通知所分配的频道和同一个组的终端装置A与终端装置B的信息(S125)。
之后，终端装置C根据该通知，根据图10的步骤S43以后的处理以及S46以后的处理，将CH#3分配给演奏输入设备16，在音源部17中在CH#1、CH#2、CH#3的频道中分别进行Prog#1、Prog#2、Prog#3的内容设定，将终端装置A与终端装置B的地址信息登录到发送目的地列表中(S126)。
另外，管理服务器100，还向终端装置A以及终端装置B发送状态通知，通知新登录到同一个组中的终端装置C的信息(S127、S128)。之后，终端装置A以及终端装置B，分别根据该通知，通过进行图10的步骤S46以后的处理，在音源部17中在CH#3的频道中进行Prog#3的内容设定，并将终端装置C的地址信息登录到发送目的地列表中(S129、S130)。
这样，通过以上，成为终端装置C能够与终端装置A以及终端装置B互相点对点发送接收MIDI数据的状态，并开始通信(S131)。另外，终端装置A与终端装置B，像之前一样继续通信(S132)。从而，通过上述处理，成为终端装置A、B、C能够互相点对点通信的状态。
另外，如果从终端装置C看，只通过指定1台通信对象，就能够处于还能同时与正在同该通信对象通信的对象进行通信的状态。
接下来，图17中示出了在图16的处理后，在终端装置A中实施音源部17的设定变更操作的情况下的处理顺序例。
这种情况下，终端装置A检测到设定变更操作之后，生成对应的MIDI事件(这里，是将频道CH#1的设定变更为Prog#4的MIDI程序变更事件)后提供给音源部17，并变更音源部17的设定(S141)。另外，向登录在发送目的地列表中的发送目的地，发送同一个MIDI事件(S142)。之后，接收到该事件的其他终端装置，也通过图10的步骤S52的处理，按照MIDI事件来变更音源的设定(S143)。
另外，终端装置A，还向管理服务器100发送表示将频道CH#1的设定变更为Prog#4的设定变更通知(S144)。然后，管理服务器100通过图4的步骤S22以后的处理，按照通知的内容变更终端装置管理表的终端装置A的信息(S145)，同时向与终端装置A同一个组的各个终端装置，发送设定变更通知，来通知设定的变更(S146)。之后，接收到该通知的各个终端装置，分别通过图10的步骤S50的处理，按照通知内容变更音源部17的设定(S147)。如上所述，步骤S147的处理，虽然通常与步骤S141或S143的处理重复，但为了防止出错仍需要实施。
通过以上处理，能够将1台终端装置中的音源部17的设定变更，反映到其他终端装置中。
接下来，图18中示出了在图17的处理后，在终端装置A中实施会话的结束操作的情况下的处理顺序例。
这种情况下，终端装置A检测到结束操作之后，向管理服务器100发送脱离通知(S151)，同时中止与其他终端装置之间的通信(S152)。之后，在管理服务器100侧，根据脱离通知，通过图5的步骤S32以后的处理，将通知源的终端装置A的信息从组管理表以及终端装置管理表中删除(S153)。
另外，此前与终端装置A进行会话的终端装置B以及终端装置C，由于与终端装置A之间的通信失败(S154)，因此通过图10的步骤S54的处理，从发送目的地列表中删除终端装置A(S155、S156)。但继续终端装置B与终端装置C之间的通信(S157)。
通过以上处理，终端装置A能够从会话中脱离。
通过以上所说明的演奏数据通信管理系统1，各个终端装置10在参加会话的情况下，只需指定要发送接收数据的对象的终端装置中的任意一个来向管理服务器100请求参加，就能够参加所指定的终端装置所参加的会话，成为能够与参加同一个会话的所有终端装置之间发送接收数据的状态。另外，在希望的通信对象没有进行会话的情况下，能够自动生成新的会话组。因此，每次参加会话时，不需要会话房间(session room)的设定这种复杂的操作，能够提高会话形成的自由度，同时使得各个装置能够通过简单的操作参加会话。
另外，通过让音源设定的信息也由管理服务器100进行管理，能够向新参加会话的终端装置，通知已经参加会话的终端装置中的音源部的设定内容，反之，对已经参加了会话的终端装置，也能够通知新参加会话的终端装置中的音源部的设定内容。因此，若令各个装置根据该通知进行音源部的设定，那么即使参加会话时用户没有特别进行设定操作，也能够在参加同一个会话的装置之间将音源部的设定内容共通化，不管MIDI事件发送给了哪个装置，都能够按照该MIDI事件发出相同的音。
另外，由于终端装置间的MIDI数据的传输，不经管理服务器100而是点对点进行，因此能够抑制信息传输的延迟量。
接下来，对演奏数据通信管理系统的第2实施方式进行说明。图19为说明该演奏数据通信管理系统的概要构成的方框图。
该图中所示的演奏数据通信管理系统2中，多个终端装置20能够经网络30进行通信，各个终端装置20中兼具第1实施方式中所说明的终端装置10的功能、以及管理服务器100的功能。即，各个终端装置20，既相当于电子音乐装置，又相当于演奏数据通信管理装置。其中，在每一组的会话中将1台终端装置20设为主机节点，只对该主机节点，将作为管理服务器100的功能设为有效，其他终端装置20中将作为管理服务器100的功能设为无效。
另外，万一发生了1个组的会话中有两台以上的终端装置20同时成为主机的状况的情况下，通过实施适当协商，让成为主机的时刻的时间戳较早的一方优先、或随机等方法，只让任意一台作为主机节点发挥作用。在2台以上的终端装置20同时尝试参加会话的情况下，会发生这样的状况。另外，主机可以让可经网络30通信的范围内只存在1台主机节点。
另外，作为网络30，可以使用以LAN或互联网为首的各种通信路径。网络拓扑结构也是任意的。
由于这样的终端装置20，其硬件构成与第1实施方式的终端装置10相同，因此省略其说明。另外，对应的构成要素的符号，使用图2中所示的符号。
以下，通过图20至图24的流程图，对终端装置20所执行的各种处理进行说明。另外，对于与第1实施方式中说明的处理共通的部分，简化或省略其说明。
首先，图20中示出了会话参加时的处理的流程图。
终端装置20，通过未图示的操作设备受理会话的参加指示之后，开始图20的流程图所示的处理。然后，首先对网络30上的所有节点、或设想存在要通过会话进行通信的对象的地址范围等，广播主机检索通知，进行是否存在已经成为主机节点(以下简称作“主机”)的终端装置20的检索(S201)。如果能够分别掌握想要通信的对象，则可以分别发送主机检索通知。该步骤S201的处理中，终端装置20的CPU作为检索机构发挥功能。
之后，由于若存在主机，应该会从该装置返回应答，因此根据其有无来判断主机的有无(S202)，如果存在则向该主机发送参加通知(S203)后结束处理。该参加通知可以与图6中所示的形式相同，但这里由于至少知道主机是通信对象，因此不需要包含通信对象ID。
另一方面，如果不存在主机，则将自机器设为主机(S204)，决定自己所使用的频道(S205)，在音源部17中，在所决定的频道中进行自机所使用的设定(S206)。然后，再生成节点信息表，登录必要的信息(S207)，并结束处理。
接下来，图21中示出了节点信息表的例子。
节点信息表，是各个终端装置20所保存的表，与第1实施方式中的终端装置管理表相对应。而且，对于自身所参加的会话，包含参加该会话的各个终端装置的信息、以及该会话中的主机的ID的信息。
终端装置的信息，可以登录ID、频道编号以及音源设定信息来形成。这里，由于对参加1个会话的终端装置的信息进行处理，因此不需要通信对象ID与组编号，不对其进行登录。
该节点信息表，最低限度可以只由主机保存，但这里考虑到简化主机从会话中脱离的情况下的处理，可以在参加会话的所有终端装置20中保存。
接下来，图22中示出了成为主机的终端装置20所执行的与接收数据相关的处理的流程图。
终端装置20，将从其他终端装置20等外部装置处接收到的数据，暂存在接收缓存中，在自机是主机的情况下，以定期的时刻进行图22的流程图中所示的处理，通过这样，来根据这些数据实施处理。
然后，该处理中，首先确认接收缓存(S211)。之后，如果有参加通知(S212)，则进行步骤S213至S218的与参加通知相关的处理。该处理与图4的步骤S13至S20的处理的不同点在于所参照的表是节点信息表；没有关于组的处理；对通知源装置通知信息时，将节点信息表的内容全部发送；以及，自身也如图10的步骤S47以及S48的情况那样，进行发送目的地列表的更新以及音源的设定(S218)。除此之外，均与图4的步骤S13至S20的处理相同。
另外，这些步骤S213至S218的处理中，终端装置20的CPU作为会话信息通知机构发挥功能。另外，由于主机以外的终端装置20如后所述，不进行该部分的处理，因此可以说，成为作为主机工作的状态后，会话信息通知机构的功能有效。相反也成立。
然后，步骤S218之后，回到步骤S212重复进行处理，如果接收缓存中还有其他数据，则进行与该数据相关的处理。
另一方面，在步骤S212中没有参加通知的情况下，进入步骤S219，这里，如果有脱离通知，则进行步骤S220以及S221的与脱离通知相关的处理。虽然该处理，是与图5的步骤S132以后的处理相对应的处理，但这里，由于让各个终端装置20存储节点信息表，因此还要向其他终端装置通知表的变更内容(S221)。
另外，在步骤S219中没有脱离通知的情况下，进入步骤S222。之后，如果有主机检索通知，则回发自机的ID作为应答(S223)。
另外，在步骤S222中没有主机检索通知的情况下，进入步骤S224以后的处理，在存在MIDI数据、通信错误或其他数据的情况下，进行对应于这些数据的处理(S224～S229)，但该处理与图10的步骤S51至S56的情况相同。
另外，步骤S221、S223、S225、S227、S229之后，回到步骤S212，重复进行处理。
接下来，图23中示出了主机以外的终端装置20所执行的与接收数据相关的处理的流程图。
主机以外的终端装置20，以定期的时刻，取代图22的流程图进行图23的流程图所示的处理，通过这样，进行对应于保存在接收缓存中的数据的处理。
之后，该处理中，首先确认接收缓存(S231)。然后，如果有状态通知(S232)，则按照通知内容对自身所保存的节点信息表进行更新(S233)，同时，给演奏输入设备16分配频道，进行音源部的设定以及发送目的地列表的更新(S234)。该步骤S234的处理，与图10的步骤S42至S48的处理相对应。
另一方面，步骤S232中如果有状态通知，则进入步骤S235。然后，这里如果有脱离通知，则进行与步骤S236至S238的脱离通知相关的处理。另外，由于主机以外的终端装置20，在从会话脱离的情况下，向主机发送脱离通知，因此如果主机以外的终端装置20接收到脱离通知，则只会是来自主机的。反之，在主机要从会话脱离的情况下，向参加会话的终端装置20中接下来要成为主机的终端装置20，发送脱离通知。
然后，与脱离通知相关的处理中，首先在节点信息表中将自机作为主机登录(S236)，从节点信息表中删除脱离的终端装置(前主机)的信息(S237)。通过这样，以后将正在执行该处理的终端装置20作为主机来发挥功能，将对已脱离的装置的频道分配也解除。之后，向登录在节点信息表中的其他全部终端装置发送状态通知，通知表的变更内容(S238)。通过以上的处理，能够进行主机的变更。
另外，在步骤S235中没有脱离通知的情况下，进入步骤S239以后的处理，在存在MIDI数据、通信错误或其他数据的情况下，进行对应于这些数据的处理(S239～S244)，但该处理与图10的步骤S51至S56的情况相同。
另外，步骤S234、S238、S240、S242、S244之后，回到步骤S232重复进行处理。
另外，终端装置20与管理服务器100的情况不同，在参加会话的各个终端装置中的音源设定被变更的情况下，通过MIDI事件接收该通知。另外，即使没有另外对该内容进行保管，只要参照自身的音源部17中的设定内容，也能够掌握对分配给各个终端装置的频道进行了怎样的设定。因此，即使不像第1实施方式的情况那样使用设定变更通知，也能够根据这些信息，将节点信息表中的音源设定信息的内容，保持为符合各个终端装置的现状的状态(省略了该处理的图示)。但是，本实施方式中，也可以在MIDI事件的发送接收之外，另行进行设定变更通知的发送接收。这一点对主机以及主机以外的终端装置20均一样。
接下来，图24中示出了终端装置20的CPU所执行的与数据发送相关的处理的流程图。
该处理，在主机与主机以外的终端装置中均共同执行。而且，该处理所发送的通知中有参加通知、脱离通知、主机检索通知等，由于发送目的地不唯一，因此在步骤S254、S255中，确定应当发送通知的对象(例如主机)后进行通知的发送，除此之外均与第1实施方式中图11所示的处理基本相同。
成为主机的终端装置20，通过进行以上的图22以及图24中所示的处理，能够兼具第1实施方式中的终端装置10与管理服务器100的功能来工作。
另外，主机以外的终端装置20，通过进行以上的图23以及图24所示的处理，能够实现与第1实施方式中的终端装置10相同的功能，并且在主机作出请求的情况下，能够进行动作来作为下个主机发挥功能。
接下来，对照图25至图27，对各个终端装置20通过上述处理所进行的工作顺序的例子进行说明。另外，这些图中为了分别区别多个终端装置，给各个终端装置标注A、B、C的符号来进行说明。
首先，图25中表示的是，第2个终端装置(终端装置B)对成为主机的终端装置A(设ID为“ID#1”)进行参加通知的情况下的处理顺序例。
这种情况下，终端装置B(设ID为“ID#2”)，通过图20的步骤S201的处理用广播进行主机检索(S311)，与此相对，作为主机的终端装置A，通过图22的步骤S223的处理回发应答(S312)。于是，终端装置B向回发了该应答的终端装置A，通过图20的步骤S203的处理，发送包含ID#2作为自机ID、包含Prog#2作为音源设定信息的参加通知(S313)。
之后，接收到该通知的终端装置A，通过图22的步骤S214以后的处理，将频道CH#2分配给终端装置B，使其不与终端装置A重合(S314)，同时，在节点信息表中登录终端装置B的信息(S315)，按照通知内容，在音源部17的CH#2的频道中进行Prog#2的内容的设定，并将终端装置B的地址信息登录到发送目的地列表中(S316)。之后，向终端装置B发送状态通知，通知节点信息表的内容(S317)。
终端装置B根据该通知，通过图23的步骤S233以后的处理，更新节点信息表(这种情况下为新生成)(S318)，并将CH#2分配给演奏输入设备16，音源部17中在CH#1、CH#2的频道中分别进行Prog#1与Prog#2的内容的设定，并将终端装置A的地址信息登录到发送目的地列表中(S319)。
这样，通过以上，成为终端装置A与终端装置B能够互相点对点发送接收MIDI数据的状态，并开始通信(S320)。
接下来，图26中表示的是，图25的处理之后，下个终端装置(终端装置C)对终端装置A进行参加通知的情况下的处理顺序例。
这种情况下，终端装置C(设ID为“ID#3”)，与图25的情况一样，与终端装置A之间交换主机检索与应答(S331、S332)，之后，向终端装置A发送包含ID#3作为自机ID、包含Prog#3作为音源设定信息的参加通知(S333)。
然后，接收到该通知的终端装置A，还是通过图22的步骤S214以后的处理，将频道CH#3分配给终端装置C，使其不与终端装置A以及终端装置B重合(S334)，同时，在节点信息表中登录终端装置C的信息(S335)，根据通知内容，在音源部17的CH#3的频道中进行Prog#3的内容的设定，并将终端装置C的地址信息登录到发送目的地列表中(S336)。之后，向终端装置C发送状态通知，通知节点信息表的内容(S337)。另外，还向参加同一个会话的终端装置B，通知节点信息表的变更内容(S338)。
之后，终端装置B以及终端装置C，分别根据状态通知，更新节点信息表(S339)，同时进行发送目的地以及音源等的设定(S340)。然后，通过以上，成为终端装置C能与终端装置A以及终端装置B互相点对点发送接收MIDI数据的状态，并开始通信(S341)。另外，终端装置A与终端装置B，像之前一样继续通信(S342)。从而，通过上述的处理，成为终端装置A、B、C能够互相点对点通信的状态。
另外，从终端装置C来看，只需向主机发送参加通知，就能够成为可与参加该主机所管理的会话的所有终端装置，同时进行通信的状态。
接下来，图27中表示的是，图26的处理之后，在终端装置A中实施会话的停止操作的情况下的处理顺序例。
这种情况下，终端装置A检测到停止操作后，向参加会话的任意一个终端装置发送脱离通知(S351)，同时，中止与其他终端装置之间的通信(S352)。给哪个装置发送，既可以随机决定，也可以按照用户的指示来适当决定。
这里，若设发送给终端装置B，终端装置B，通过图23的步骤S236以后的处理，在节点信息表中将自机作为主机登录(S353)，并从节点信息表中删除终端装置A的信息(S354)。之后，发送登录在节点信息表中的其他节点的状态通知，并通知节点信息表的变更内容(这里，是变更后的表本身)(S355)。
这里，通知目的地为终端装置C，接收该通知的终端装置C，通过图23的步骤S233以后的处理，根据通知内容对节点信息表进行更新(S356)。
另外，此前与终端装置A进行会话的终端装置B以及终端装置C，由于通过终端装置A的通信中止，与终端装置A之间的通信失败(S357)，因此通过图23的步骤S242的处理，将终端装置A从发送目的地列表中删除(S358、S359)。但终端装置B与终端装置C之间的通信仍继续(S360)。
另外，也可以在步骤S354或S356之后，立刻将终端装置A从发送目的地列表中删除。
通过以上的处理，终端装置A在从会话中脱离之后，能够将作为主机的动作交接给终端装置B。这种情况下，由于各个终端装置中保存有节点信息表，因此脱离的一方只进行脱离通知即可。从而，能够使得脱离时不会发生负荷较大的处理。
以上结束了对实施方式的说明，但装置的构成、具体的处理内容以及数据的形式等，当然并不仅限于上述各个实施方式中说明的示例。
例如，所处理的演奏数据的形式可以不是MIDI形式，也并不仅限于通过点对点形式进行MIDI数据的传输的系统。终端装置10之间的数据传输，还可以经管理服务器100或其他的传输服务器来进行。
另外，第1实施方式中，每当上述音源部17的设定变更时，各个终端装置10，在正参加着会话时进行音源部17的设定变更的情况下，不将其内容发送给其他终端装置，而只通知给管理服务器100，其他终端装置按照管理服务器100所发送的设定变更通知，来变更音源部17的设定。
这种情况下，想要变更设定的终端装置10，既可以按照自身所生成的MIDI事件，对自机的音源部17变更设定，也可以按照来自管理服务器100的设定变更通知，对自机的音源部17进行变更。通过这样，可很容易地将参加会话的所有终端装置的音源部17的设定保持为统一的内容。
另外，管理服务器100，即使没有特别变更，也可以对每一个会话，将参加会话的所有终端装置中的设定内容，定期通知给参加该会话的所有终端装置。如果像这样定期进行通知，即使在一部分数据因通信异常而丢失的情况下，也能在之后的通知时补偿该丢失。
另外，各个终端装置，事先使得参加会话时所使用的ID能够登录·存储·公开在互联网上的门户站点等中，通过对该门户站点的用户列表进行检索等，使得用户能够找出会话的对象。这种情况下，可以将通过检索所得到的ID指定为通信对象的ID，来向管理服务器100请求参加会话。
另外，作为管理服务器100的功能，进行音源部的设定内容的管理以及通知并不是必需的，最低限度可以对每一个进行会话的组，管理终端装置的ID，给终端装置分配频道，通过上述的状态通知，进行ID以及频道的通知。
另外，虽然这里对给参加会话的各个终端装置各分配1个频道的例子进行了说明，但并不仅限于此，还可以分配多个频道。
另外，在设置具有终端装置10与管理服务器100这双方的功能的装置的情况下，可不像第2实施方式那样，准备具有将它们组合起来的功能的装置，而是只准备分别具有这双方的功能的装置。这种情况下，终端装置10还有可能对自身没有参加的会话进行管理。另外，这种情况下，具有管理服务器100的功能的终端装置10可以是1台。
另外，第2实施方式中，各个终端装置20中，可以不设置发送目的地列表，将登录在节点信息表中的终端装置当作发送目的地来处理，进行MIDI数据的发送。
另外，将用来让计算机作为上述的终端装置10、20以及管理服务器100发挥功能的程序，事先存储在ROM或HDD等中，或记录在CD-ROM或软盘等非易失性存储媒体(存储器)中来提供，并从该存储器中将该程序读出到RAM中后由CPU执行，或从具有记录着程序的存储媒体的外部机器或将程序保存在HDD等存储机构中的外部机器中下载后执行，也能够得到同样的效果。
另外当然，各个实施方式以及变形例的内容，可以在不矛盾的范围内组合使用。
从以上说明可以得知，通过采用本发明的电子音乐装置，在多个装置间发送接收演奏数据的情况下，能够提高用于数据的发送接收的会话形成的自由度，同时能让各个装置通过简单的操作参加会话。
从而，能够提供一种操作性较高的通信环境。
权利要求
1.一种电子音乐装置，具有通过通信网络进行与其他电子音乐装置之间相互交换演奏数据的会话的功能，设置有检索机构，其对管理上述会话的主机装置进行检索；在通过该检索没有发现主机装置的情况下，让自己作为主机装置工作，在发现主机装置的情况下，向该发现的主机装置发送包含有自身的识别信息的参加通知的机构；存储机构，其保存正在参加该会话的电子音乐装置的识别信息，来作为上述会话的信息；会话信息通知机构，其在作为主机装置工作的情况下，在从其他电子音乐装置接收到参加通知时，将该其他电子音乐装置的识别信息保存到上述存储机构中，同时在自身所管理的会话中给该其他电子音乐装置分配空置的频道并通知给该其他电子音乐装置，进而，根据保存在上述存储机构中的识别信息，将参加所述自身所管理的会话的各个电子音乐装置的识别信息以及对应的频道的信息，也通知给上述其他电子音乐装置；在没有作为主机装置工作的情况下，从上述发现的主机装置处接收作为对上述参加通知的应答发送来的频道的分配，同时，将该发现的主机装置所通知的识别信息保存到上述存储机构中的机构；以及，与由保存在上述存储机构中的识别信息所确定的其他电子音乐装置之间，互相交换上述演奏数据的机构。
2.如权利要求1所述的电子音乐装置，其特征在于设有在作为主机装置工作的情况下，对应于从其他电子音乐装置接收到脱离通知这一情况，将该其他电子音乐装置的识别信息从上述存储机构中删除，根据保存在上述存储机构中的识别信息，将该存储机构中所保存的识别信息的变更内容，通知给参加上述自身所管理的会话的各个电子音乐装置的机构。
3.如权利要求1所述的电子音乐装置，其特征在于设有在不作为主机装置工作的情况下，对应于从作为对参加中的会话进行管理的主机装置的电子音乐装置接收到脱离通知这一情况，将该电子音乐装置的识别信息从上述存储机构中删除，同时，让自身作为对上述参加中的会话进行管理的主机装置工作，进而，根据保存在上述存储机构中的识别信息，将表示自身是主机装置的信息以及上述存储机构中所保存的识别信息的变更内容，通知给参加自身所管理的会话的各个电子音乐装置的机构。
全文摘要
在进行经通信网络与其他终端装置之间相互交换演奏数据的会话的情况下，对管理该会话的主机装置进行检索(S331)，在能够找到主机装置的情况下，将参加通知发送给该主机装置(S333)，并受理频道的分配作为应答，同时存储主机装置所通知的识别信息(S338～S340)。在没有找到主机装置的情况下，将自身作为主机装置来发挥功能，进行与参加通知相应的频道的分配、以及参加会话的终端装置的信息的通知(S334、S337等)。
文档编号G10H1/00GK1838233SQ20061007179
公开日2006年9月27日 申请日期2006年3月22日 优先权日2005年3月25日
发明者梅泽悟, 宫部素明 申请人:雅马哈株式会社