Music Project

Music Project - wiki http://www23.atwiki.jp/musicprog16/ Music Project - wiki ja 2010-03-11T02:24:34+09:00 トップページ http://www23.atwiki.jp/musicprog16/pages/1.html 2010-03-11T02:24:34+09:00 新規習得技術など http://www23.atwiki.jp/musicprog16/pages/38.html 新規習得技術・活用した講義・参考文献前期のを貼り付けておくので各自編集してください。付録A 　新規習得技術 ●高谷有紀子 -MAX/MSPによるプログラミング技術 -Flash作成技術 ●佐藤佑樹 -C++によるプログラミング技術 -Max/MSPによるプログラミング技術 -インタフェースの操作技術 ●古川祐太 -C++によるプログラミング技術 -Max/MSPによるプログラミング技術 -MIDI制御に関する知識 -音楽に関する基礎知識 ●下村京平 -Flash・Action Script技術 -Max/MSPによるプログラミング技術 -プレゼンテーション能力 ●飯田悠司 -Flash・Action Script技術 -Max/MSPによるプログラミング技術 -音楽理論に関する基礎知識 ●田中慎太郎 -MAX/MSPによるプログラミング技術 -Flash作成技術 ●茅野裕馬 -C++によるプログラミング技術 -Max/MSPによるプログラミング技術 -MIDI制御 ●寺井明日実 -C++によるプログラミング技術 -Max/MSPによるプログラミング技術 -プレゼンテーション能力付録B　活用した講義 ●高谷有紀子 -物理学入門 -科学技術リテラシ -情報表現基礎Ⅰ -情報表現基礎表現Ⅰ ●佐藤佑樹 -インターネットテクノロジ -プログラミング演習 -情報アーキテクチャ演習 ●古川祐太 -複雑系学科演習 -心理学 -プログラミング演習 -プログラム言語論 ●下村京平 -プログラミング言語論 -プログラミング演習 -情報表現基礎Ⅰ -情報表現基礎演習Ⅰ ●飯田悠司 -プログラミング演習 -複雑系学科演習 -CommunicationI～IV -情報表現基礎Ⅰ -情報表現基礎演習Ⅰ ●田中慎太郎 -情報表現基礎Ⅱ -情報表現基礎演習Ⅱ -情報デザインⅠ -情報デザイン演習Ⅰ -情報表現基礎Ⅲ -情報表現基礎演習Ⅲ -情報デザインⅡ -情報デザイン演習Ⅱ -ヒューマンインタフェース -ヒューマンインタフェース演習 ●茅野裕馬 -インターネットテクノロジ -プログラミング演習 -認知心理学 -認知心理学演習 ●寺井明日実 -インターネットテクノロジ -プログラミング演習 -認知心理学 -認知心理学演習参考文献 [1]　WiiMusic, http://www.nintendo.co.jp/wii/r64j/index.html, 任天堂, 2008 [2]　斎藤音楽研究所「Max/MSP/Jitter　ドキュメント日本語版」, http://www.s-musiclab.jp/sml_main.html [3]　WiiYourself!, htt p :// wiiyourself.gl.tter.org / , gl・tter , Jul, 24 2008 [4]　ノイマンピアノ（赤松正行、左近田展康）,2016：Max オデッセイ―音楽と映像をダイナミックに創造する！最高の開発環境を徹底解説,　Rittor Music, 2006. [5]　はじめてのMax/MSP, http://www.sonasphere.com/max/, 徳井直生, 2008 [6]　林知行，標準ポピュラー・コード理論，東京，シンコーミュージック・エンターテイメント，2006 [7]　プログラミングの丘，コード判別-Easy コーダー，http://jet2.u-abel.net/music/chord_d.htm　，Oct，28 2009 [8]　music-theory.net , オンライン理論講座，http://www.music-theory.net/page.to?to=13　，Jan, 13 2010 2010-01-13T20:58:17+09:00 メニュー http://www23.atwiki.jp/musicprog16/pages/2.html 2010-01-08T16:59:52+09:00 最終報告書　第3章 http://www23.atwiki.jp/musicprog16/pages/27.html 2010-01-07T18:48:05+09:00 最終報告書　第5章(テキストモード) http://www23.atwiki.jp/musicprog16/pages/35.html 元の5章のページが容量オーバーになってしまったのでテキストモードで新たに作成しました。5章についてはこのページを編集してください第5章　結果　5.15.MIDIを制御するプログラム 5.1.1　成果　これはMIDIを用いて製作された楽曲の再生、及びその楽曲のテンポ、ダイナミクス、ピッチをユーザがリアルタイムに操作し、変化させる事のできるソフトウェアである。ユーザが楽曲の不連続感や不自然さを感じずに操作できることを目標として製作された。 5.1.2　仕様　このプログラムはあらかじめ用意されたMIDIファイルを読み込んで再生を行い、再生されているMIDIファイルのテンポ、ダイナミクス、ピッチをリアルタイムに操作、変化させることができる。開発環境はMAX/MSPを使用した。パラメータの操作を行う際は、MIDIデータに設定されている楽器ごとの操作ではなく、一度に全ての楽器に対し各パラメータの操作を行う。実際の操作はMAX/MSPの画面上から行う形をとった。 5.1.3　解決手順　まず、ダイナミクスの操作の方法について考えることとした。当初は各音の打鍵の強さを表すパラメータであるベロシティの値を操作する事により、ダイナミクスの表現を行うこととした。しかし、ベロシティは音が鳴っている間に変化することを想定していないパラメータであるために、リアルタイムで操作を行った際に本来のそれぞれの音の長さで止まらなくなってしまうという問題が発生した。そこで、実際にリアルタイム操作を想定したパラメータである、エクスプレッションを操作する事によってダイナミクスの表現を行う形をとった。テンポに関しても同様にしてリアルタイム操作を想定したパラメータであるピッチベンドを操作する事によりピッチの変化を表現する事とした。　テンポの操作に関しては、再生時に元々MIDIデータに記録されているテンポ情報を無視してMAX/MSP 上からの操作ができる様に命令を付加することにより、実現できることが昨年のプロジェクトで判明していたため、それを流用することとした。　楽器ごとのパラメータ操作をできる様にも一度実装はおこなってみたが、MIDIデータを製作する段階である程度の設定を行わなくてはならないという問題が発生したため、最終的には全ての楽器を同時に操作する様に実装を行うこととした。 5.1.4　評価　このプログラムによって楽曲の不連続感や再生時の不具合なく、スムーズな操作を実現する事ができている。しかし、楽曲再生を行う際に簡単な設定を毎回行わなくてはいけないという問題点や、各楽器ごとのパラメータ操作の実装に関しては多少の問題を抱えてしまう結果となったため、今後解決策を考えていかなければならない。また、完成された楽曲全体のピッチをシームレスに操作してしまうと、楽曲が不自然に聞こえてしまうということが判明した。 5.2　Max間通信プロトタイプ 5.2.1 成果　このプログラムは、Wiiリモコンによるパラメータ操作を操作の簡易化のためにリモコン1台につき１パラメータのみ対応させる、つまり１つのMIDI音源に対して複数台のWiiリモコンで操作するという決定から必要となった。wii コントローラとPCを繋げるときに、PC1台に対し複数のwiiコントローラを繋ぐか、PC1台に対し1台のwiiコントローラを繋ぎかつ複数PCの通信を行うか、どちらにするかという事が問題となり、話し合いをした結果、接続が容易であるという点より後者に決まり、今回のMAX間通信が必要となった。このプログラムによって別のPC とのMAX内のデータのやり取りが可能となった。図1は今回行った通信の概要図である。　　　　　　　　　　　　　　　　　　　　　　　　　　　図１ 5.2.2 仕様　これはMAX/MSP を複数のPC間で操作するために製作されたプログラムである。このプログラムはwii コントローラのロールから得た値を、MIDI操作を行っている別PCへ送信するために作られている。これにより複数のPC間でパラメータの送受信をする事が可能となる。送信側はポートと受信側のPCのアドレスを指定し、受信側はポートを指定する事で送受信を行っている。後述のMusic Fuzzy内においては、音量を調整する値とテンポを調整する値の二つのパラメータがリアルタイムにMIDI操作を行うPCへ送られており、それによって曲調が変化している。 5.2.3 解決手順　まず何故、PC1台に対し複数のwiiコントローラを繋ぐではなく、PC1台に対し1台のwiiコントローラを繋ぎかつ複数PCの通信を行う方式で行うことになったのかというと、後者の方が接続が容易であるという理由もあったが、処理の重さの違いも理由であった。そもそもMAX/MSP自体処理がそれほど軽くなく、その上メインとなるPCではFALSHも起動するため用いているPCのスペック上ぎりぎりの状態であった。そこに更にWiiリモコンを複数台接続するとなるとPCがフリーズしだす可能性も否定できなかった。そのため通信自体もある程度負荷はかかるが、１台で全ての処理をこなすよりも処理を複数のPCに分散した方が余裕が出来ると判断し、後者の接続方法を採用することとなった。　通信方法についてはMAX間で互いにアドレスの指定をし合い、それによって通信を行っている。今回の通信方式はUDP/IP通信を採用しているが、当初の通信方法はTCP/IP通信であった。しかし、リアルタイムに値を送信していく必要があり、その場合TCI/IP通信の「送信を失敗した場合、再送信を行う」という性質上エラーが頻発した。これは送信に失敗した際に再送信するため、どんどんデータが溜まっていき処理しきれなくなり発生するものであった。よって実装の際は「送信に失敗した場合、再送信を行わず次のデータを送る」という性質をもつUDP/IP通信を用いる事になった。これによってエラーが発生しなくなったのと引き換えに送信に失敗した場合は値が飛ぶことになるが、次々とリアルタイムに値が送信されているためほぼ問題はなかった。 5.2.4 評価このプログラムはMAXを複数PC間で用いる場合に必須といえるものであり、今後も利用していくと考えられる。これによって処理が膨大になり1台のPCだけでは動作が難しい状態になった場合でも複数のPCに分担することで解決することが可能となった。　問題点としては使用するPCが異なる場合にアドレスが異なるため毎回変える必要があり、製品版が無くランタイム版しか使えない場合オブジェクトの内容を変更することが出来ず、アドレスの変更が不可能なため通信が出来ないという点である。発表するときのように毎回決まったPCを用いるならば問題は無いが、それだけでは汎用性がない。そのため今後、例えばオブジェクトをクリックするだけでアドレスを任意に変更出来るような機能を追加する予定である。（文責：古川裕太） 5.3　MAX/MSP-FLASH間通信 5.3.1　成果　MIDI や音に関する処理を行っているMAX/MSP とGUI であるFlash 間の通信を実現している。 MAX/MSP とflash双方で送信と受信を行うことが可能である。 5.3.2　仕様　Flash とMAX/MSP間でXML ソケットを用いた通信を実現する事を目的とし、Olaf Matthes 氏が製作した flashserver というMAX/MSP上で使用する事のできるコンポーネントを用いて実装する形をとった。0.05秒に 1度、3つの数値をFlash側に送信し、表示している画面の位置をFlashからMAX/MSPに送信する形をとった。 5.3.3　解決手順　昨年度のプロジェクトでも同じ様にflaseserverを用いたXML ソケット通信を行っていたため、それを参考にして実際の製作を行った。しかし、前述したMAX間通信を行っている際、MAX/MSP-Flash間で送受信を同時に行ってしまうと、処理が重い事が原因でMAX/MSP側のソフトウェアが落ちてしまうという問題が発生した。そのため、flashserverで送信と受信が同時に行うことがないように、また当初0.01秒に一度のデータ送信を行うように設定していたが、0.05秒に一度に頻度を下げるよう実装を行うことによりこの問題を回避することに成功した。 5.3.4　評価　MAX/MSPで計算したデータのFlashへの送信に関してほぼ実現する事ができた。今後のMAX/MSPや Flashを利用したソフトウェアの製作に役立てていくことができるだろう。しかしながら、頻度の高い送信や、送受信を同時に行うことができない等の問題をfalshserverが抱えており、今後送信するデータの増加も考えられるため、もっと負荷の軽い通信方法を考えていかなければならない。 5.4 pro16wii 5.4.1　成果　このプログラムは、wii リモコンの各センサの値をMAX/MSP上でとるためのMAX/MSPのエクスターナルとして製作された。かなり速く操作を行った場合でも、停止することなく値をMAX/MSPに渡すことができる様になっている。 5.4.2　仕様　開発環境はC++を使用している。gl.tter氏が中心となって開発されたwiiyourself というライブラリを元にして開発を行った。wiiリモコンの3軸加速度センサの値や重力加速度の値を用いて算出されるロールやピッチといった動きの値、またボタンの入力等をMAX/MSP上でとることができる。pro16wii単体での動作はできる様にはなっておらず、MAX/MSP上での設定をする事により利用することができる。 5.4.3　解決手順　昨年のプロジェクトでもwii リモコンを利用していたため、昨年開発したpro10wiiを元にして開発を行った。当初はpro10wii をそのまま流用してソフトウェア開発を行っていく予定だったが、wii リモコンを速く動かしすぎるとロールやピッチの値をしばらく取ることができなくなる、というバグが存在していたため、その修正をすることとなった。　まず、wiiyourself内でどのような計算をしているのかを実際にwiiyourself のライブラリ内を読んで行くことにより理解する事とした。その結果、ライブラリ内で行っている計算の中にロールやピッチの値をとるだけならば無駄となってしまう部分があったため、実際のロールやピッチの値を出すための計算をライブラリ内ではなく、実行するプログラム内で行い計算を簡略化する事によりこの問題を解決する事とした。その結果、どんなに速くwiiリモコンを動かしても値がとまることなく取れるようにする事ができた。 5.4.4　評価　昨年度製作したpro10wii よりも動作が高速で正確な値をとることができる様になっている。しかし、加速度センサを利用しているため、ユーザが本来示したい値をとるまでに、その値の位置に持っていくまでの動かす速度によっては若干のずれが生じてしまうという問題は加速度センサ単体を使っている限りは避けることができない。よって今後もwii リモコンを使ってロールやピッチといった動きで値をとるならば、ジャイロセンサ等を用いた値の修正を行っていかなくてはならない。また、wiiyourself内では本来重力加速度の値を最大１して算出しなくてはいけないが、ごくまれに 1.05という値が算出されてしまうため、ロールの計算がある角度でうまくいかず間違った値が算出されるというバグがいまだ残っているため、 wiiyourselfそのもののデバッグをさらに行う必要がある。 5.6 Music Fuzzy 5.6.1 成果　このプログラムは前期までに開発、取得した技術を合わせたものである。まずpro16wiiはwiiコントローラから取った値を音量やテンポにそれぞれ対応した値へと変換を行い、その値をMAX間通信によりMIDI操作を行っているPCへと送信するプログラムである。そしてメインとなるプログラムでMIDI音源の再生を行い、そのMIDI音源の音量とテンポをpro16wiiから送られてきた値によりリアルタイムに変化させる。更にそれらの値をメインプログラム内にあるパッチ、CALPISの中でFLASHの画面へと視覚フィードバックしている。またCALPISではWiiリモコンのボタン操作によるFLUSHの再生、停止といった動作の管理も行っている。これらの一連の全てのプログラムを統合したものが、成果物であるMusic Fuzzyのプログラムである。図2はこの処理を行うMAX/MSPの全体像である。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　図２ 5.6.2 仕様　これはwii コントローラのロールによってMIDI音源の音量とテンポを操作するプログラムである。Pro16wii によってwii コントローラとMAXを接続することでこちらの対応している値も変化するようになっている。　　また、FLASHとの通信も行っており、Wiiリモコンから得たテンポと音量の値の情報を画面へと反映し、分かりやすくする役割も担っている。Wiiリモコンのボタン操作にも対応しており、wii コントローラの方向キーの上下でFLASHの選択肢も上下し、Aボタンで決定、Bボタンでキャンセルが出来るようになっている。またMIDI音源再生中にBボタンを押す事で再生を終了し、メインメニュー画面へ戻るようになっている。これにより、一度プログラムを起動してしまえばいちいちWiiリモコンとマウスを再生や停止をする度に持ち替えなくても操作をすることが可能となっている。 5.6.3 解決手順　これまで取得してきた技術により、音量の調整やテンポの変化、MAX間通信とMAXフラッシュ間通信といった、今まで作成してきた全てのプログラムを繋ぎ合わせ作成した。　テンポの操作に関しては、MIDI音源を開始するオブジェクトに数字を加えれば変化するという単純な方法もあったのだが、こちらは一度演奏を始めるとテンポを変えることが出来なかった。そのため、現在の方式へと変更された。この方式ではtempoというテンポを調整するオブジェクトとトグルも用い、細かい時間に何度も値を送信することでMIDI音源にテンポ情報を反映させている。また、この方法を用いる際にMIDI音源を開始するSTARTというメッセージオブジェクトの最後に-1をつける必要がある。Wiiリモコンと接続する際には、Wiiリモコンのロールとの割合によってテンポが0.5倍～1.5倍程度になるように調整した。基本となるテンポの値が１２８であるため、そこに別のPCで計算されたWiiリモコンより送られた値を元にして計算された±60程度の値を加算することでテンポの調整を行っている。　また音量の調整に関しては、値の幅が０～１２７までであり、全ての値を操作可能にした場合、小さくしすぎると聞こえなくなる問題があった。そこでWiiリモコンのロールとの割合を１００を基本とし±３０程度になるように調整を行った。またgakkiというパッチ内において全てのMIDIチャンネルの音量を調節している。そのため、チャンネルごとの変化も可能となるが、今回は簡単な操作を目標としたため、一括の操作とした。　次にCALPISというパッチについては、初めの段階ではMDI制御部分とWiiリモコン検出部分を繋いで終わりであったが、wii コントローラによる操作の実装にあたって全ての操作をWiiリモコンで出来るようにMIDIの再生、停止といった操作を追加する必要ができ、またwii コントローラのボタンを各ボタンへと関連付ける必要もあった。そのためMIDI操作部分にCALPIS というパッチを追加した。図2の左側がそれにあたり、ここはFLASHに関係しているプログラムである。 FLASHにWiiリモコンより得たパラメータの表示を行ったり、FLASH側の操作によりMIDI音源の再生や停止、流れるMIDI音源の選択を行う等、FLASHとMAX間での通信が行われている。 5.6.4 評価　wiiコントローラによる音量とテンポ操作、FLASHの操作という当初の目的は達成出来た。しかし曲数が2曲と少ない点が見受けられる。また、MIDI音源自体の音量を変えることしか出来ず、楽器パートごとの音量調整には対応していなかった。そのため今後改良を加え、パートごとの音量調節、曲数の増加といった要素を追加する予定である。　今回、伴奏の音量やテンポの操作を目標として作成したが、実際に操作をしてみると操作できるパラメータが少なく、また伴奏の音自体は変化していないため指揮者的な要素が強くなってしまっていたため、演奏しているという感覚が十分では無かった。よって今後は旋律自体を操作出来るような機能を追加する必要があるかもしれない。（文責：古川裕太） 5.2 ロールコントローラー（下村）終　　　5.2.1　成果　　5.2.1　成果　より楽器を演奏している気分に近づけるために、オーケストラの指揮者が指揮棒を振る動きをイメージしてロールコントローラー（図すうじ）というものを作成した。ロールコントローラーの軸部分にWiiリモコンを固定することによって、三軸加速度センサーを利用したロール操作のぶれがなくなり、安定したラジアン（角度）値を取ることができるようになった。操作方法も、取っ手部分を回すのみなので、従来のWiiリモコンのロール操作よりも簡易化することができた。よって、初心者でも簡単に操作することができる。　　　　　　　　　　　　「がぞう」　　　　　　図.すうじ　ロールコントローラー　　　5.2.2　仕様　木製の円盤２枚の軸部分にWiiリモコンが入る大きさの箱を取り付け、ネジで固定した。片方の円盤部分にユーザーが操作する取っ手部分を取り付けた。　今回は１台のWiiリモコンに１つのパラメーターを割り当てるプログラム仕様であり、操作対象となるパラメーターがダイナミクスとテンポなので、計２台のロールコントローラーを作成した。ユーザーが取っ手部分を回すことにより、テンポとダイナミクスを操作することができる。時計で例えると、１２時の位置の値が基準になるようにWiiリモコンを固定している。そこから時計まわり（ユーザーに対して右方向）へ回転させるとダイナミクスは大きくなり、テンポは速くなる。反時計まわり（ユーザーに対して左方向）へ回転させるとダイナミクスは小さくなり、テンポは遅くになるようになっている。　非常にシンプルな操作方法であり、軸部分にしっかりとWiiリモコンが固定されているため、かなり安定したラジアン（角度）の値を検出できている。よって、初心者の方にも使いやすく、音楽経験者の方はかなり細かい操作も可能である。　　　5.2.3　解決手順　まずはじめに、音楽を表現している気分になる動きは、どのような動きなのかを考えた。ギターやピアノなどの楽器を弾く動き、ダンスを踊る動き、指揮棒を振る動きなどがあげられ、この中でWiiリモコンのロールの動きをうまく変換できるものとして指揮棒を振る動きを選んだ。一般的に指揮者が２拍子や３拍子、４拍子を振る動きは、感情のこもり方や曲調によって、また指揮をする人によってもかなり動きに違いがでてくるものである。そのため、２拍子の指揮の振り方を横にしたような感じで、左右に弧を描く腕の振り方に操作方法を限定して、その動きにロール操作から変換させようということにした。　次に、インタフェースの具体的な形を決めるために、１００円ショップ等でフリスビーやワイヤーなど使えそうなものを買ってきて、簡易版のコントローラーを作成した。そこから具体的な形を導いた結果、円盤を２枚設置し、その２つの間の軸の部分にWiiリモコンを固定することによって、Wiiリモコンのローの動きを先ほど述べたような指揮棒を振る動きに変換可能であると考えた。また、卓上で操作することも仮定し、ワイヤーだけでパーツ同士を固定するのではなく、しっかりとした土台が必要であることもわかった。　これらをふまえて実際のコントローラーの設計を決めた。材料は加工が自分たちでしやすいように木材を使用することにした。木材と木材を繋げる部分には金属のネジ、土台とコントローラーを固定する部分には、家具を固定する際に使用するL字の金具を使用した。Wiiリモコンのロール操作を指揮棒を振る動きに変換することから、この装置をロールコントローラーと名付けた。　　　5.2.4　評価　ロールコントローラーの使用によって、作成したソフトウェアに対し、Wiiリモコンが送るラジアン（角度）の値をかなり正確にとることが結果よりわかったので、外付けのコントローラーとしては役割を果たしていたといえるだろう。しかし、操作方法においては中間発表のアンケートの結果、あまり演奏している気分になれないといった感想が多かった。Wiiリモコンがとっていた値はロールによるラジアン（角度）の値であり、加速度をとっているのではないため、実際の操作方法は指揮者のようにリズムをとるような動きを再現出来ていなかった。CDコンポなどのボリュームを調整する操作とさほど変わらないのではないかといった声もあったため、後期に向けての改善点の一つとして、演奏に近い操作を可能にするインタフェースを研究、開発するという目標ができた。　5.3 Sortcode（寺井）終 5.3.1　成果　このプログラムは流れている伴奏のどの音が鳴っているかという情報を読み込み、どのコードであるかを判別する処理を行う。この次に行うコードに調和する音を判別し、振り分けるという処理へ繋げるために必要なプログラムである。 5.3.2　仕様　開発環境はC++である。伴奏の音の情報はインレットから数字として与えられ、その情報を読み込んでコードを判別する。判別する部分は単純にif文で書かれている。白鍵の音のみで構成された3音または4音のコードを判別することが出来る。コードにはあらかじめ数字を割り当ててあり、その数字をアウトレットに出力する。 5.3.3　解決手順　まずはプログラムのアルゴリズムを考えた。大まかな仕組みとしては流れている伴奏のどの音が鳴っているかという情報を読み込んで、同時に鳴っている音からどのコードであるかを判別し、結果を出力する。　音の情報は2つの数字で与えられる。1つ目の数字はどの音であるかを表している。48はドに当たる。レはこれよりも2つ大きい50である。このように音が1音上がるごとに値は2ずつ増えていく。もう1つの数字は音が鳴っているかどうかを表している。音が鳴っていれば1、鳴り終われば0が送られてくる。例えば52と1が送られてくるとミが鳴っているという訳である。プログラム内では高いドと低いドなどのようなオクターブ違いの音も同じ音として扱うために音の種類の数字は12で割った余りで表している。ドは0、レは2、ミは4である。配列arrayを用意し、12で割った余りと配列の添え字を対応させ0か1を格納するという方式をとっている。例えば、array[7] =1ならソが鳴っているということを表している。　流れている伴奏の音の情報は複数が同時に送られてくるのではなく、1つずつ順番に送られてくる。コードの判別には同時に鳴っている3つまたは4つの音を判断しなければならない。そのために鳴っている音の情報は保持しておかなければならない。Max/MSPの仕様上、値の保持にはマルチスレッドモードを用いる必要がある。当初はこのマルチスレッドモードを用いたプログラムを作成していた。しかし、マルチスレッドモードを用いようとすると大量のエラーが検出された。またそれらのエラーの有効な解決方法を見つけることが出来ず、また残された時間から考えるとマルチスレッドモードを用いたプログラムを完成させるのは困難であると判断し、マルチスレッドモードを用いないプログラムを作成することにした。　マルチスレッドモードを用いずに値を保持する方法はインレットとアウトレットを増やし、ある音が鳴っているという情報が送られてきた場合、対応する配列に1を格納し、1が格納されている配列のみ添え字の値を一旦アウトレットから出力する。一旦外に出された値はMax/MSPのオブジェクトを用いてそこに値を保持しておく。音が鳴り終わったという情報が送られてきた場合は配列に0を格納し、音の情報の保持を終わらせる。保持されていた値は次の音の情報が送られてきたときに一緒にsortcodeへ入力される。値が保持されていたということは音が鳴り続いているという意味であるため、対応する配列に1を格納する。完成したsortcodeは図のように最終的にインレットは6つ、アウトレットは5つにまで増やした。どちらもそのうちの4つを値の保持に利用している。1番左のインレットにはどの音であるかの数値が送られてくる。その隣は音が鳴っているかどうかが0か1で送られてくる。その2つ以外のインレットが値の保持されていた値を読み込むために利用されている。アウトレットは1番左が判別されたコードに割り当てられた数値を出力する部分であり、それ以外は保持する値を出力するために利用している。　コードの判別の処理をする部分は単純にif文を繰り返して処理を行っている。理論班が作成したコード表を基にして判別している。例えば以下の記述はドとミとソとシが同時に鳴っていればそのコードはCm7であるという意味である。 if(array[0] == 1 && array[4] == 1 && array[7] == 1 && array[11] == 1) { code=1; //Cm7 } 今回の制作物に対応しているコードは全部で21種類であるため、上記のような処理を21通り行っている。 5.3.4　評価　最も重要であるコードを判別するという処理自体には特に問題もなく動作させることが出来た。しかし、当初作成する予定であったマルチスレッドモードを用いたプログラムを完成させることが出来なかった。マルチスレッドモードを用いないバージョンでは対応させる音を増やすという場合に一回一回インレットとアウトレットを増やすという作業が必要になってくる。アウトレットから出力した値を保持するオブジェクトをインレットと繋ぐことでMax/MSP上のプログラムが複雑で分かり辛くなるという点も問題である。また、コードを判別する部分は単純にif文を繰り返しているだけなので対応する音とコードを増やすという場合には動作が重くなることが考えられる。このツールの性質上リアルタイムで音を判断することが重要であるので動作が重くなる可能性があるということは致命的な欠点となる。（文責：　寺井明日実） 5.4 umdecode 5.4.1　成果　このプログラムはsortcodeで判断され、出力されたコードの情報を読み込み、そのコードに調和する音を判別して振り分けるという処理を行う。このコードで判別された音がコントローラであるnanoPADのボタンに振り分けられるため、sortcodeと同じくHarmonic Fuzzyのアルゴリズム上で重要な役割を担っている。 5.4.2　仕様　開発環境はC++ である。sortcodeから出力された数値をインレットからumdecodeに読み込み、そのコードに調和する6つの音を判別してその情報をアウトレットから出力する。判別する部分はsortcodeと同様にif文を用いて処理を行っている。全体的にプログラムの構成はsortcodeと共通する点が多い。また、バグを修正するために演奏している最中に伴奏のコードが変化すると1を出力するという機能を追加した。 5.4.3　解決手順　インレットにsortcodeからコードの情報が送られてくるとその数値を読み込み、if文でそのコードに調和する音を判別し、それぞれ1つの音につき1つのアウトレットから出力する。当初は4つの調和する音を判別して振り分けていたが、ツールの開発途中でコントローラの全ボタンのうち上段の6つのボタンを演奏用に利用することになったため、アウトレットを6つに増やし、6つの調和する音を出力するようにした。対応している全21種類のコードのうち3音のコードと4音のコードで調和する音が同じになるという組み合わせが存在する。例えばCとCm7、DとDm7などのような組み合わせのことである。これらの組み合わせはumdecode上では同じコードとして扱う。これにより無駄な処理を行わずに済んだ。　開発途中で演奏中に音が止まらなくなるというバグが見つかった。コントローラのボタンを押っぱなしにしている間に伴奏のコードが変わると押していたボタンに振り分けられていた音が鳴り止まなくなるという現象である。このバグを修正するために1つ前のコードの値を保持し、調和する音の判断を始める前に前のコードと同じなら0、違うなら1を出力するという機能を追加した。調和する音が同じになるコードの組み合わせについては上記のように同じコードであるとして処理を行う。例えば1つ前のコードがCで次にCm7に変化してもコードは変化していないと見なし、アウトレットからは0が出力される。 5.4.4　評価　一部のコードの組み合わせを同じコードとして扱うことで判別の速度を上げることに成功した。しかし、sortcodeと同様に判別部分がif文で構成されているため対応するコードを増やすと動作が重くなってしまう可能性がある。このように大量のif文を使わないで判別するにはデータベースを読み込めるようにするという方法が挙げられる。　バグの修正のために追加したコードが変わったかどうかを判断する機能はバグを修正する上で役に立った。（文責：　寺井明日実）　5.5 Camail(ゆーき) 　　5.6.1　成果　前期成果物の問題点として、演奏している気分になりにくいことや自由度が低い音楽表現しか実現が出来ないことが挙げられた。今回のHarmonic Fuzzyではその問題点を受け、流れている伴奏に調和する音をユーザーが演奏することにより、オリジナルの音楽を演奏することを実現した。また、ボタンの数をある程度限定することにより、操作を簡易化した。実際の演奏と同じような操作を実現したことで演奏してる気分になれ、nanoPADに様々な音を割り振ることにより旋律の操作を可能にし、自由度の高い音楽表現を実現することが出来た。よって、従来の音楽表現に比べ、簡単な操作で自由度の高い音楽表現を実現した。　　5.6.2　仕様これは、あらかじめ用意したMIDIで作られた伴奏に対し不協和音にならないような音を判別し、それをnanoPADの各ボタンに割り当てるプログラムである。伴奏が再生されるとそれをリアルタイムで読み込み、その時の楽曲のコードによって不協和音にならない音を判別し、nanoPADに割り当てる。ユーザーはnanoPADのボタンを押すことによって演奏を行うことができ、どのように演奏を行ったとしても不協和音が発音されることはないため、演奏技術や経験がないユーザーでも簡単に使うことができる。また、演奏時のダイナミクスの操作や音色の変化、割り当て音のオクターブシフト機能を搭載した。　読み込むことのできる伴奏には、Cメジャースケール上の音のみで構成されていること、トラックの１と２にコードの構成音を配置する事といった制限を設けることとした。　　5.5.3　解決手順　まず、nanoPADのボタンによってどのような値が流れているのかを入力して調べる必要があった。ここで大切なこととすれば、出力された値をどのように振り分ければ良いかを研究することであった。いろいろなオブジェクトを探して、割り振るときにどれを使用すればうまくいくのかを試していたのだが、それにあったものが見当たらなかった。そこで見つけたのがselectオブジェクトであった。それを用いることにより、それぞれの値をそれに格納することができ、出力のされ方は格納した各々の値の分、出力の個数が決まるというものであった。また、メロディーラインと音の音色、高さを同じ場所で操作すると、だいぶプログラムのスペースが広がり、見栄えが悪くなるので、メロディーラインの部分をwariate内のオブジェクトに挿入することでそれを改善することが出来た。　　　5.5.4　評価　今回のプログラムの楽器の種類やメロディーラインの数はプレゼンテーション用に３つでしたが、本来はnanoPADのボタンの数からするともっと増やすことが出来る。しかし、プロジェクト全体のテーマは初心者でも簡単に音楽表現が出来るソフトウェアを製作することなので、あまりボタンの数を増やすと混乱するのではないかと考え、この設定にした。今回のプログラムで大変苦労した点は見栄えの悪さであった。inletやoutletを駆使してプログラムを構築していったのだが、なかなか思うように作業が進まなかった。他の人の協力もあって徐々に直していったので、だいぶ見栄えはよくなった。（文責：佐藤佑樹）　5.6 Harmonic Fuzzyプログラム部分（ファジ）　　5.6.1　成果　前期成果物の問題点として、演奏している気分になりにくいことや自由度が低い音楽表現しか実現が出来ないことが挙げられた。今回のHarmonic Fuzzyではその問題点を受け、流れている伴奏に調和する音をユーザーが演奏することにより、オリジナルの音楽を演奏することを実現した。また、ボタンの数をある程度限定することにより、操作を簡易化した。実際の演奏と同じような操作を実現したことで演奏してる気分になれ、nanoPADに様々な音を割り振ることにより旋律の操作を可能にし、自由度の高い音楽表現を実現することが出来た。よって、従来の音楽表現に比べ、簡単な操作で自由度の高い音楽表現を実現した。　　5.6.2　仕様これは、あらかじめ用意したMIDIで作られた伴奏に対し不協和音にならないような音を判別し、それをnanoPADの各ボタンに割り当てるプログラムである。伴奏が再生されるとそれをリアルタイムで読み込み、その時の楽曲のコードによって不協和音にならない音を判別し、nanoPADに割り当てる。ユーザーはnanoPADのボタンを押すことによって演奏を行うことができ、どのように演奏を行ったとしても不協和音が発音されることはないため、演奏技術や経験がないユーザーでも簡単に使うことができる。また、演奏時のダイナミクスの操作や音色の変化、割り当て音のオクターブシフト機能を搭載した。　読み込むことのできる伴奏には、Cメジャースケール上の音のみで構成されていること、トラックの１と２にコードの構成音を配置する事といった制限を設けることとした。　　5.6.3　解決手順 Harmonic Fuzzyを開発する上では、演奏難易度と自由度のバランスの設定、演奏音設定時の判別アルゴリズムの考案、ユーザーインターフェースの選択、演奏タイミングと判別タイミングの設定といった問題の解決が必要となった。　まず、演奏に関する自由度の高さと演奏の難易度のバランスをどの程度に設定するのかを決定することとした。演奏の難易度を低く設定するならば、その時の伴奏のコードの構成音だけをユーザーが演奏出来るようにすれば、でたらめに演奏してもメロディーとして成り立たせることができ、演奏技術によってメロディーの出来が左右されることが少ない。しかし、その場合演奏音がかなり限定されてしまうため、演奏技術が低くてもメロディーの完成度が高くなりやすい反面、どのユーザーが演奏しても同じようなメロディーになってしまいやすくなるという問題が発生する。そのため、コードの構成音以外にも演奏できる音を設定することとし、演奏時に不協和音になってしまう音であるアボイドノートを設定する音から取り除くことにより、演奏における高い自由度と低い難易度を維持することとした。　次に、どのようにしてその時その時の伴奏に対し調和する音を判別するのかのアルゴリズムを作成した。開発開始当初の案は、伴奏の音からその時のコードが何なのかを判別する事ができれば、調和する音を判別できるのではないかというものであった。しかし、伴奏に対しメロディーをつける時にはコードだけではなく、その楽曲のスケールが何スケールなのかを判別しなくては自然なメロディーをつけることが不可能であるということが分かった。 Harmonic Fuzzyでは、開発期間の関係上スケール判別アルゴリズムをプログラムに実装することが難しかったため、読み込む楽曲をCメジャースケールのもののみに限定することとして開発を行うこととした。　演奏時のユーザーインターフェースはKORG社のnano padを使用することとした。当初はMusic Fuzzyのために開発したロールコントローラーを使用する案があった。しかし、ロールコントローラーでは回転による操作になってしまうため、決まった順でしか演奏を行うことができないという問題があった。よって、ユーザーの意図したように演奏音の順番を決める事ができ、音の強弱もつけることの出来るようなユーザーインターフェースが必要となった。また、開発期間の短さからもユーザーインタフェースを自主開発することは難しいのではないかと考えられた。そこで、MIDIコントローラーの一つとして発売されており、音の強弱をたたく強さで感知することのできるKORG社のnano padをユーザーインターフェースとして採用することとなった。　また、判別のタイミングと演奏のタイミングをどうあわせるかといった問題を解決した。Harmonic Fuzzy上では、伴奏から調和する音がどんな音なのかを判別するときにはわずかな処理時間が発生してしまうため、コードが丁度変わる瞬間にユーザーが演奏を行おうとすると、前のコードの設定音が演奏されてしまうという問題が発生してしまう可能性があった。そのため、実際に演奏されている伴奏音よりもあらかじめ少し先に伴奏の判別を終えておくことによりこの問題を解決することとした。　　5.6.4　評価　高い自由度と低い演奏難易度を両立することができ、おおむね目標を達成することができたものの、いまだいくつかの問題点がある。　Music Fuzzyに比べると実際に演奏音をユーザーがある程度選択し、楽器に近い感覚での演奏を行うことが出来るようになっているため自由度は演奏時の自由度はかなり高くなっており、どの音を演奏しても伴奏に調和するように設定しているため、演奏時の難易度を低くすることも出来ている。実際に音楽経験のあるユーザー、ないユーザーともに何人かにHarmonic Fuzzyを実際に使って演奏を行ってもらったが、最初はそこまでうまく演奏できないものの、何度か演奏しているうちにすぐにある程度の演奏を行うことが出来るようになっていた。詳細なデータを実験によってとってはいないので判断が難しいところではあるが、初心者にも簡単に演奏を行うことができるようにすることが出来るようになっているのではないかと考えられる。最終発表会でも中間発表時のMusic Fuzzyと比較すると、評価は高くなっており様々なユーザーが楽しめるシステムとなっていることが分かった。　しかし、すべての楽曲に対応することができないこと、リズム感の無いユーザーにはいまだ若干敷居の高いシステムになってしまっていること、リアルタイムセッションにはシステムを流用することができないなどの課題が残った。Harmonic Fuzzyではスケール判別を行う機能が実装されていないため判別することのできる楽曲がCメジャースケールでなくてはいけないことや、楽曲の製作の際に様式を守っているものでなくてはならない等、読み込むことのできる楽曲にかなりの制限が生じてしまっている。また、演奏タイミングをユーザーに完全に任せてしまっていることから、リズム感が無いユーザーにとっては演奏が難しく感じてしまうことがある。リアルタイムに演奏している伴奏とHarmonic Fuzzyのシステムを使いセッションを行いたいと思っても、処理時間の問題や、演奏開始時では、スケールの判別を行うことが難しいなどの問題があり調和する音を判別することが難しくなってしまうという問題がある。　5.7 Harmonic Fuzzy　GUI部分（文責：田中）終　　5.7.1　成果　　前期成果物であるMusic FuzzyのGUIに関する問題点は、Max/MSP側で処理した音情報のパラメータをただ機械的に表示しているだけであり、エンターテインメント性も無く、ユーザが画面の情報から「自分が今演奏を行っている」と感じられなかった点である。この点解決する為に、画面上には実際に演奏した結果の情報以外にも、それに合わせた画面動作を置くことにより、ユーザが画面を見て、演奏を行っていると感じさせるよう試みた。またGUIではただ操作結果を出力すれば良いというわけではなく、分かりやすく表示するということはもちろん、その表示方法が効果的に目的とした感情を引き出せなくてはならない。その為、本作の Harmonic Fuzzyではユーザが画面を見て、演奏を行っていると感じさせる出力方法でなくてはならない。前期のMusic Fuzzyではこの点に関しては言及しなかった為、本作ではこの点に関して着手して制作を行い、画面の制作を行った。最終的にはこれらの要項を満たす、メニュー画面と実行画面、また操作の方法を説明したチュートリアル画面を制作した。　　5.7.2　仕様　　Harmonic FuzzyのGUIは前期の成果物であるMusic Fuzzyと同様に、Flashで製作を行った。基本原理も同様に、Flash内のムービークリップのフレーム操作によって場面の切り替えを行い、 Action Scriptによる制御でMax/MSP間との通信を行い音情報のパラメータを得た。本作ではただ数値を表示させるだけでなく、実際にユーザがどのような演奏を行ったのかを伝える為、画面内の楽譜上に音符を生成する形で実際の演奏状況をユーザに伝えるように作成した。また、ただ結果を表示させるだけでは機械的であると判断し、演奏した音によって画面上に変化を持たせる仕様にした。前期と同様メニュー画面を作成したが、この他の実行画面だけではメニュー画面の意味が無い。その為、実行画面やプログラムの使用を説明するチュートリアル画面や、プログラムを終了させる終了画面を作成し、メニュー画面に意味を持たせ、多機能性を出した。また実行画面ではMax/MSP側から情報を受け取るだけでなく、Flash側からMax/MSP側へ情報を送信し、楽曲の再生、停止を行えるようにした。　　5.7.3　解決手順　今回の制作物であるHarmonic Fuzzyにおいて、演奏によりエンターテインメント性を感じさせることは非常に重要である。なぜならば、今回の制作物Harmonic Fuzzyのコンセプトの一つに、初心者でも演奏を楽しむことできるというものがある。その為にユーザが演奏を行った際にユーザが、演奏ではなく操作をしている、または演奏でも非常に不可解であるなどと感じてしまってはコンセプトを達成することができないのである。その為に、画面上にエンターテインメント性を出すエフェクトを出力することで、ユーザに対しての視覚的にエンターテインメント性を出すことにした。その解決方法としては、画面上にユーザの反応を返すという方法を行った。具体的な処理のアルゴリズムは以下のようになる。Harmonic Fuzzyではまずユーザが演奏を行い、それに対して押されたnanoPADのボタンにより音の処理を行い、不協和音にならない音を出力するというものであった。その出力する音の情報をMax/MSP側から送られ、それを元にFlash上でフレーム操作を行うという方法で処理を行った。問題の出力方法に関してであるが、今回は2つの手法を用いた。まず一つ目は楽譜を表示させ、それの上に音符を生成するという方式である。まず実行画面上に音符も何も置かれていない状態の楽譜を生成する。そしてユーザがnanoPADを操作して音が出力されることで、そのMax/MSP側から送られてきた数値を元に出力すべき音符の種類及び位置を判別し、予め作成しておいた音符とそれの動作を複製し、制御通りの箇所に配置して音符を流すという使用である。これにより画面の楽譜上に、ユーザが演奏することによってその結果である音符が次々と生成されて流れていくというものになった。これにより、ユーザは演奏結果が楽譜という形でリアルタイムで出力される為に、ユーザはnanoPADの操作でも画面からの視覚情報によって、「演奏を行っている」という感情を誘発できると考え、これを作成した。　二つ目は演奏の結果によるエフェクトの変化である。Harmonic Fuzzyでは、操作を行ったタイミングやボタンによって出力される音の種類が変化する。その為、前述した音符の出力位置と同様、音の種類によって場合分けをして、エフェクトを変化させることができる。今回の制作物のHarmonic Fuzzyでは演奏である為、出来るだけ音楽に関連のあるエフェクトにしようと試みた。初期の段階では楽器の画像を作成し、それをユーザが演奏した音に合わせて動作するという方式であった。例えば、ピアノやギターなどの画像が画面上にあり、演奏することによってその楽器が音に合わせて動いたり、大きくなったり、音符を出したりするなどの演奏に対する結果の出力ではない反応を演出し、エンターテインメント性を出すという方式である。しかしながら、ただ楽器が画面上で変化するだけでは少々不足しているのではないかと考え、11月後半の時期に急遽エフェクトの仕様を変更した。最終的には、演奏を行っている人のムービクリップを作成し、それに対して音毎の変化を出した。具体的に説明すると、まず画面上には楽譜以外に楽器(今回ではフルート)を持った人物の画像があり、ユーザがnanoPAD によって演奏を行い、Max/MSPが処理した音の種類によって、それぞれ異なる指使いによって楽器を演奏するムービーを出すという形式である。これによって、画面上でもユーザの演奏結果をただ単純に表示するだけでなく、画面上でも演奏を行うことにより、ユーザを視覚情報から演奏をしている気分にさせるように試みた。この制御は基本他の箇所で行った制御であるフレーム操作を使用していて、if文による場合分けにより作成した指の表示を変えて場面変えを行っているだけである。　また、実行画面以外に作成したメニュー画面についても少し述べる。メニュー画面では3つの項目があり、ユーザが現在どの項目を選んでいるのかが判別できるなくてはならないので、テロップを流したり、ボタンに変化をつけたりといった工夫を入れた。なたこれはメニュー画面だけでなく実行画面に関しても該当する箇所があるが、操作の方法として今回はインターフェースの機器(今回はnanoPAD)での操作はあくまで演奏の箇所だけであり、それ以外の操作はマウスによって行う処理にした。その為、Action Scriptにてマウスからの操作に対応して場面の切り替えを行わせるようにした。またFlashからMax/MSPへの情報送信や逆側からの情報の受け取りに関しても、前期の制作物であるMusic Fuzzyと同様、該当する箇所をAction Scriptで制御するという方法を取り解決を行った。　　5.7.4　評価　　ユーザの演奏結果を画面上に出力することによって、ユーザに結果を視覚的に伝えた為、またその方法が数値などによる直接的な方式ではなく、楽譜や演奏している状況などの音楽に関連した方式によるものであった為、画面開発の当初の目的でもあった「ユーザに演奏を行っている気分にさせる出力」を行うことができた。また前期の制作物であるMusic FuzzyではただMax/MSP側からの出力結果を表示するだけであったが、本作では画面の場面展開の制御をそろえたり、また全画面で表示されるためプログラム終了の項目を入れたりなど、結果の出力以外の箇所の向上も行った。しかしながらいくつかの問題点もあるのも事実ではある。例えば、メニュー画面と実行画面との統一性が薄いという点である。11月下旬に出力画面のデザインの仕様変更があった為に、メニュー画面の修正が間に合わず、メニュー画面の箇所が旧デザインとなり、新デザインの方も旧デザインに合わせて作成は行ったが、若干のズレが生じてしまった。また、出力画面の構成に関しても問題が存在している。現在Harmonic Fuzzyの実行画面は楽譜が画面上部にあり、演奏に合わせて動作する人物のオブジェクトが中央にあるという形式であった。演奏中にユーザが見ていた箇所は、主に楽譜の箇所であり、人物が演奏を行っているムービーの箇所は位置の関係上あまり集中して見られなかったというもの問題である。そもそもこの人物の動作は指にしか変化が無いため、動きの変化が多少分かり難くなってしまっている。これらの点は単純にクオリティが多少低いという問題点ではあるが、エンターテインメント性をより引き出す為には、これらの問題点を解決するクオリティの向上が必要になっているのも事実である。　5.a　HarmonicFazzyを使用した実演技術の習得　　//こんなん増やしてもよろしいですか？いろいろ突っ込んで頂けるとありがたいです(飯田)// 　　5.a.1　成果　最終成果発表会において、傍聴者に対して実演を行うことは、HarmonicFazzyの利点などを伝えることのできる手段のなかで、最も効率的な方法のひとつである。しかし、まずは実演する我々がわかりやすい実演の方法を身につけなければ、この最終成果物の目的である、楽器の演奏経験や音楽に対する知識を持たないユーザーでも、簡単に、かつ自由度の高い音楽表現を支援するということを伝えることができない。そのため、ある程度実演の方法を固定し、だれでも簡単に実演できるような方法を考案することで、以上の問題を解決できるのではないかと考え、このテーマを設定した。　　5.a.2　仕様　具体的には、再生されている曲のコード進行に合わせて、どの部分でどんな音色を使えばよいか、また、それに合わせてどのような演奏を心がければよいかを明記した、いわば実演方法のマニュアルのようなものである。今回のHarmonicFazzyでは、3種類の音色と、3段階の音程をユーザーの好みによって使い分けすることができる。そのため、それらの機能も利用した実演をできるようにならなければいけない。そこで、まずは今回の最終成果発表会で使用する楽曲全体を３つのパートに区切って考え、それぞれのパートごとに3種類の音色をそれぞれ振り分けた。そして各パートごとに使用する音色に合わせて演奏方法を変化させることで、閲覧者の受け取る印象が大きく変わることを記載した。　　5.a.3　解決手順　前記したとおり、曲全体を3つのパートで構成されていると考える。そしてそれぞれのパートに異なる3種類の音色を設定した。　まず序盤部分ではピアノの音を使用した。数ある楽器の中で、もっともポピュラーであり、さまざまな楽曲に使用されている。そのため、どんな楽曲にもなじみやすく、そしていろんな演奏体系にも対応させやすいため、この音色を今回の最終成果発表会で使用する楽曲の序盤に配置することとした。またメロディをつける際は、単音を中心として、連続的なメロディをつけるように心がけることによって、よりピアノらしい演奏を可能とすることができた。　中間部分では、木琴のような音を使用した。序盤で使用したピアノの音よりもサスティンが短く、一音一音がしっかりとした音色が特徴であるため、ピアノのときよりも一音一音がはっきりとしたメロディをつけるようにした。また、音数を多めにしながら単音と和音を織り交ぜて、軽やかな演奏を心がけて使用することにより、スタッカートの効いたメロディをつけやすく、ピアノの音との違いを明確にすることができた。　終盤部分では、バイオリンのような音色を使用した。ピアノや木琴のような音色よりも、アタックが弱く、やわらかで伸びのある音なので、この音色を採用した。演奏するにあたっては、音数を少なくして、ゆっくりと長い音を奏でていくこととした。これにより、静かでゆったりとしたメロディを奏でることができ、他の音色との差をつけることが可能となった。　以上のように、ボタンを押してから離すまでの音の長さなどの特徴がが大きく異なる3種類の音色を設定することにより、様々な演奏方法が可能であるということをわかりやすく伝えることができるようになった。また、どれもオーケストラやポップスなどでも広く使用されいてるような音色であることから、どんな楽曲にも違和感なくメロディを乗せることが可能となった。さらにユーザーからの視点に立ったとき、ピアノや木琴を実際に演奏する際には、鍵盤が左から右へと音程が高くなっていく。今回のHarmonicFazzyでも同じように左から右へと音程が高くなるように音が割り振られているので、既存の音楽表現にならって直感的な操作が可能となった。また、普段親しみがなく鍵盤楽器でないバイオリンのような楽器も、そのような直感的な操作のおかげで、鍵盤と同じような演奏ができるため、より親しみを持てるようになった。　　5.a.4　評価　最終発表会にて上記のことを意識しながら実演を行ったところ、閲覧者が発表終了後に記載する評価シートに「実演がわかりやすかった」などのフィードバックを多数いただくことができた。これは、今回の考察が成功したものと考えることができる。しかし、ある教授から「実演が慣れすぎているのではないか」との指摘もあり、今回のHarmonicFazzyの目的のひとつである、誰にでも簡単に演奏できる、という意図が少し伝わりにくかったように思われる。弾く人、聞く人の主観の問題もあるため、ある程度は仕方ないかもしれない。しかし、その場で参加を募って実際に演奏してもらうなどの解決策もあったため、誰にでも簡単に演奏できるという意図をどう伝えるかが課題として残ってしまった。 (文責：飯田) 　5.8 中間発表会（ゆっこ）終わーり　　5.8.1　成果　中間発表会のために、展示用のポスターとプレゼンテーション用のスライド、メンバー全員のプロジェクトTシャツを作成した。以下に図すうじ　で今回のポスターを示す。また、このほかにプレゼンテーションの練習、Music Fuzzyの実演の練習なども行った。　　　　　　　　　「がぞう」　　　　　　　　　図すうじ　中間発表会用ポスター　　5.8.2　解決手順解決手順　ポスターを作成するにあたり、読む人にわかりやすいように文章はなるべく簡潔に少なめにし、図や写真を多く取り入れた。　スライドも情報量が多くなりすぎないように、重要なところにポイントをしぼり、なおかつ発表の順序をどうしたら聞き手にわかりやすいかを考えた上で作成した。プレゼンテーションではMusic Fuzzyの概要を説明したあとに、実際の動作の様子を実演で披露することにした。そのため発表の練習は、まずプレゼンテーションの練習をするメンバーと実演の練習をするメンバーに分かれて行った。　プレゼンテーションの練習をするにおいて、台本などを作ってしまうと棒読みのようになってしまいがちなので、それを防いでより自然なプレゼンテーションを行うために、台本の　作成は一切行わなかった。簡潔な内容のスライドの説明をうまくできているか、また、声の調子や大きさ、スピードが聞き手にわかりやすいものになるよう全員で発表の練習を見せ合い、お互い注意し合いながら練習を行った。質疑応答にも柔軟な対応が出来るように、全員で考えられる質問をし合っていった。　実演の練習をするにおいては、実演の際に使用する音源「愛の夢」を何度も繰り返し聞き、ピアノ版の楽譜を用意し、この曲のテンポやダイナミクスに関する情報をよく理解した。そして、テンポや曲のどの場面でテンポまたはダイナミクスを操作すればより効果的に聞かせることが出来るのかを重点に置いて練習をした。　また、メンバー全員の統一感を持たせるためと、他のプロジェクトとの差別化をはかるために、プロジェクトTシャツを用意した。自由な音楽をテーマとし、楽しくかつ個性を尊重したプロジェクトであるという雰囲気を出せるように、メンバー全員ひとりひとりのTシャツの色を変え、柄は無地で統一した。　　5.8.3　評価　ポスターやスライド、個々の出来としては良かったのだが、全体に統一感がなかったので、最終発表では全体の統一感を考えつつ、発表の準備をしていきたい。プレゼンテーションも一部の人だけがするのではなく、全員がしたほうがメンバー全員のプレゼンテーション能力や理解度の向上に繋がると考えた。　また、実演を行うため室内での発表になるため、発表場所がわからなかったという声もあったので、発表場所を示した貼り紙などをすると、もっとたくさんの方が発表をみに来て下さるのではないかと考えた。　5.9 成果発表会（ゆっこ）終　　5.9.1　成果　最終発表会のために、展示用のポスター、プレゼンテーション用のスライド、入り口に設置するプロジェクト紹介のためのスライド、道案内用の張り紙などを作成した。以下に図すうじ　で今回のポスターを示す。また、中間発表会のときの評価シートを参考にしたうえで、プレゼンテーションの練習、実演の練習なども行った。　これらの準備を計画的にしておいたため、室内で人の集まりにくい場所での発表ではあったが、たくさんの方に発表を見に来ていただくことができた。　　　　　　　「がぞう」「がぞう」　　　　　　図すうじ　最終発表会用ポスター　　5.9.2　解決手順　中間発表ではプレゼンテーションを行うメンバーと実演を行うメンバーに分かれて発表を行ったが、全員のプレゼンテーション能力とプロジェクト学習に関する理解度の向上のために全員が１回ずつでもプレゼンテーションを行ったほうが良いと考えた。そのため今回は、理論班に実演の練習を事前にしてもらい、プレゼンテーションの練習は全員で行った。ひとりひとり練習を行ったため時間を要したが、全員が人前で発表するという経験ができたので良かった。　ポスターは中間発表と同じデザインで作成した。中間発表の際と同様に、文章は簡潔なものにした。そして今回は理論の面などで、口頭での説明では難しい点があったため、出来るだけわかりやすい図で表現した。　プレゼンテーション用のスライドは、この一年間の過程がわかるように、本プロジェクトの目的、前期の成果、反省点、後期の目標、後期の成果が明確になるように順序立てて作成した。　また、成果物Harmonic Fuzzyのシンボルマークを作成したので、これをプレゼンテーション用のスライドや、Tシャツのロゴ等に使用することにより全体に統一感が出来た。　室内での発表のため、外から見ただけでは本プロジェクトの発表がわかりずらいという意見が中間発表会の際にでていた。たくさんの方に発表を見に来ていただきたいので、外から見ても発表を行っているということがわかるように、また、少しでも入りやすい雰囲気になるよう、発表を行う教室の前にプロジェクターを設置し、プロジェクトメンバーの写真や本プロジェクトのキャッチコピー等をスライドにして投影した。本プロジェクト名と発表する教室の場所を記載した貼り紙も作成し、教室の入り口に掲示した。　　5.9.3　評価　発表準備はメンバー全員が協力し、中間発表会の経験も生かしてスムーズに作業することが出来ていた。教室内に入りやすいように入り口に工夫をしたので、教室の後ろに立ち見の方が出るほど、予想以上にたくさんの方々に発表を見ていただくことが出来た。　アンケートの内容によると、実演がすごく好評であった。プレゼンテーションは全員が行ったため、厳しい評価もあったが全員がプレゼンテーションの経験が出来たので良かったと思う。ポスターは中間発表の際とほぼ同じデザインで作成し、文章の量や画像・写真の量は適切だったが、今回はシンボルマークも作成し、全体の統一感という点ではもう少しデザインを変えるべきだった。　全体を通して具体的な成果物ができ、たくさんの方に本プロジェクトを知っていただき、おもしろいプロジェクトの内容であったと評価をしていただくことが出来たので、発表会の目的は達成出来た。 2010-01-07T17:37:05+09:00 最終報告書　第5章 http://www23.atwiki.jp/musicprog16/pages/31.html 5章が容量オーバーになってしまったのでテキストモードで新たに作成しました。 [[5章]] 第5章　結果　5.15.MIDIを制御するプログラム 5.1.1　成果　これはMIDIを用いて製作された楽曲の再生、及びその楽曲のテンポ、ダイナミクス、ピッチをユーザがリアルタイムに操作し、変化させる事のできるソフトウェアである。ユーザが楽曲の不連続感や不自然さを感じずに操作できることを目標として製作された。 5.1.2　仕様　このプログラムはあらかじめ用意されたMIDIファイルを読み込んで再生を行い、再生されているMIDIファイルのテンポ、ダイナミクス、ピッチをリアルタイムに操作、変化させることができる。開発環境はMAX/MSPを使用した。パラメータの操作を行う際は、MIDIデータに設定されている楽器ごとの操作ではなく、一度に全ての楽器に対し各パラメータの操作を行う。実際の操作はMAX/MSPの画面上から行う形をとった。 5.1.3　解決手順　まず、ダイナミクスの操作の方法について考えることとした。当初は各音の打鍵の強さを表すパラメータであるベロシティの値を操作する事により、ダイナミクスの表現を行うこととした。しかし、ベロシティは音が鳴っている間に変化することを想定していないパラメータであるために、リアルタイムで操作を行った際に本来のそれぞれの音の長さで止まらなくなってしまうという問題が発生した。そこで、実際にリアルタイム操作を想定したパラメータである、エクスプレッションを操作する事によってダイナミクスの表現を行う形をとった。テンポに関しても同様にしてリアルタイム操作を想定したパラメータであるピッチベンドを操作する事によりピッチの変化を表現する事とした。　テンポの操作に関しては、再生時に元々MIDIデータに記録されているテンポ情報を無視してMAX/MSP 上からの操作ができる様に命令を付加することにより、実現できることが昨年のプロジェクトで判明していたため、それを流用することとした。　楽器ごとのパラメータ操作をできる様にも一度実装はおこなってみたが、MIDIデータを製作する段階である程度の設定を行わなくてはならないという問題が発生したため、最終的には全ての楽器を同時に操作する様に実装を行うこととした。 5.1.4　評価　このプログラムによって楽曲の不連続感や再生時の不具合なく、スムーズな操作を実現する事ができている。しかし、楽曲再生を行う際に簡単な設定を毎回行わなくてはいけないという問題点や、各楽器ごとのパラメータ操作の実装に関しては多少の問題を抱えてしまう結果となったため、今後解決策を考えていかなければならない。また、完成された楽曲全体のピッチをシームレスに操作してしまうと、楽曲が不自然に聞こえてしまうということが判明した。 5.3　MAX/MSP-FLASH間通信 5.3.1　成果　MIDI や音に関する処理を行っているMAX/MSP とGUI であるFlash 間の通信を実現している。 MAX/MSP とflash双方で送信と受信を行うことが可能である。 5.3.2　仕様　Flash とMAX/MSP間でXML ソケットを用いた通信を実現する事を目的とし、Olaf Matthes 氏が製作した flashserver というMAX/MSP上で使用する事のできるコンポーネントを用いて実装する形をとった。0.05秒に 1度、3つの数値をFlash側に送信し、表示している画面の位置をFlashからMAX/MSPに送信する形をとった。 5.3.3　解決手順　昨年度のプロジェクトでも同じ様にflaseserverを用いたXML ソケット通信を行っていたため、それを参考にして実際の製作を行った。しかし、前述したMAX間通信を行っている際、MAX/MSP-Flash間で送受信を同時に行ってしまうと、処理が重い事が原因でMAX/MSP側のソフトウェアが落ちてしまうという問題が発生した。そのため、flashserverで送信と受信が同時に行うことがないように、また当初0.01秒に一度のデータ送信を行うように設定していたが、0.05秒に一度に頻度を下げるよう実装を行うことによりこの問題を回避することに成功した。 5.3.4　評価　MAX/MSPで計算したデータのFlashへの送信に関してほぼ実現する事ができた。今後のMAX/MSPや Flashを利用したソフトウェアの製作に役立てていくことができるだろう。しかしながら、頻度の高い送信や、送受信を同時に行うことができない等の問題をfalshserverが抱えており、今後送信するデータの増加も考えられるため、もっと負荷の軽い通信方法を考えていかなければならない。 5.4 pro16wii 5.4.1　成果　このプログラムは、wii リモコンの各センサの値をMAX/MSP上でとるためのMAX/MSPのエクスターナルとして製作された。かなり速く操作を行った場合でも、停止することなく値をMAX/MSPに渡すことができる様になっている。 5.4.2　仕様　開発環境はC++を使用している。gl.tter氏が中心となって開発されたwiiyourself というライブラリを元にして開発を行った。wiiリモコンの3軸加速度センサの値や重力加速度の値を用いて算出されるロールやピッチといった動きの値、またボタンの入力等をMAX/MSP上でとることができる。pro16wii単体での動作はできる様にはなっておらず、MAX/MSP上での設定をする事により利用することができる。 5.4.3　解決手順　昨年のプロジェクトでもwii リモコンを利用していたため、昨年開発したpro10wiiを元にして開発を行った。当初はpro10wii をそのまま流用してソフトウェア開発を行っていく予定だったが、wii リモコンを速く動かしすぎるとロールやピッチの値をしばらく取ることができなくなる、というバグが存在していたため、その修正をすることとなった。　まず、wiiyourself内でどのような計算をしているのかを実際にwiiyourself のライブラリ内を読んで行くことにより理解する事とした。その結果、ライブラリ内で行っている計算の中にロールやピッチの値をとるだけならば無駄となってしまう部分があったため、実際のロールやピッチの値を出すための計算をライブラリ内ではなく、実行するプログラム内で行い計算を簡略化する事によりこの問題を解決する事とした。その結果、どんなに速くwiiリモコンを動かしても値がとまることなく取れるようにする事ができた。 5.4.4　評価　昨年度製作したpro10wii よりも動作が高速で正確な値をとることができる様になっている。しかし、加速度センサを利用しているため、ユーザが本来示したい値をとるまでに、その値の位置に持っていくまでの動かす速度によっては若干のずれが生じてしまうという問題は加速度センサ単体を使っている限りは避けることができない。よって今後もwii リモコンを使ってロールやピッチといった動きで値をとるならば、ジャイロセンサ等を用いた値の修正を行っていかなくてはならない。また、wiiyourself内では本来重力加速度の値を最大１して算出しなくてはいけないが、ごくまれに1.05という値が算出されてしまうため、ロールの計算がある角度でうまくいかず間違った値が算出されるというバグがいまだ残っているため、wiiyourselfそのもののデバッグをさらに行う必要がある。 5.2 ロールコントローラー（下村）終　　　5.2.1　成果　より楽器を演奏している気分に近づけるために、オーケストラの指揮者が指揮棒を振る動きをイメージしてロールコントローラー（図すうじ）というものを作成した。ロールコントローラーの軸部分にWiiリモコンを固定することによって、三軸加速度センサーを利用したロール操作のぶれがなくなり、安定したラジアン（角度）値を取ることができるようになった。操作方法も、取っ手部分を回すのみなので、従来のWiiリモコンのロール操作よりも簡易化することができた。よって、初心者でも簡単に操作することができる。　　　　　　　　　　　　「がぞう」　　　　　　図.すうじ　ロールコントローラー　　　5.2.2　仕様　木製の円盤２枚の軸部分にWiiリモコンが入る大きさの箱を取り付け、ネジで固定した。片方の円盤部分にユーザーが操作する取っ手部分を取り付けた。　今回は１台のWiiリモコンに１つのパラメーターを割り当てるプログラム仕様であり、操作対象となるパラメーターがダイナミクスとテンポなので、計２台のロールコントローラーを作成した。ユーザーが取っ手部分を回すことにより、テンポとダイナミクスを操作することができる。時計で例えると、１２時の位置の値が基準になるようにWiiリモコンを固定している。そこから時計まわり（ユーザーに対して右方向）へ回転させるとダイナミクスは大きくなり、テンポは速くなる。反時計まわり（ユーザーに対して左方向）へ回転させるとダイナミクスは小さくなり、テンポは遅くになるようになっている。　非常にシンプルな操作方法であり、軸部分にしっかりとWiiリモコンが固定されているため、かなり安定したラジアン（角度）の値を検出できている。よって、初心者の方にも使いやすく、音楽経験者の方はかなり細かい操作も可能である。　　　　　　　　　5.2.3　解決手順　まずはじめに、音楽を表現している気分になる動きは、どのような動きなのかを考えた。ギターやピアノなどの楽器を弾く動き、ダンスを踊る動き、指揮棒を振る動きなどがあげられ、この中でWiiリモコンのロールの動きをうまく変換できるものとして指揮棒を振る動きを選んだ。一般的に指揮者が２拍子や３拍子、４拍子を振る動きは、感情のこもり方や曲調によって、また指揮をする人によってもかなり動きに違いがでてくるものである。そのため、２拍子の指揮の振り方を横にしたような感じで、左右に弧を描く腕の振り方に操作方法を限定して、その動きにロール操作から変換させようということにした。　次に、インタフェースの具体的な形を決めるために、１００円ショップ等でフリスビーやワイヤーなど使えそうなものを買ってきて、簡易版のコントローラーを作成した。そこから具体的な形を導いた結果、円盤を２枚設置し、その２つの間の軸の部分にWiiリモコンを固定することによって、Wiiリモコンのローの動きを先ほど述べたような指揮棒を振る動きに変換可能であると考えた。また、卓上で操作することも仮定し、ワイヤーだけでパーツ同士を固定するのではなく、しっかりとした土台が必要であることもわかった。　これらをふまえて実際のコントローラーの設計を決めた。材料は加工が自分たちでしやすいように木材を使用することにした。木材と木材を繋げる部分には金属のネジ、土台とコントローラーを固定する部分には、家具を固定する際に使用するL字の金具を使用した。Wiiリモコンのロール操作を指揮棒を振る動きに変換することから、この装置をロールコントローラーと名付けた。　　　5.2.4　評価　ロールコントローラーの使用によって、作成したソフトウェアに対し、Wiiリモコンが送るラジアン（角度）の値をかなり正確にとることが結果よりわかったので、外付けのコントローラーとしては役割を果たしていたといえるだろう。しかし、操作方法においては中間発表のアンケートの結果、あまり演奏している気分になれないといった感想が多かった。Wiiリモコンがとっていた値はロールによるラジアン（角度）の値であり、加速度をとっているのではないため、実際の操作方法は指揮者のようにリズムをとるような動きを再現出来ていなかった。CDコンポなどのボリュームを調整する操作とさほど変わらないのではないかといった声もあったため、後期に向けての改善点の一つとして、演奏に近い操作を可能にするインタフェースを研究、開発するという目標ができた。　5.3 Sortcode（寺井）　　5.3.1　成果　　5.3.2　仕様　　5.3.3　解決手順　　5.3.4　評価　5.4 Umdecode 　　5.4.1　成果　　5.4.2　仕様　　5.4.3　解決手順　　5.4.4　評価　5.5 Camail(ゆーき) 　　5.5.1　成果　　　　　　　これはMAX/MSPのプログラムで作製したパッチの名前である。このパッチはnanoPADのボタンにそれぞれオクターボ　　　　　　　シフトと楽器選択を機能させるために作成した。これにより、音の高さや音色の変化を自由に操作することができた。　　5.5.2　仕様　　　　　　　nanoPADのボタンを押したときに出力された値をそれぞれselectのオブジェクトで割り振り、それぞれの値を足算を使　　　　　　　って、目的のMIDI音源に接続していった。また、　　5.5.3　解決手順　　5.5.4　評価　5.6 Harmonic Fuzzyプログラム部分（ファジ）　　5.6.1　成果　前期成果物の問題点として、演奏している気分になりにくいことや自由度が低い音楽表現しか実現が出来ないことが挙げられた。今回のHarmonic Fuzzyではその問題点を受け、流れている伴奏に調和する音をユーザーが演奏することにより、オリジナルの音楽を演奏することを実現した。また、ボタンの数をある程度限定することにより、操作を簡易化した。実際の演奏と同じような操作を実現したことで演奏してる気分になれ、nanoPADに様々な音を割り振ることにより旋律の操作を可能にし、自由度の高い音楽表現を実現することが出来た。よって、従来の音楽表現に比べ、簡単な操作で自由度の高い音楽表現を実現した。　　5.6.2　仕様これは、あらかじめ用意したMIDIで作られた伴奏に対し不協和音にならないような音を判別し、それをnanoPADの各ボタンに割り当てるプログラムである。伴奏が再生されるとそれをリアルタイムで読み込み、その時の楽曲のコードによって不協和音にならない音を判別し、nanoPADに割り当てる。ユーザーはnanoPADのボタンを押すことによって演奏を行うことができ、どのように演奏を行ったとしても不協和音が発音されることはないため、演奏技術や経験がないユーザーでも簡単に使うことができる。また、演奏時のダイナミクスの操作や音色の変化、割り当て音のオクターブシフト機能を搭載した。　読み込むことのできる伴奏には、Cメジャースケール上の音のみで構成されていること、トラックの１と２にコードの構成音を配置する事といった制限を設けることとした。　　5.6.3　解決手順 Harmonic Fuzzyを開発する上では、演奏難易度と自由度のバランスの設定、演奏音設定時の判別アルゴリズムの考案、ユーザーインターフェースの選択、演奏タイミングと判別タイミングの設定といった問題の解決が必要となった。　まず、演奏に関する自由度の高さと演奏の難易度のバランスをどの程度に設定するのかを決定することとした。演奏の難易度を低く設定するならば、その時の伴奏のコードの構成音だけをユーザーが演奏出来るようにすれば、でたらめに演奏してもメロディーとして成り立たせることができ、演奏技術によってメロディーの出来が左右されることが少ない。しかし、その場合演奏音がかなり限定されてしまうため、演奏技術が低くてもメロディーの完成度が高くなりやすい反面、どのユーザーが演奏しても同じようなメロディーになってしまいやすくなるという問題が発生する。そのため、コードの構成音以外にも演奏できる音を設定することとし、演奏時に不協和音になってしまう音であるアボイドノートを設定する音から取り除くことにより、演奏における高い自由度と低い難易度を維持することとした。　次に、どのようにしてその時その時の伴奏に対し調和する音を判別するのかのアルゴリズムを作成した。開発開始当初の案は、伴奏の音からその時のコードが何なのかを判別する事ができれば、調和する音を判別できるのではないかというものであった。しかし、伴奏に対しメロディーをつける時にはコードだけではなく、その楽曲のスケールが何スケールなのかを判別しなくては自然なメロディーをつけることが不可能であるということが分かった。Harmonic Fuzzyでは、開発期間の関係上スケール判別アルゴリズムをプログラムに実装することが難しかったため、読み込む楽曲をCメジャースケールのもののみに限定することとして開発を行うこととした。　演奏時のユーザーインターフェースはKORG社のnano padを使用することとした。当初はMusic Fuzzyのために開発したロールコントローラーを使用する案があった。しかし、ロールコントローラーでは回転による操作になってしまうため、決まった順でしか演奏を行うことができないという問題があった。よって、ユーザーの意図したように演奏音の順番を決める事ができ、音の強弱もつけることの出来るようなユーザーインターフェースが必要となった。また、開発期間の短さからもユーザーインタフェースを自主開発することは難しいのではないかと考えられた。そこで、MIDIコントローラーの一つとして発売されており、音の強弱をたたく強さで感知することのできるKORG社のnano padをユーザーインターフェースとして採用することとなった。　また、判別のタイミングと演奏のタイミングをどうあわせるかといった問題を解決した。Harmonic Fuzzy上では、伴奏から調和する音がどんな音なのかを判別するときにはわずかな処理時間が発生してしまうため、コードが丁度変わる瞬間にユーザーが演奏を行おうとすると、前のコードの設定音が演奏されてしまうという問題が発生してしまう可能性があった。そのため、実際に演奏されている伴奏音よりもあらかじめ少し先に伴奏の判別を終えておくことによりこの問題を解決することとした。　　5.6.4　評価　高い自由度と低い演奏難易度を両立することができ、おおむね目標を達成することができたものの、いまだいくつかの問題点がある。　Music Fuzzyに比べると実際に演奏音をユーザーがある程度選択し、楽器に近い感覚での演奏を行うことが出来るようになっているため自由度は演奏時の自由度はかなり高くなっており、どの音を演奏しても伴奏に調和するように設定しているため、演奏時の難易度を低くすることも出来ている。実際に音楽経験のあるユーザー、ないユーザーともに何人かにHarmonic Fuzzyを実際に使って演奏を行ってもらったが、最初はそこまでうまく演奏できないものの、何度か演奏しているうちにすぐにある程度の演奏を行うことが出来るようになっていた。詳細なデータを実験によってとってはいないので判断が難しいところではあるが、初心者にも簡単に演奏を行うことができるようにすることが出来るようになっているのではないかと考えられる。最終発表会でも中間発表時のMusic Fuzzyと比較すると、評価は高くなっており様々なユーザーが楽しめるシステムとなっていることが分かった。　しかし、すべての楽曲に対応することができないこと、リズム感の無いユーザーにはいまだ若干敷居の高いシステムになってしまっていること、リアルタイムセッションにはシステムを流用することができないなどの課題が残った。Harmonic Fuzzyではスケール判別を行う機能が実装されていないため判別することのできる楽曲がCメジャースケールでなくてはいけないことや、楽曲の製作の際に様式を守っているものでなくてはならない等、読み込むことのできる楽曲にかなりの制限が生じてしまっている。また、演奏タイミングをユーザーに完全に任せてしまっていることから、リズム感が無いユーザーにとっては演奏が難しく感じてしまうことがある。リアルタイムに演奏している伴奏とHarmonic Fuzzyのシステムを使いセッションを行いたいと思っても、処理時間の問題や、演奏開始時では、スケールの判別を行うことが難しいなどの問題があり調和する音を判別することが難しくなってしまうという問題がある。　5.7 Harmonic Fuzzy　GUI部分（文責：田中）終　　5.7.1　成果　　前期成果物であるMusic FuzzyのGUIに関する問題点は、Max/MSP側で処理した音情報のパラメータをただ機械的に表示しているだけであり、エンターテインメント性も無く、ユーザが画面の情報から「自分が今演奏を行っている」と感じられなかった点である。この点解決する為に、画面上には実際に演奏した結果の情報以外にも、それに合わせた画面動作を置くことにより、ユーザが画面を見て、演奏を行っていると感じさせるよう試みた。またGUIではただ操作結果を出力すれば良いというわけではなく、分かりやすく表示するということはもちろん、その表示方法が効果的に目的とした感情を引き出せなくてはならない。その為、本作のHarmonic Fuzzyではユーザが画面を見て、演奏を行っていると感じさせる出力方法でなくてはならない。前期のMusic Fuzzyではこの点に関しては言及しなかった為、本作ではこの点に関して着手して制作を行い、画面の制作を行った。最終的にはこれらの要項を満たす、メニュー画面と実行画面、また操作の方法を説明したチュートリアル画面を制作した。　　5.7.2　仕様　　Harmonic FuzzyのGUIは前期の成果物であるMusic Fuzzyと同様に、Flashで製作を行った。基本原理も同様に、Flash内のムービークリップのフレーム操作によって場面の切り替えを行い、Action Scriptによる制御でMax/MSP間との通信を行い音情報のパラメータを得た。本作ではただ数値を表示させるだけでなく、実際にユーザがどのような演奏を行ったのかを伝える為、画面内の楽譜上に音符を生成する形で実際の演奏状況をユーザに伝えるように作成した。また、ただ結果を表示させるだけでは機械的であると判断し、演奏した音によって画面上に変化を持たせる仕様にした。前期と同様メニュー画面を作成したが、この他の実行画面だけではメニュー画面の意味が無い。その為、実行画面やプログラムの使用を説明するチュートリアル画面や、プログラムを終了させる終了画面を作成し、メニュー画面に意味を持たせ、多機能性を出した。また実行画面ではMax/MSP側から情報を受け取るだけでなく、Flash側からMax/MSP側へ情報を送信し、楽曲の再生、停止を行えるようにした。　　5.7.3　解決手順　今回の制作物であるHarmonic Fuzzyにおいて、演奏によりエンターテインメント性を感じさせることは非常に重要である。なぜならば、今回の制作物Harmonic Fuzzyのコンセプトの一つに、初心者でも演奏を楽しむことできるというものがある。その為にユーザが演奏を行った際にユーザが、演奏ではなく操作をしている、または演奏でも非常に不可解であるなどと感じてしまってはコンセプトを達成することができないのである。その為に、画面上にエンターテインメント性を出すエフェクトを出力することで、ユーザに対しての視覚的にエンターテインメント性を出すことにした。その解決方法としては、画面上にユーザの反応を返すという方法を行った。具体的な処理のアルゴリズムは以下のようになる。Harmonic Fuzzyではまずユーザが演奏を行い、それに対して押されたnanoPADのボタンにより音の処理を行い、不協和音にならない音を出力するというものであった。その出力する音の情報をMax/MSP側から送られ、それを元にFlash上でフレーム操作を行うという方法で処理を行った。問題の出力方法に関してであるが、今回は2つの手法を用いた。まず一つ目は楽譜を表示させ、それの上に音符を生成するという方式である。まず実行画面上に音符も何も置かれていない状態の楽譜を生成する。そしてユーザがnanoPADを操作して音が出力されることで、そのMax/MSP側から送られてきた数値を元に出力すべき音符の種類及び位置を判別し、予め作成しておいた音符とそれの動作を複製し、制御通りの箇所に配置して音符を流すという使用である。これにより画面の楽譜上に、ユーザが演奏することによってその結果である音符が次々と生成されて流れていくというものになった。これにより、ユーザは演奏結果が楽譜という形でリアルタイムで出力される為に、ユーザはnanoPADの操作でも画面からの視覚情報によって、「演奏を行っている」という感情を誘発できると考え、これを作成した。　二つ目は演奏の結果によるエフェクトの変化である。Harmonic Fuzzyでは、操作を行ったタイミングやボタンによって出力される音の種類が変化する。その為、前述した音符の出力位置と同様、音の種類によって場合分けをして、エフェクトを変化させることができる。今回の制作物のHarmonic Fuzzyでは演奏である為、出来るだけ音楽に関連のあるエフェクトにしようと試みた。初期の段階では楽器の画像を作成し、それをユーザが演奏した音に合わせて動作するという方式であった。例えば、ピアノやギターなどの画像が画面上にあり、演奏することによってその楽器が音に合わせて動いたり、大きくなったり、音符を出したりするなどの演奏に対する結果の出力ではない反応を演出し、エンターテインメント性を出すという方式である。しかしながら、ただ楽器が画面上で変化するだけでは少々不足しているのではないかと考え、11月後半の時期に急遽エフェクトの仕様を変更した。最終的には、演奏を行っている人のムービクリップを作成し、それに対して音毎の変化を出した。具体的に説明すると、まず画面上には楽譜以外に楽器(今回ではフルート)を持った人物の画像があり、ユーザがnanoPADによって演奏を行い、Max/MSPが処理した音の種類によって、それぞれ異なる指使いによって楽器を演奏するムービーを出すという形式である。これによって、画面上でもユーザの演奏結果をただ単純に表示するだけでなく、画面上でも演奏を行うことにより、ユーザを視覚情報から演奏をしている気分にさせるように試みた。この制御は基本他の箇所で行った制御であるフレーム操作を使用していて、if文による場合分けにより作成した指の表示を変えて場面変えを行っているだけである。　また、実行画面以外に作成したメニュー画面についても少し述べる。メニュー画面では3つの項目があり、ユーザが現在どの項目を選んでいるのかが判別できるなくてはならないので、テロップを流したり、ボタンに変化をつけたりといった工夫を入れた。なたこれはメニュー画面だけでなく実行画面に関しても該当する箇所があるが、操作の方法として今回はインターフェースの機器(今回はnanoPAD)での操作はあくまで演奏の箇所だけであり、それ以外の操作はマウスによって行う処理にした。その為、Action Scriptにてマウスからの操作に対応して場面の切り替えを行わせるようにした。またFlashからMax/MSPへの情報送信や逆側からの情報の受け取りに関しても、前期の制作物であるMusic Fuzzyと同様、該当する箇所をAction Scriptで制御するという方法を取り解決を行った。　　5.7.4　評価　　ユーザの演奏結果を画面上に出力することによって、ユーザに結果を視覚的に伝えた為、またその方法が数値などによる直接的な方式ではなく、楽譜や演奏している状況などの音楽に関連した方式によるものであった為、画面開発の当初の目的でもあった「ユーザに演奏を行っている気分にさせる出力」を行うことができた。また前期の制作物であるMusic FuzzyではただMax/MSP側からの出力結果を表示するだけであったが、本作では画面の場面展開の制御をそろえたり、また全画面で表示されるためプログラム終了の項目を入れたりなど、結果の出力以外の箇所の向上も行った。しかしながらいくつかの問題点もあるのも事実ではある。例えば、メニュー画面と実行画面との統一性が薄いという点である。11月下旬に出力画面のデザインの仕様変更があった為に、メニュー画面の修正が間に合わず、メニュー画面の箇所が旧デザインとなり、新デザインの方も旧デザインに合わせて作成は行ったが、若干のズレが生じてしまった。また、出力画面の構成に関しても問題が存在している。現在Harmonic Fuzzyの実行画面は楽譜が画面上部にあり、演奏に合わせて動作する人物のオブジェクトが中央にあるという形式であった。演奏中にユーザが見ていた箇所は、主に楽譜の箇所であり、人物が演奏を行っているムービーの箇所は位置の関係上あまり集中して見られなかったというもの問題である。そもそもこの人物の動作は指にしか変化が無いため、動きの変化が多少分かり難くなってしまっている。これらの点は単純にクオリティが多少低いという問題点ではあるが、エンターテインメント性をより引き出す為には、これらの問題点を解決するクオリティの向上が必要になっているのも事実である。　5.a　HarmonicFazzyを使用した実演技術の習得　　//こんなん増やしてもよろしいですか？いろいろ突っ込んで頂けるとありがたいです(飯田)// 　　5.a.1　成果　最終成果発表会において、傍聴者に対して実演を行うことは、最も効率的にHarmonicFazzyの利点などを伝えることのできる手段のひとつである。しかし、まずは実演する我々がわかりやすい演奏方法を身につけなければ、この最終成果物のメリットを伝えることができないため、ある程度演奏方法を固定し、だれでも簡単に演奏できるような方法を考案した。　　5.a.2　仕様　具体的には、曲全体のコード進行に合わせて、どの場所でどの音色を使い、またそれに合わせてどのような演奏を心がければよいかを明記した、いわばマニュアルのようなものである。今回は3種類の音色と、3段階の音程が使用でき、それらも紹介できるようにしなければいけないため、曲全体を３つの構成として考え、それぞれのパートごとに音色を振り分け、それにあったメロディをつけることができることが可能となった。　　5.a.3　解決手順　前記したとおり、曲全体を3つの構成として考える。そしてそれぞれの部分に違う音色を設定した。　まず序盤部分ではピアノの音を使用した。数ある楽器の中でもっともポピュラーであり、どんな楽曲にも対応することができるためである。またメロディをつける際は、単音を中心として、連続的なメロディをつけるように心がけることにより、よりピアノらしい演奏となった。　中間部分では、木琴のような音を使用した。サスティンが短く一音一音がしっかりとした音色なので、このときはピアノのときよりもはきはきしたメロディをつけ、音数を多めにしながら単音と和音を織り交ぜて使用することにより、スタッカートの効いたメロディをつけやすくなった。　終盤部分では、バイオリンのような音色を使用した。他の音色よりもやわらかく伸びのある音なので、音数を少なくしてゆっくりと長く音を奏でていくこととした。これにより、静かでゆったりとしたメロディを奏でることができた。　以上のように、ボタンを押してから離すまでの音の長さが違う3種類の音色を設定することにより、様々な演奏方法が可能であるということをわかりやすく伝えることができるようになった。また、どれもオーケストラなどでも使われるような音色であることから、どんな楽曲にも違和感なくメロディを乗せることができた。　　5.a.4　評価　最終発表会にて上記のことを意識しながら実演を行ったところ、閲覧者が発表終了後に記載する評価シートに「実演がわかりやすかった」などのフィードバックを多数いただくことができた。これは、今回の考察が成功したものと考えることができる。しかし、ある教授から「実演が慣れすぎているのではないか」との指摘もあり、今回のHarmonicFazzyの目的のひとつである、誰にでも簡単に演奏できる、という部分から少し離れてしまった。ある程度は仕方ないかもしれないが、その場で参加を募って実際に演奏してもらうなどして、誰にでも簡単に演奏できるが課題として残ってしまった。　5.8 中間発表会（ゆっこ）終わーり　　5.8.1　成果　中間発表会のために、展示用のポスターとプレゼンテーション用のスライド、メンバー全員のプロジェクトTシャツを作成した。以下に図すうじ　で今回のポスターを示す。また、このほかにプレゼンテーションの練習、Music Fuzzyの実演の練習なども行った。　　　　　　　　　「がぞう」　　　　　　　　　図すうじ　中間発表会用ポスター　　5.8.2　解決手順解決手順　ポスターを作成するにあたり、読む人にわかりやすいように文章はなるべく簡潔に少なめにし、図や写真を多く取り入れた。　スライドも情報量が多くなりすぎないように、重要なところにポイントをしぼり、なおかつ発表の順序をどうしたら聞き手にわかりやすいかを考えた上で作成した。プレゼンテーションではMusic Fuzzyの概要を説明したあとに、実際の動作の様子を実演で披露することにした。そのため発表の練習は、まずプレゼンテーションの練習をするメンバーと実演の練習をするメンバーに分かれて行った。　プレゼンテーションの練習をするにおいて、台本などを作ってしまうと棒読みのようになってしまいがちなので、それを防いでより自然なプレゼンテーションを行うために、台本の　作成は一切行わなかった。簡潔な内容のスライドの説明をうまくできているか、また、声の調子や大きさ、スピードが聞き手にわかりやすいものになるよう全員で発表の練習を見せ合い、お互い注意し合いながら練習を行った。質疑応答にも柔軟な対応が出来るように、全員で考えられる質問をし合っていった。　実演の練習をするにおいては、実演の際に使用する音源「愛の夢」を何度も繰り返し聞き、ピアノ版の楽譜を用意し、この曲のテンポやダイナミクスに関する情報をよく理解した。そして、テンポや曲のどの場面でテンポまたはダイナミクスを操作すればより効果的に聞かせることが出来るのかを重点に置いて練習をした。　また、メンバー全員の統一感を持たせるためと、他のプロジェクトとの差別化をはかるために、プロジェクトTシャツを用意した。自由な音楽をテーマとし、楽しくかつ個性を尊重したプロジェクトであるという雰囲気を出せるように、メンバー全員ひとりひとりのTシャツの色を変え、柄は無地で統一した。　　5.8.3　評価　ポスターやスライド、個々の出来としては良かったのだが、全体に統一感がなかったので、最終発表では全体の統一感を考えつつ、発表の準備をしていきたい。プレゼンテーションも一部の人だけがするのではなく、全員がしたほうがメンバー全員のプレゼンテーション能力や理解度の向上に繋がると考えた。　また、実演を行うため室内での発表になるため、発表場所がわからなかったという声もあったので、発表場所を示した貼り紙などをすると、もっとたくさんの方が発表をみに来て下さるのではないかと考えた。　5.9 成果発表会（ゆっこ）終　　5.9.1　成果　最終発表会のために、展示用のポスター、プレゼンテーション用のスライド、入り口に設置するプロジェクト紹介のためのスライド、道案内用の張り紙などを作成した。以下に図すうじ　で今回のポスターを示す。また、中間発表会のときの評価シートを参考にしたうえで、プレゼンテーションの練習、実演の練習なども行った。　これらの準備を計画的にしておいたため、室内で人の集まりにくい場所での発表ではあったが、たくさんの方に発表を見に来ていただくことができた。　　　　　　　「がぞう」「がぞう」　　　　　　図すうじ　最終発表会用ポスター　　5.9.2　解決手順　中間発表ではプレゼンテーションを行うメンバーと実演を行うメンバーに分かれて発表を行ったが、全員のプレゼンテーション能力とプロジェクト学習に関する理解度の向上のために全員が１回ずつでもプレゼンテーションを行ったほうが良いと考えた。そのため今回は、理論班に実演の練習を事前にしてもらい、プレゼンテーションの練習は全員で行った。ひとりひとり練習を行ったため時間を要したが、全員が人前で発表するという経験ができたので良かった。　ポスターは中間発表と同じデザインで作成した。中間発表の際と同様に、文章は簡潔なものにした。そして今回は理論の面などで、口頭での説明では難しい点があったため、出来るだけわかりやすい図で表現した。　プレゼンテーション用のスライドは、この一年間の過程がわかるように、本プロジェクトの目的、前期の成果、反省点、後期の目標、後期の成果が明確になるように順序立てて作成した。　また、成果物Harmonic Fuzzyのシンボルマークを作成したので、これをプレゼンテーション用のスライドや、Tシャツのロゴ等に使用することにより全体に統一感が出来た。　室内での発表のため、外から見ただけでは本プロジェクトの発表がわかりずらいという意見が中間発表会の際にでていた。たくさんの方に発表を見に来ていただきたいので、外から見ても発表を行っているということがわかるように、また、少しでも入りやすい雰囲気になるよう、発表を行う教室の前にプロジェクターを設置し、プロジェクトメンバーの写真や本プロジェクトのキャッチコピー等をスライドにして投影した。本プロジェクト名と発表する教室の場所を記載した貼り紙も作成し、教室の入り口に掲示した。　　5.9.3　評価　発表準備はメンバー全員が協力し、中間発表会の経験も生かしてスムーズに作業することが出来ていた。教室内に入りやすいように入り口に工夫をしたので、教室の後ろに立ち見の方が出るほど、予想以上にたくさんの方々に発表を見ていただくことが出来た。　アンケートの内容によると、実演がすごく好評であった。プレゼンテーションは全員が行ったため、厳しい評価もあったが全員がプレゼンテーションの経験が出来たので良かったと思う。ポスターは中間発表の際とほぼ同じデザインで作成し、文章の量や画像・写真の量は適切だったが、今回はシンボルマークも作成し、全体の統一感という点ではもう少しデザインを変えるべきだった。　全体を通して具体的な成果物ができ、たくさんの方に本プロジェクトを知っていただき、おもしろいプロジェクトの内容であったと評価をしていただくことが出来たので、発表会の目的は達成出来た。 2010-01-07T15:56:39+09:00 最終報告書　第2章 http://www23.atwiki.jp/musicprog16/pages/26.html 2010-01-06T16:34:10+09:00 最終報告書　第6章 http://www23.atwiki.jp/musicprog16/pages/32.html 第6章　成果　6.1　班ごとの成果　6.1.1　理論(飯田)終　コードとスケールの関係性についての学習　音楽理論に基づいたコードやスケールの関係性についての学習や、MIDIデータ上でのコードとスケールの判別方法について提案などを行った。その結果、音楽理論の基礎を学ぶことによって、コードについての基本的な知識や、コードとスケールの基本と相互関係、アボイドノートについてなどの知識を身につけることができた。　第3章でも説明したが、一般的なコードとは、3つもしくは4つの異なる音から構成されており、「ド・ミ・ファ」「レ・ファ・ラ」などのように一音飛ばした構成をしている。一番低い音を根音、ルート音などと呼び、コードの種類を決定する。２つめ、３つめ、あるいは４つめの音の位置が少し変わることによって、コードの属性を決定する。　スケールとは、一般的に音階のことを指し、高さの違う複数の音の集まりのことを言う。西洋音楽では、ドから次のドまでの音を12等分して、そこから規則的に7音をとったものが長音階、短音階などと言われるものとなった。　ここで、調(キー)が一つに決まっていた場合、一般的にあるコードが存在するならば、それに対応してスケールもただ一つ決まる。つまり、コードとスケールは対となっているため、どちらかひとつが判別できればもう一方も判別できるようになる。これを利用して、今回の成果物を製作することができた。コードの判別方法　　音楽理論、コード理論に基づいて、コードやスケールの関係性についてや、楽曲におけるコードの構成の仕組みなどについてを学んだことによって、具体的なコード判別の方法を見出すことが出来た。　はじめに、再生されているMIDIデータの中にある、和音のデータをリアルタイムで読み込む。その和音の中で一番低い音をルート音として、その他の構成音との距離を調べ、それを数値化する。あらかじめ、3和音もしくは4和音で作られる一般的なコードがどのような音の配置で構成されているかを、数値的に表したものをプログラム上に用意しておく。そして入力されたコードと比較し、そのコードが何であるかを判別できるようにした。　スケールの判別方法　今回の成果物の場合、時間の制限や技術の限界などの理由から、楽曲のキーがCメジャーのみで固定されていた。そのため、入力されたコードと固定されているキーを比較させてスケールを判別した。スケールはあらかじめプログラムの中に組み込んでおき、入力されたコードに対応してスケールを出力するようにした。これにより、正確にスケールを判別することができるようになった。ただし前述のとおりキーが制限されていたため、読み込むことのできるコードに多少の制限があり、蓄えておくべきコードの種類、振り分けるべきスケールの種類は少なかった。　アボイドノートの検出方法　入力されたコードに対応したスケールを振り分ける際、そのスケールのなかにはコードにそぐわない除外すべき音であるアボイドノートが混ざっている。そのため、スケールとコードとアボイドノートを対応させて、プログラムの中で、対応したアボイドノートを除外するようにした。その結果、コード名とスケールが判別できた段階で即座にアボイドノートが判断できるようになり、nanoPADに振り分ける音の中に邪魔な音が入らないようにすることが可能となった。 (文責：飯田) 　6.1.2　プログラム班 6.1.2.1　MIDIを制御するプログラム　MIDIデータで作成された楽曲の再生、及びその楽曲のテンポ、ダイナミクス、ピッチを再生中にリアルタイムの操作し変化させることができる。ユーザが楽曲の不連続感を感じることなく楽曲操作を行う事が可能である。 6.1.2.2　MAX間通信プロトタイプ　中間発表に向けては、wii リモコンをPC1台に対し1台繋ぎwii リモコンのセンサの値をとる、ということに決定したため、MAX間の通信が必要となった。このプログラムによって別のPCのMAX/MSPとのリアルタイム通信が可能となった。 6.1.2.3　MAX-FLASH間通信　今後プロジェクトでGUIに処理情報を反映させる事を目的として開発を行い、MAX/MSP とFlash間で双方が相手に対し送受信を行うことが可能となった。 6.1.2.4　pro16wii 　このプログラムは、wii リモコンの各センサの値をMAX/MSP上でとるためのMAX/MSPのエクスターナルとして製作された。昨年製作されたpro10wiiに比べ、ソフトウェアの安定度が向上しており、かなり速く操作を行った場合でも、停止することなくセンサの値をMAX/MSPに渡すことができる様になっている。 6.1.2.5　Music Fuzzy 　このソフトウェアを製作するまでに開発したソフトウェア、および取得した技術をあわせて製作された中間発表の成果物である。wii リモコンを装着したロールコントーローラーによる操作で、MIDIで製作された楽曲のテンポ・音量といったパラメータををリアルタイムに操作する事が可能となっている。ユーザーが操作したパラメータの値はFlash上のメーターに反映され、ユーザは視覚的に情報のフィードバックを受けることが可能となっている。 6.1.2　班ごとの成果　の　プログラム班 6.1.2.6　Camailの作成　このプログラムはnanopadとMAX/MSPの接続を主体として作成されたものである。nanopadの各ボタンに不協和音にならない音を割り当てたり、オクターブチェンジの機能を割り当てたり、鳴らす音のプログラムチェンジを割り当てたり、ダイナミクスの変化を割り当てたりといった様々な機能を振り分けている。今回のHarmonic Fuzzyの基盤ともいえる部分である。（文責：古川裕太） 6.1.2.7　sortcodeの作成　C++によってMAX/MSPのオブジェクトとして作成されたMIDI音源の構成する音を解析することで、コードを判別するプログラムである。このプログラムにMIDIの制御によって再生されているMIDI音源の主旋律である値を渡すことでコードの判別が可能となった。コードの判別には理論班によって作成されたコード判別表が用いられている。（文責：古川裕太） 6.1.2.8　umdecodeの作成　C++によってMAX/MSPのオブジェクトとして作成された、sortcodeで判別されたコードを受けてそのコードに対応した音を割り当てるためのプログラムである。このプログラムによって伴奏に対して不自然ではない音を常にnanopadの各ボタンに割り当てることが出来た。音の振り分けには理論班によって調べ上げられたコードに対応した適切な音の種類が用いられている。（文責：古川裕太） 6.1.2.9　Harmonic Fuzzyの作成 6.1.2.9.1　各種コントロールチェンジ　nanopadを用いて様々に旋律の変化をさせる際、より多彩に音色に変化をつけるために様々なコントロールチェンジを加えた。3種類の楽器による音色の変化、基本となる音から１段階高低をつけた３つのオクターブ変化、そしてタッチパネルを用いた直感的な操作が可能となるダイナミクスの変化、この３つのコントロールチェンジの実装を行い、これによって演奏中に様々な音色へと変化させることが可能となり、よりプロジェクトテーマに近い物へ仕上げることができた。 6.1.2.9.2　コード判別のアルゴリズム　コード判別はMIDIで作成した伴奏のコード構成部分からその時鳴っている音を抽出し、理論班によって調べられたコード対応表を用いて完全マッチングにて判別を行っている。このプログラムによって高速なコード判別が可能となった。開発はC++を用いて行った。 6.1.2.9.3　リアルタイム処理における先読み込み　Harmonic Fuzzyは伴奏からコードを読み取り不協和音とならない音を出すことが要であり、常に伴奏に対して不自然ではない音を出さなければならなかったが、実際に演奏される伴奏とコードの読み取りを同時に行うとどうしても微妙にコードの読み取りが遅くなり音がずれる場合があった。そのためdelayオブジェクトを用いて演奏とコードの読み取りをほんの少しずらし、常にコードの読み取りを少し早めに行うことで安定して自然な音で演奏することが可能となった。 6.1.2.9.4　MAX-FLASH間通信　MAXとFLASH間通信には前期と同様の方法を用いたが、FLASH側に値を送信する際に先頭の値が前回送った値と同じ場合に値を受け取らないという問題があった。そのためスイッチオブジェクトを用いて、nanopadのボタンが押された際に前回とは異なる値を送るように設定した。これによってMAX側で変化させている各ボタンに対応した音をFLASH側の楽譜へと表示させることができ、今どの音を出しているのかが把握しやくすなった。（文責：古川裕太）　6.1.3　インタフェース班(田中)終　　前期のアイディア班が二つに分かれ、理論班とインターフェース班が出来た為、ここでは前期のアイディア班の活動についても述べる。インターフェース班はいくつかの活動を行っている。まず第一に、GUIの作成である。前期ではMusic Fuzzy、後期ではHarmonic Fuzzyの画面を両方ともFlashにて作成を行った。その為、画面構築の為のFlashの技術習得も行っている。プログラム班が制作したプログラムによって処理した音情報のパラメータを的確に視覚にてユーザに伝達する為に、また演奏を行っているユーザが手の操作だけでなく、視覚から情報によって演奏をしている気分を誘発するような画面構成を目標として制作を行った。前期の成果物であるMusic Fuzzyでは、出力する曲の選択を行うメニュー画面と、実際に画曲のパラメータの表示を行う実行画面の二つの画面を作成した。どちらの画面でもflashserverによるFlashとMax/MSP間での通信を行い、Max/MSPからの情報を受け取って、それを元に処理を行っている。前期でのMusic Fuzzyではwiiリモコンによる操作であったため、それに合わせての制御を行った。後期に作成したHarmonic Fuzzyでも同様に、プログラミング班が作成したプログラムの出力を行う為にFlashにて画面を作成した。しかし後期のHarmonic Fuzzyでは、前期での問題点でもあった、ユーザを視覚情報によって演奏した気分にさせることができるかという点に着目して制作を行った。Harmonic Fuzzyの画面では、Music Fuzzyでも作成したメニュー画面及び実行画面以外にもいくつかの機能を作成した。最終的にHarmonic Fuzzyで作成したのは、起動したときに表示されるシンボルマークや制作プロジェクト名を移すタイトル画面、各画面に場面を切り替える為のメニュー画面、実際にMax/MSPで作成したプログラムと通信し演奏を行う実行画面、実行画面の操作説明や概要をユーザに説明するチュートリアル画面、そしてプログラムを終了させる終了画面の計五つの画面を作成した。また今回は演奏の操作インターフェースとしてnanoPADを採用しているが、nanoPADを使用する箇所は実行画面部だけであり、その他の箇所はマウスを使用して操作を行う仕様に設定する為、前期とは多少異なるAction Scriptを用いて画面の制作を行った。　二つ目の活動はポスターの作成である。実際にはポスターの内容は各班が協力し、各項目を記入したのでインタース班のみの活動内容ではないが、主にインターフェース班が行った内容についてを述べる。主にインターフェース班は、当然ではあるがインターフェース班が行った内容の要約を記述した。制作物の概要、作成した画面の構図、操作方法やシンボルマーク、また他班の活動要約の図にも多少協力を行っている。また、ポスターの印刷はインターフェース班が行った。印刷する為にポスターの形式を整え、それを指定されたポスターの要項を満たすよう作成、印刷を行った。　三つ目は操作インターフェースの考案、作成である。プログラム班が作成したプログラムをどのような装置を用いれば適切であるか、ユーザが演奏している気分になれるかといった点を考察し、それにふさわしい装置を探し、必要とあれば新しく操作する為の装置を開発した。まず前期に作成したMusic Fuzzyに関してであるが、操作を行う為のインターフェースとしては二つの装置を使用した。まず一つ目はwiiリモコンである。wiiリモコンのロールの値をMax/MSPによって入手し、そのロールの値によって音のパラメータの操作を行った。このwiiリモコンを採用した理由は、昨年度でもこれを使用してMax/MSP上で処理を行っていたからである。二つ目に使用したのは、ロールコントローラーと命名した装置である。　(ロールコントローラーの画像) 　これを開発、使用した理由は、まず操作の方法をwiiリモコンを捻るといったリモコンを操作する動作ではなく、体を使用した操作方法を取らせる為である。前年度ではwiiリモコンを捻るという動作を行って操作していたが、捻るという動作が操作し難いと感じた為、回すという単純な操作を組み込むといったことも理由の一つである。しかし、これら装置を使用した演奏は、ユーザ演奏しているという気分にはさせず、ただ回すという動作をしているとしか感じられなかった。その為後期に作成したHarmonic Fuzzyでは、midi機器であるnanoPADを採用した。nanoPADはそもそも演奏を行う為の装置である為、当然演奏を行うことに適している為、これを使用した。ただnanoPADはあくまでmidi機器であり、これによって画面の操作を行うには不適切であると考え、演奏以外の操作はマウスを採用した。　四つ目はシンボルマークの作成である。作成したシンボルマークは後期に作成したHarmonic Fuzzyだけであり、前期に作成したMusic Fuzzyのシンボルマークは作成しなかった。作成したシンボルマークは、Harmonic Fuzzyが音楽の分野のソフトである為、音楽に関連したマークにする為に、本作では音符を採用しマークを作成した。　（シンボルマーク画像） (文責：田中) 　6.1.4　各メンバーの成果・高谷有紀子　おわり私は本プロジェクトのプロジェクトリーダーを担当した。プロジェクト内での話し合いをまとめたり、各グループの進捗状況の把握、担当教員への連絡・相談、メンバーの出席状況の確認、メンバー全員が週報を提出したかの確認、その他発表会等の事務的作業を行い、メンバー全員がグループワークを円滑に行えるように努めた。前期はアイディア班に所属し、wiiリモコンに外付けするインターフェイスであるロールコントローラの設計、作成を行った。後期はインターフェイス班に所属し、GUIのアイディアを出したり、FlashとActionScriptを学習しながら音符や楽器などのパーツを作成した。また、最終発表に使用するスライドのテンプレート作成、Illustraterを使用してのポスター作成、メンバーが着用するプロジェクトTシャツの発案・作成を行った。・田中慎太郎　前期プロジェクト　アイディア班に所属し、主にFlashによるGUIの作成を行った。Max/MSPの基礎知識の学習の後は長期間にわたり、Flashによる制作を行った。Flashの基礎操作やAction Scriptの習得後、基礎画面構成、画面展開の処理、画面のデザイン、Max./MSPとの通信制御など、Music Fuzzyの画面開発全般を行った。また、ポスターの作成も行った。　後期プロジェクト　後期ではインターフェース班に所属され、前期と同様Flashに関する箇所の制作を行った。Harmoinc FuzzyのGUI全般を前期と同様担当し、制作を行った。またポスターの制作や、Harmonic Fuzzyのシンボルマークのデザイン、制作を行った。・下村京平　前期プロジェクト　前期では、アイディア班のメンバーとしてインタフェースの制作に取り掛かった。そのため、前半はAction　Scriptの学習を行い、その後Wiiリモコンを取り付けるためのインタフェースの制作を行った。Wiiリモコンを取り付けるためにはどのような形にすべきなのか、どのようなもので作るべきなのかを考え作成を行った。また、前半の目標決めの時には、メンバーそれぞれの意見を聞き、まとめた。　後期プロジェクト　後期では、理論班のメンバーとして音楽理論について学習を行った。コード理論とスケール理論の学習を行い、スケールの構成、コードの構成方法の知識をつけ、スケールの判別とコードの判別を行わせるためのアルゴリズムをまとめた。また、最終発表会のパフォーマンスで使用するための楽曲の作成を行った。・飯田悠司(終) 　前期プロジェクト　前期はアイデア班に所属した。主にデザインなどを担当する班だったが、そのために必要な知識がほとんどなかったため、まずはFLASHやActionScriptなどの基礎的な内容を学習した。そして、それを利用して前期成果物における実際のメニュー画面や、値を表示するための画面などのGUI部分のアイデアを考案した。また、FLASHとMax/MSPとの接続方法をWebなどを利用して探索した。前期末には、後期の方針を決定しつつあったので、音についての理解を深めるため、Webページや情報ライブラリにて公開している文献を読む、他大学の研究内容を調べて参考にするなどの活動も行った。　後期プロジェクト　後期では理論班に所属した。そこでは主にコードの判別方法、スケールの判別方法を開発するという目標が設定されていたので、まずは一般的な音楽理論を元に、楽曲や音、コードやスケールなどについての学習を行った。その際、Webページや文献を参考に学習を進めた。また、後期成果物のコードの判別方法、スケールの判別方法に関する具体的なアルゴリズムを製作するため、後期序盤に学習したことを応用して、その判別方法を開発した。活動終盤では前期で学習したことを利用し、最終成果発表会におけるプレゼンテーション用のスライド製作などの活動も行った。 (文責：飯田) ・茅野裕馬（終）前期プロジェクト　Music Fuzzyの全体のアルゴリズムの考案や、MAX-FLASH間通信、pro16wiiといった各機能の実装を中心に行い、他メンバーの開発活動におけるアドバイス等も行った。また、MIDI処理に関するアルゴリズムの考案や、MIDI機器、音響機器の設定及び設置、中間発表におけるパワーポイント作成及び発表を行った。後期プロジェクト　Harmonic Fuzzy全体のアルゴリズムの考案やコード割り当て機能、プログラムチェンジ部分、オクターブシフト部分、ダイナミクスコントロール部分、FLASH－MAX/MSP間の通信部分、MIDI楽曲の先読み込み部分といった各機能の実装を中心に行い、他メンバーがプログラムをうまく作成できない場合は代替となる簡易的なアルゴリズムを考案しサポートを行った。また、各種バグの修正やMIDI機器の設定、最終発表用楽曲の作曲などを行った。・佐藤佑樹（終）前期プロジェクト　まず、任天堂ソフトのWii Musicの動きを確認し、私たちはどのようなものを作ればよいか話し合った。その後、プログラム班に所属し、各プログラムの分析や接続を行った。また、WiiにおけるC++のボタン操作を分析し、その動きがどうなっているのかを調べた。比較的、技術面においてはあまり触れていなかったので、交流の場を早めに提供し、みんなの統一を図るようにした。後期プロジェクト　前期に引き続き、プログラム班に所属し、nanoPADのボタンにそれぞれどのような値が送られているのかを調べた。nanoPADの左側にある4段階のSCENEによって送られる値が変わることがわかった。目的は初心者でも簡単に演奏できるようなソフトウェアを作ることなので、少量のボタンだけで演奏できるようにSCENE1だけを使用した。どのような値が送られるかはオブジェクトのnotein, noteoutを用いることによって調べられることが分かった。今回は技術的な面にも取り掛かることが出来たので、今回のツールがどのようなプログラムなのか大まかな部分を理解することが出来た。（文責：佐藤佑樹）・寺井明日実　終前期プロジェクト　プログラム班のグループリーダーとして活動内容を把握したり、話し合いを纏めることに努めた。Max/MSP の扱い方やC++でMax/MSPのオブジェクトを作成する方法の基礎を学んだ。中間発表会では演奏を担当した。また中心となって中間報告書の執筆を行った。　後期プロジェクト　前期と同様にプログラム班に所属し、その中でC++の担当となった。主にコードを判別するプログラムを作成し、その後は他のC++のプログラムの手直しや機能の追加などを行った。成果発表会用ポスターに乗せる図の作成なども行った。（文責：　寺井明日実）・古川裕太前期プロジェクト　前期はMAX/MSPに関してはMAX間通信におけるテンポ、音量のパラメータの送信部分などを作成した。これはWiiリモコンから検出された値によってテンポや音量を調整した値をMAX間通信によりMIDI制御を行っているPCのMAX/MSPに送り伴奏へ反映させるものである。このオブジェクトを使った方が楽なのではないか、といった提案などを行うこともあった。また、中間発表においては質問に対する回答役を行った。突っ込んだ回答にも対応するためにプログラム全体に対する理解を深める必要があり、これにより知識が深まった。後期プロジェクト　後期の成果としてはMIDI制御部分や最終的なまとめ部分を担当した。MIDI制御に関しては前期のものを参考にしつつも外部機器であるnanopadとの接続やコードの読み込みといった新しい機能が加えられたため、大幅に変更を加えることとなった。最終的なまとめとしてはC++にて製作したオブジェクトの実装、nanopadとMAX/MSPの接続、MIDI制御と再生、そしてインターフェースといった後期にプロジェクト班とインターフェース班の各メンバーが作成したプログラムを１つプログラムへまとめあげた。また、最終発表において全員が発表をするということで私も発表を行った。簡潔にそれでいて分かりやすい説明をする事の難しさをよく知ることができた。（文責：古川裕太）　　6.2　今後の展望　　6.2.1インタフェース班　田中　終　インターフェース班で主に行ってきた活動はGUIの作成であり、Flashによる画面の開発である。その為今回の課題点では主に作成したGUIについて、特に後期に作成したHarmonic Fuzzyに関しての課題点を述べる。　まず最初に、画面毎のデザインに関してである。5.7.4の評価でも多少述べたが、メニュー画面と実行画面にてデザインの仕様が異なってしまってしまい、統一感がなくなってしまっている。また、このデザインがそもそもHarmonic Fuzzyのプログラムに合っているのかとういう点でも議論があまりされていない。Harmonic Fuzzyでの主役はあくまでプログラムによる音の処理の部分であり、画目のデザインの箇所ではない。その為デザインの方をプログラムに合ったものにする必要がある。如何にして画面によりプログラムについてを伝えられるかを詳しく考察し、解決策を練ることが一つの課題点である。　第二に、エフェクトの向上についてである。後期に作成したHarmonic Fuzzyの実行画面では、楽譜と演奏している人物のムービー、そして背景の演出がこれに該当する。まず楽譜に関してのエフェクトであるが、単調に音符を楽譜上に流しているだけである。音符自体に演出が施されていない為、エンターテインメント性が弱く感じてしまう。また画面内の演奏を行う人物に関する演出も、動く箇所が指のみである為、演出が弱くなってしまっている。両者とも、例えば音符の形を変化させたり、動かす箇所を増やすこなど、大きな演出を入れることでよりエンターテインメント性を増すことが可能である。しかしながらそのようにした場合、演出過剰によって今度は楽譜などの結果出力部の情報が的確に伝わらなくたってしまう可能性がある。エンターテインメント性を向上させ、かつその演出によって機能性も損なわないようにする、このバランスに関してを考察し、制作物のクオリティを向上させるという点もまた課題点の一つである。　第三に、開発環境の見直しである。今年度は前年度に引き続き、FlashによってGUIの作成を行った。Flashを使用した理由として、Max/MSPとの通信の方法が既に確立されていたという点がある。前年度に既に作成してあったものを参考にしたり、web上に掲載されたFlashとMax/MSP間の通信方法を元に作成を行った為、使用を満たすのに容易であった。またFlash自体が映像作成に非常に適しているということも事実である。しかしながら、他にも画面作成に適している開発環境が存在し得たかもしれない。例えばJavaでも制作は可能であるし、DirectXなども画面開発が可能である。もちろんFlashもまた画面開発に適していると言えるが、採用した最も大きな理由は昨年度も使用していたからである。Flashを昨年度も使用していたから今年もそれを使用して目標のものをFlashの仕様に合わせて作るのではなく、もっと他の開発環境に関してを調べ考察し、目的のものに適している開発環境を使用すべきである。もちろん、議論した上でFlashが最も制作に適していると判断したならばそれで良い。今後の開発環境に関してを議論することは課題の一つである。　第四に、演奏を行う為の操作インターフェースに関してである。今回で使用した操作インターフェースは、前期にwiiリモコンとロールコントローラー、後期にはnanoPADを採用し、開発を行った。しかしながら、前期で使用した二つの装置に関しては演奏を行っている気分にはさせず、それを解決するために採用したnanoPADはmidi機器であるが故、非常に演奏には適していた。しかし、あくまで演奏に適しており、Harmonic Fuzzyに対して有効ではあったが、より向上させることができるのではないかという疑問点も浮上している。単純に演奏に適した装置があったからそれを採用したのであって、新しく作ろうとした訳ではない。例えば素人と玄人の楽器の弾き方の違いを調べる実験等を行い、その結果からの新しいインターフェースの可能性が見えてくるかもしれない。そうすれば新しい装置を開発し、より演奏しやすくなるかもしれない。勿論、nanoPADが最もHarmonioc Fuzzyに適しているという可能性も否定できない。しかしながら、今回ではその点に関する細かい議論、調査が行われていない為、新しいインターフェースの可能性に関して着目し、考察、調査を行うことでより操作の向上をさせることもまた課題の一つである。　まとめとして、インターフェース班の課題点はクオリティを向上させ、他の方法に関しての考察や調査を行うというもことである。言葉にまとめてしまうと簡単ではあるが、実際にこれらを実行するとなると、いくつものステップを踏む必要があり、またそれらにいくつもの方向性がある為、非常に多くの時間を必要としてしまう。単純に向上すると言っても、それを実現することは非常に困難である。しかしながら、これらの議論をせずに制作を行い、より向上したものができるかと聞かれると疑問点がある。これらの議論をしっかりと行い、必要とあれば調査、実験を行ってデータを得て、それを元に制作を行うことが重要である。一つの方法のみに着目するのではなく、いくつもの方法についてを着目し、可能性を見つけ、目標に最も適している方法を探す。今年度はFlashのみによる画面開発であり、新たな操作インターフェースについての議論があまりされなかった。開発したプログラムに対して最も適切である方法を見つける為にも、様々な制作方法についてを議論することがインターフェース班の課題である。 (文責：田中) 　　6.2.2理論班　コードの判別方法　現在のところ、MIDIデータのなかから読み込んだ3和音もしくは4和音が、プログラム上にある3和音もしくは4和音のコードデータと完全に一致しなければ、コード名の判別ができないようになっている。この課題に対しての問題点は大きくわけて２つ存在する。　まずひとつめに、異なる名称で同じ和音の構成であるコードの存在があげられる。これは和音の中のどの音がルート音なのかを判別しなければいけない、と言い直すこともできる。どの音をルート音にするかという解釈の違いや認識の違いなどから生まれる問題であるため、機械的に和音の構成とコード名を断定することはできないのである。そしてコードを特定しなければ、楽曲のキーと比較してコードにあったスケールを判断することができない。そのため、スケール判別をする際にも大きな影響を及ぼす可能性がある。　この問題に対して、それまでのコード進行からの流れや、一般的なコード進行などから予測することがある程度可能であるということが参考文献などからわかっているため、それまでのコード進行を記録しながら、一般的なコード進行のパターンと比較することのできるよう、一般的なコード進行のパターンを記録するようなデータベースを構築することで、その課題を解決できるのではないかと予測している。　ふたつめは、3和音もしくは4和音に満たない2和音以下の音、もしくは5和音以上などの複雑なコードの場合には対応できないことである。一般的な音楽理論では、3和音もしくは4和音をコードの基本として考えることが圧倒的に多い。そのため、今回の最終青果物においても、3和音もしくは4和音が入力される、という前提のもと製作を行った。しかし、実際に製作されているさまざまな楽曲では、2音だけが同時に鳴ることもあり、5音以上の異なる音が鳴っていることもあるため、その前提に必ずしも当てはまらない場合が多々存在する。なので、この問題を解決しない限りは、どんな楽曲にも対応させるという目標を達成することは難しいだろう。この問題に対して、いくつかの解決策を考えている。　まず2和音の入力に対して、それらを3和音のいずれかの音が省略されたもの、もしくは4和音のいずれか2つの音が省略されたものと考えることで、ある程度の予測をすることができる。そのうえで、異なる名称で同じ和音の構成であるコードが入力された場合の問題に対する解決策を応用し、それまでのコード進行や一般的なコード進行のパターンと比較して判定することができるのではないかと考えている。入力された2和音を含む3和音構成もしくは4和音構成のコードを識別し、それまでのコード進行や一般的なコード進行のパターンと比較することで、そのコードが何のコードの省略形であるかを判断した上で、コード名を特定するという方法である。　また5和音以上の入力に対しては、すべて4和音のうえに装飾音として1音多く鳴っていると解釈することで、予測をすることができる。実際、3和音や4和音の上に装飾音を乗せるという演奏方法は、数多くの楽曲で使用され、音楽理論・コード理論においてもその考え方は広く扱われている。そして、この問題に対しても、上記のような、それまでのコード進行を記録し、一般的なコード進行のパターンと比較するためのデータベースを構築することで解決できると考える。その5和音のルート音を判断し、それに合わせて残りの４つの音のうち3つとルート音で構成されている4和音のコードを識別する。そしてそのコードの候補とそれまでのコード進行や一般的なコード進行のパターンと比較することで、そのコードが何のコードの発展形であるかを判断した上で、コード名を特定する方法である。　ただしこの２つめの問題に対しても、まずは1つめの問題を解決しなければ、ルート音を予測するという行為ができなくなるため、それまでのコード進行を記録しながら、一般的なコード進行のパターンと比較するための、一般的なコード進行のパターンを記録するようなデータベースを構築することは、今後の研究のうえでもっとも重要な事柄であると考える。　スケールの判別方法　今回の製作物では、Cメジャースケールの場合のみという制限を設けて製作を行った。しかし、実際の楽曲ではさまざまなコードが使われ、それに合わせてさまざまなスケールを使用しなければならないことが多いため、このままではそれらの楽曲に対応することができないため、課題として残ってしまった。　この課題を解決するためには、大きな問題を乗り越えなければならない。それは、どのように実際の楽曲のコードを判別するか、という問題だ。楽曲には、全体の調(キー)というものが決まっている。これを簡潔に説明するならば、その楽曲における「ドレミファソラシド」が、どの位置にあるかを定めているものである。楽曲によって、中心となる音は変わってくるため、通常「ドレミファソラシド」と考えた場合はドが中心となっているが、きょくによっては「レ」であったり「ミ」する。たとえば、ある楽曲の楽譜の始めに、「＃」や「♭」がいくつも書かれている場合がある。これを調号といい、その楽曲における中心音がなにであるかを示している。何も書かれていない場合、本来のままドレミファソラシドの位置はかわらない。だが楽譜の始めに＃がひとつ書かれている場合、その曲のドは、本来のソの音として考えなければならない。また、調自身にも長調(メジャーキー)と短調(マイナーキー)の2種類があり、それによってもドの位置が変わってくる。それらは、メジャーキーがド、マイナーキーがラを中心とした音になっている。先ほどの例で言うならば、楽譜の始めに＃がひとつ書かれている場合、その曲のドは、メジャーキーの場合はソ、マイナーキーの場合はミ、ということになる。これらのことを踏まえたうえで初めて、曲の中に出てくるコードに合わせて、そのコード上でのスケールを判別する、という作業に入る。コード判別においての問題点は上の項で説明したとおりであるので、その課題を解決したうえで、スケールについての課題もしなければならない。これらをすべて判別するためには、十分な音楽理論に関する知識と、膨大な音楽経験、そしてそれを具現化するための技術が必要になるが、現在の我々ではそれらを達成できないであろうと考えた。そのため、今回の製作物については、楽曲全体のキーをひとつに絞ることによって簡易化を図った。　現段階では、この問題を解決するための方法がみつかっていない。楽曲によっては途中でキーが変化したり、あえてそのキーから外したスケールを使用していたりする場合もある。これらを機械的に判断することは容易ではない。しかし、コードの判別方法の課題点に対する解決策を応用して、既存のコード進行や、それに対応するキーなどを慣例的に判断することで、何らかの解決策を講じることができるのではないか、と予測している。 (文責：飯田) 　　6.2.3プログラム班　プログラム班における今後の課題において、まず１つ目は、どんな楽曲にも対応できるようにすることである。今回の作ったHarmonic Fuzzyで使用した楽器は3個だった。nanoPADではボタンの数をもっと増やすことが可能であり、MAXのMIDI機器に搭載されている楽器の種類は他にもたくさんあるので、さまざまなジャンルの音楽を作ることができる。また、今回用いた音楽は、演奏速度が速い楽曲だったので、遅い楽曲でも演奏できるようにすること。例えば、前期で用いた愛の夢の伴奏に、メロディーラインを載せていけば、オリジナルの楽曲を作ることができるようになるであろう。さらに、J-POPに音楽を載せることで、J-POPをオリジナルにアレンジすることを可能にしてほしい。カラオケはMIDIを使用しているので、誰かが歌っているときに、横で演奏するなど楽しい機能も搭載できる。　２つ目は実際の演奏とセッションを可能にすることである。MIDI機器の楽器の種類は多数存在するので、いろいろセッションをすることが可能となる。MIDIには、ドラムを初め、キーボードやギター、ベースなどの基本的なものから、フルートといった笛類も存在するので、MIDI機器でバンド演奏を初め、オーケストラを組むことも出来るであろう。　３つ目はさらに使いやすいインタフェースにすることです。今回使用したのはWiiリモコンとnanoPADであったが、Wiiリモコンはアクションをするときの音楽表現には最適であるが、プログラムをすることがとても難しく、旋律を操作する方法を見出せない。また、nanoPADはボタンの種類が多いので、初めての人には少々使いにくいという欠点も残っている。だから、ボタン配列がわかりやすい位置にあり、ボタンの数もさらに多いインタフェースを使用すれば演奏の幅がもっと広がっていくだろう。（文責：佐藤佑樹） 2010-01-06T16:00:15+09:00 最終報告書　第4章（テキストモード） http://www23.atwiki.jp/musicprog16/pages/37.html 容量オーバーしたのでテキストモードに第4章　プロジェクト内のインターワーキング（ゆっこ）（佐藤）終開発環境における学習 5月　昨年度のインターフェースと開発環境の導入　去年の研究内容を引き継いで、プログラムの操作を昨年度のプロジェクトメンバーの方から教えてもらった。使用していた開発環境はMAX/MSPであり、そのやり方を学習していった。始めはドレミの旋律をMAX上で表現し、音楽を奏でた。徐々にその環境にも慣れ始めたところで、先輩から課題を出されるようになった。プロジェクトメンバーと一緒に考え、できないときもあったが、新たなオブジェクトの発見もあった。　5月の後半には、C++の学習を行い、ここから本格的にプログラム班とアイディア班に分かれた。C++では、まず起動のやり方とビルドの方法を行い、C++とMAXの接続の仕方を研究した。それは昨年度の先輩の力を借りて克服した。　 6月　インターフェースと開発環境を連動　Wii リモコンとC++、MAX/MSPを連動してPC上それを使った動きを表示した。私はC++上でWiiのボタン操作はどのようになっているのかを分析した。実際に、ボタンを押してPCに情報をどのように送ればよいのかはDemo.hを用いて理解することができた。 Wii リモコンを使って、テンポやダイナミクス、ピッチを変化させることに成功し、中間発表までの披露する音楽も決定した。また、実際に中間発表で使うWiiリモコンの動きをロールだけに集中した。中間発表の準備 6月　スライドの製作と中間報告書の初めの部分の作成　6月の後半になり、中間報告書や発表の下準備をするグループと中間発表のプログラムを創るグループに分かれた。私は発表用の仮のスライドを製作し、中間報告書の文章を考え始めた。 7月　発表の練習とシナリオ作り　中間発表に向けて、説明するべき点や話す内容をはっきりと話せるように練習し、説明と実演の流れをスムーズに出来るように何度も練習した。時間を具体的に計ってどのような質問をしてくるのか予想して、中間発表に備えた。開発環境における学習 8月　今後のプロジェクトの方針　夏季休業に一度だけ今後のプロジェクトをどのように進めていこうか話し合った。前回はダイナミクスとテンポだけしか変化させることができなかったので、今回はメロディーラインや音色の種類を操作出来るようなプログラムを実現しようと考えた。　 9月　nanoPADをMAX上で操作する方法　今回のインターフェースはnanoPADに決まり、プログラムは前期同様MAXを使用することとなった。まず、nanoPADがMAX上でどのように動作をするのかを研究した。MAX上で動かすには、KORG社のホームページから専用のドライバーをパソコンに取り込む必要があった。そして、nanoPADのボタンが押されたとき、MAXにどのような値が出力されるのかを確認することができた。 10月　nanoPADの不具合　通常、nanoPADのボタン信号は押したときと離したときの2回検出されるのだが、各々のボタンによって1回だけしか検出されない箇所や、信号がない箇所があった。その原因を追究していくうちにService Pack 1をパソコンに導入していないという候補も挙げられた。しかし、それを行っても結果は変わらなかった。最終的にKORG社に電話し、直接原因を聞くことにした。そこでわかったことがnanoPAD自身が故障しているということであった。そして、修理してもらったところ問題が改善された。 11月　nanoPADの値の振り分け　nanoPADのそれぞれのボタンの値を検出し、それらをMAX上で振り分けられるようにプログラムした。使用したオブジェクトはselectであった。その中にnanoPADから送られた値を振り分け、振り分けられた値をそれぞれ出力し、各々の値を操作（計算）することができるようになっている。 12月　最終発表の準備　まず、発表用のスライドを各班が担当した分野に分けて作り、それを連結して一つのスライドにした。私は担当したスライドはnanoPADを用いた理由の部分のスライドであった。また、発表用のパネルは主に背景、目標、理論班などを担当した。前回の発表の時、私たちの発表場所がどこかわからないという人が多数いたので、プロジェクト場所を示す矢印を作った。（古川）終古川裕太音に関する理解 4月　プロジェクトのテーマ決め、チーム分け　プロジェクト全体で今年度のテーマと方向性について話し合った結果、大きな目標として楽器が出来ない、やったことの無い人でも簡単な操作で楽しく演奏できるものを作成していくこととなった。そしてそれをどのような形にするかに関しては、昨年の成果物であるwii music を簡易化および改良、複数人でも使用を可能としたものを作成していく事が決定した。　その際、実際にプログラミングをするプログラム班とGUIの作成などに関するアイディア班の2つに別れて進めていくことが決定した。また、音に関する基礎知識を身に付けるため、ライブラリから本を借りて読む事で学習した。プログラミング技術の取得 5月　MAX/MSPの学習、技術取得　プログラム班で話し合い、まずはMAX/MSPの基礎知識を身に付けるところからはじめた。まず昨年のプロジェクトメンバーにMAX/MSPの使い方、基礎、Wiiリモコンの接続方法、去年行われていたプログラミングの説明など、様々な事を教えていただいた。そして、改めて自分たちでMAX/MSP内のチュートリアルやWebページを参照あるいは参考書を読むことで理解を深め、班内で知識を共有した。これによって、MAX/MSPプログラミングについて一通りのプログラミングが出来るような、ある程度の力を身につけた。その後、学習したMAX/MSPの知識を用いてMIDI再生部分とテンポ操作部分、そして音量操作部分と開発を行い、MIDI操作プログラムの基礎の作成を行った。 6月　C++の技術取得、wiiコントローラの制御方法について　プログラミング班全体でwii コントローラの制御のため、C++について学習した。Wiiyourself というフリーウェアを参考にすることでプログラムを作成した。Wiiコントローラのロールを受け取り、これをテンポや音量に対応した値へ置き換えることによってMAX/MSPとWiiコントローラを関連付けた。これをMAX/MSPに組み込むことで、wii コントローラからMAX/MSPへと値を送ることに成功した。 6月　MAX/MSPの技術取得、MAX/MSP、FLASHの通信方法について　異なるPC間におけるMAX/MSP同士の通信が必要となったため、通信方法について学習した。その結果、値が送信されない、値を送信しようとするとフリーズするなどの不具合に悩まされながらも、なんとか完成させることが出来た。　また、Wiiリモコンから得た情報をFLASHに反映させるためにMAX-FLASH間通信も必要となり学習を行った。これはアイディア班のインターフェース製作と協力して行うことで無事完成させることが出来た。これによってWiiリモコンで操作しているパラメータを視覚的に把握することが可能となり、より分かりやすいものとすることが出来た。　これによりプログラム開発の要となる部分の開発が完了し、今までのプログラムを統合することで成果物となるMusic Fuzzyを完成させることが出来た。中間発表の準備 7月　中間発表へ向けて　プロジェクト全体で中間発表へ向けて話し合いをした。その結果、発表と実演と質疑応答の３チームに分かれて中間発表を行うこととなった。そして成果物への理解の再確認を行い、その後は各自発表練習、ポスター作成、スライド作成を行った。私は質疑応答の役であったため、予想外の質問というものがほぼ無くなるように様々な想定を行い理解を深めた。　また、プログラムを実際に動作させた際に生じたバグの修正も行った。プログラミング応用技術の取得 8月　夏季休暇中の自主学習　夏季休暇につき休暇前に設定した自主学習を行った。C++におけるｆｌｅｘｔの内容の把握、MAX/MSPのオブジェクトの把握といった事を行った。flextは前期に用いたものであるが、簡単に把握した程度であったため、後期にも使う可能性を考えより深く理解をしておく必要があった。　また、MAX/MSPのオブジェクトは前期にも様々なものを使用したがまだ把握しきれていないものも多く、オブジェクトしだいでは肥大化したプログラムを簡潔にまとめることも可能になるため、出来る限り様々なオブジェクトを把握する必要があった。後期へ向けての話し合い 8月　方向性の見直し　前期制作物とプロジェクトの方向性について改めて話し合った結果、もっと音楽を奏でている物を作りたいという結論となった。そのため詳細には決めなかったがおおよその目標として、前期の知識を応用し旋律の変化を目標とした、新たな制作物にとりかかることとなった。その際、夏季休暇中にある程度どのようなものにしたいかを各自考えてくることとなった。 9月　後期制作物についての話し合い　8月に決めた旋律に変化をつけたいという方向性についてを詳しく話し合った。その結果伴奏に対して常に自然な音を出すことができ、かつ自由度があり簡単なものを製作することとなった。プログラム班でどのように作っていくかを話し合った結果、MAX/MSPおよびC++におけるプログラム作成を４つの段階へ分けて行う事となったため、各自メンバーが１つずつプログラム作成を受け持つ事となった。その際私は最終的な段階である各自が作成したプログラムのまとめ、調整を行う事となった。　　また、前期はプログラム班とアイディア班の２チームに分かれていたが、作業の効率化を目指しアイディア班を理論班とインターフェース班の２つに分化し３チームに分かれることとなった。取得したプログラミング技術を用いた開発１０月　制作物のプログラム開発について　担当しているプログラム部分の開発にあたった。MIDI制御の部分の開発やオブジェクトの把握を行った。MIDI制御部分に関してはMIDI再生部分に関しては前期である程度の形が出来ていたため、コード読み込みと実際のMIDI再生を別々にするなどの改良を加えつつ流用することとした。　最終的なまとめという役割上、他のメンバーのプログラム完成を待つ必要があったため、積極的に他のメンバーの作業を補助した。主な補助としては同じMAX/MSP分野の開発であるnanoPADとMAX/MSPの接続についての補助があげられる。１１月　プログラム開発およびプログラムチェックについて　１０月に引き続きプログラム開発を行った。主な作業として他のメンバーのプログラムが完成する前には前期にも用いられていたプログラムを応用したMIDI再生の基底部分やMIDI制御部分について作成を行った。主な作業としてはnanopPADからの入力に対して同期を取ったり、nanoPADの各ボタンの振り分けるといった作業を行った。　その後はプログラム班の各メンバーが作成したプログラムの調整を行った。コードによって変化する音とオクターブ変化による値の変化の再計算を行ったり、音色の変化によるオクターブチェンジなどが挙げられる。そしてこれまで作成したプログラムを１つにまとめあげることで、後期成果物であるHarmonic Fuzzyがほぼ完成となった。バグの修正１２月　様々なバグへの対応　プログラムがおおむね完成となったため、実際に動かしてみると様々なバグが存在することが分かった。nanopadのボタンを押したまま伴奏のコードが変化すると音が鳴り続けてしまうバグやFlashとの通信において値の反映がされないバグといった問題が存在しており、プログラム班の各メンバーで互いに協力し、バグの修正を行った。最終発表の準備 12月　最終発表へ向けて　プロジェクト全体で最終発表に向けての話し合いおよび準備を行った。各自ポスター作成、スライド作成、プログラムの動作確認に取り掛かった。中間発表では発表担当と補助担当、そして説明担当とそれぞれが分担して行ったが、最終発表ではプロジェクトメンバー全員が発表を行う事となったため、中間発表以上に念入りに成果物への理解の確認を行った。東京発表へ向けての準備 1月　東京発表へ向けて　2月に東京で行われるプロジェクト発表が決まったため、開発が間に合わなかった機能の実装や、最終発表で得られた評価やアドバイスを受けてHarminic　Fuzzyの改良を行った。具体的には当初、音色の変化はそれぞれ適したオクターブへ初期設定されていたが、バグが発見され、時間も足りなかったため全て同じ初期値で設定することとなった。これを当初の目標通りに各音色ごとにオクターブ設定をするといった改良が例としてあげられる。（文責：古川裕太）（田中）終プロジェクトテーマの理解、設定 4月　プロジェクトのテーマ設定、グループ決め　前年度のプロジェクトの活動を知り、その中で使用した技術及び問題点を踏まえて、プロジェクトのメンバーで今年度のテーマを設定し、目標達成の為の技術についてを調べた。またテーマの達成の為にプログラミングを行うプログラム班、その他の、操作インタフェースの製作やGUIの作成を行うアイディア班に分かれ、作業を分担し製作を行うようにした。また、予算の決定など、プロジェクトを行う上で必要となる設定を行った。　開発環境(Max/MSP、Flash CS4)の技術習得 5月　Max/MSPの学習、理解　4月のグループ配属によりアイディア班に配属されたが、製作においてプログラミン班と連動して製作を行う為、プログラム班の活動内容に関して理解する必要がある。その為プログラムの仕様についてを知る必要が出てきたので、アイディア班も合同でMax/MSPの学習を行った。Max/MSPの基礎技術を学び、どの様な仕様であるかを昨年度の制作物を参考に学んだ。またそれに並行して、Flash CS4の技術習得を行った。Flash CS4を採用した理由は、昨年度も使用していた点とMax/MSPとよ通信が可能であり、画面製作に適していると判断した為である。この時期では主にMax/MSPとの通信方法ではなく、Flashの基礎技術を学んだ。 6月　FlashとMax/MSPとの通信技術の習得、Music FuzzyのGUI製作　FlashとMax/MSP間での通信を行い、各情報を交換し合う必要が出た為、Flash側の制御方法を昨年度の制作物を参考に学んだ。主にFlash側の制御のAction Scriptを学び、またそれを実現する為にいくつかのサンプルを作成した。またそれに並行して、前年度の制作物であるMusic FuzzyのGUIの製作を行った。主にメニューとなる画面、Max/MSP側で処理し出力した音情報のパラメータを表示する実行画面の作成を行った。中間発表の為の活動 7月　中間発表に向けての活動　7月には中間発表があった為、それに向けての活動を行った。主に製作したMusic Fuzzyの最終調整、中間発表におけるポスターの作成及び印刷、そして発表の練習を行った。また中間発表後は、中間報告書の執筆を行い、前期間に行ったプロジェクト学習の活動を振り返った。 8月　夏季休業における自主学習　8月間は夏季休業となりプロジェクト学習の講義時間がなかった為、夏季休業期間を使用して自主的にFlashの学習を行い、技術の向上を図った。　後期におけるテーマの設定、新たな班の設定 9月　後期制作物についての設定、FlashでのGUI作成　前期間に作成したMusic Fuzzyの問題点を明確にし、後期に制作するものの設定を行った。それを決定した後、今後の制作物(後のHarmonic Fuzzy)のGUIの制作に入った。　Harmonic FuzzyのGUIの制作 10月　Harmonic Fuzzyの画面作成　Max/MSPで処理した音情報を的確にかつ視覚的にユーザに伝える為、画面の制作を前期と同様にFlash CS4にて行った。主にこの期間では背景部などの土台となる箇所の作成を行い、Max/MSP側がどのような仕様にしても対応できるように注意しながら制作を行った。処理の制御などはこの期間に制作せず、その他の画面に関しての制作を行った。 11月　Harmonic Fuzzyの画面作成、制御の処理の制作　10月に引き続き、GUIの作成を行った。11月には10月に行わなかった制御の処理をAction Scriptで制作し、11月後半にはプログラム班との連動を行い、FlashとMax/MSPとの通信を行った。また音の処理結果の出力を行う為のエフェクトの作成にも着手し、Max/MSPからの情報を元にして結果をFlash上の画面に出力するようにした。　最終発表の活動 12月　最終発表の為の活動　12月には最終発表があった為、その為の準備を行った。FlashによるGUIの作成の続き以外にも、最終発表の為のポスターの作成、最終発表のプレゼンテーションの発表の練習を行った。また、プログラム班は作成した、 Max/MSPのプログラムにより、処理した音のパラメータ情報を出力を行う画面において、デザインの箇所の修正を行い、それに合わせた処理の制御部分の修正も行った。また、最終発表終了後の評価にて、いくつかの問題点があることが分かった為、これに関する修正も行う予定である。 (文責：田中) （飯田）終プロジェクトのテーマの理解、Maxの技術習得 4月　プロジェクトのテーマ設定とMaxの学習　プロジェクトの中での方向性をひとつに絞るために話し合いを行った。そこで、楽器の演奏経験や音楽に対する知識を持たないユーザーでも、簡単に演奏した気持ちになれるツールの製作を目的とすることが決まった。それに合わせてメンバーをアイデア班とプログラム班というふたつのグループに分けた。アイデア班はユーザインターフェイスやいろいろなデザインを担当する。もう一方のプログラム班はプログラミングやシステムの管理などを担当することになった。　また、そのテーマ設定をもとに、前提として必要な知識であるMax/MSPの基本的な使い方を全員が学習することで、成果物に対するイメージを具体化させていった。 5月　Max とWiiリモコンの接続　昨年のプロジェクトの最終成果物を参考にしながら、Max/MSP とWii リモコンを接続させることができるようになった。また、Max/MSP とWii リモコンの接続によって、x軸とy軸の値を取れることを確認した。さらにそのMax/MSP とWii リモコンを接続させるシステムを理解することによって、今年度の成果物に利用することができるようになった。 FLASHを用いたプロトタイプ作成 5月　FLASHの技術の習得　アイデア班に所属することとなった。そこで、前期成果物のユーザーインターフェイスのプロトタイプを製作するため、まずはFLASHの基本的な知識と使い方を学習した。その際、情報ライブラリで借りた参考書などをもとに学習を進めた。またFLASHの基本的な知識と使い方の学習と平行して、ActionScriptについても同様に、参考書などを使って学習を行った。 6月　FLASHによるプロトタイプの製作　同じ班の田中を中心として、FLASHを用いたプロトタイプ製作の手伝いなどを行った。まずはインターネットでFLASH とMax/MSPの接続方法について調査し、その調査結果を利用したプログラムをFLASH とActionScriptで製作した。　次にFLASHを使用して、成果物の実際のメニュー画面と、値を表示するための画面を作成した。同じアイデア班のメンバーでデザインについての意見を出し合った。その結果をまとめ、それをモデルとして実際の製作を行った。メニュー画面では曲の選択を行って、それに見合った画面に進めるようActionScriptでプログラムを作成した。また、値を表示する画面では、Max/MSPから読み込んだ値を車の速度メーターなどを参考にして製作したメーターで表示させることにより、直感で認識しやすいようにした。こうして出来た製作物をプロジェクトメンバーに見てもらって意見をもらい、それを改善していくことによって中間成果発表会でのプロトタイプを作成した。中間発表の準備 7月　全体の流れの把握、ポスター文章考案　中間成果発表会に向けての準備が開始された。まず成果物についての全体的な仕組みを理解し、それをプロジェクトメンバーで共有した。　次に、今回の中間成果発表会で実演する事柄や仕組みをもとに、昨年度のプロジェクトポスターを参考にしながら、ポスターに何を書くかなどを決めていった。そして作成したスライドなどを実際に使用して、中間発表の練習に励んだ。活動方針の設定 8月　後期活動方針の設定　中間成果発表会で指摘された問題点などを元に、プロジェクトメンバー全体で集まり、活動方針の変更を行った。そこで、以前のようにピッチやダイナミクスを変動させるツールでは音楽表現をしているという意識にさせることはできていなかったと考え、後期の成果物では、楽曲の旋律（メロディ）を自由に変化させることで、音楽表現を行うことのできるツールを作成することに決定した。 9月　具体的な成果物の設定　楽曲のメロディを自由に変化させることのできるツールを作成することに決定するにあたって、まずどのような製作物にするかを具体的に話し合った。そして、楽曲のコードからおおまかなキーを判別し、適したスケールを判別するようなツールを製作することが決まった。　それに伴い、プロジェクト内のグループの構成や割り振りを変更した。前期では、アイデア班とプログラミング班の２つのグループ分けだったが、後期では理論班、インタフェース班、プログラム班の3つでグループ分けを行った。私は、ソフトウェア開発で必要な音楽理論、スケールの理論、コード理論についての学習を行い、どのような演奏を行ってもきれいな旋律を奏でることのできるソフトウェアのアルゴリズムを開発する、理論班に所属することとなった。スケール・コード理論の学習 10月　コード理論とそれに基づくスケールについての学習　まずは、後期製作物で最も必要となる一般的な音楽理論をおおまかに学習した。その中でも、音楽理論に基づくコードやスケールについては、最終成果物に役立つと考え、重点的に学習を行った。その際、Webページや文献などを参考にしながら学習を進めた。そこで、楽曲におけるコード、スケール、アボイドノートの意味や役割についてなどをおおまかに学んだ。　さらに、それらの学習をもとに、コードやスケールの判別方法の道筋を立て、それを実現させることのできるように研究を行った。音楽理論に基づくアルゴリズムの開発 10月　リアルタイムでの楽曲に使用されているコード判別　学習した理論を応用して、リアルタイムで和音を読み取り、そのコード名を判別することのできるアルゴリズムの開発を行った。考えられるいくつかの方法を考察し、メンバーと話し合った結果、最終的には和音の中で一番低い音であるルート音を元に、他の和音を構成する音がルート音とどれだけ離れているかを数値的に読み取ることで、コード名の判別ができるという結論に達した。また、3和音の場合と4和音の場合に分けて考えて、それぞれの和音の構成を表計算ソフトを使って表にまとめることにより、その関係性を伝えやすくすることができた。　この開発にあたって、他大学の研究室のホームページもしくは文献などを参考に開発を進めた。 11月　コードが決まった場合におけるスケール判別　上記と同様に、学習した理論を応用して、コードが判別できた際に、スケールを判別して除外すべき音を省き、nanoPADに適切な音を振り分けることのできるアルゴリズムを開発した。今回の成果物の場合、コード進行から楽曲全体のキーを判別し、そのキーを元に各コードに対応したスケール判別をするといったような大掛かりなスケール判別は行わず、楽曲全体のキーをあらかじめ定めておき、コードに対応したスケールの判別とアボイドノートの除外だけを行った。また、コードとスケールとアボイドノートの対応を表に書き起こしておくことにより、プログラム班がプログラムを行ううえでコードとスケールの関係をわかりやすく伝えるようにすることができた。　この開発にあたって、Webページや文献を参考に開発を行った。成果発表準備 11月　成果発表会ポスターとプレゼンテーション用スライド製作　最終成果発表会に向けて、ポスターのなかの理論班の部分を執筆した。また、発表のときに使用するスライド全体の構成を考え、スライド製作に取り掛かった。そして、プレゼンテーションでは実際に演奏も行うことが決まったため、どのように演奏すれば成果物の魅力を活かせるかなどを研究し、最終成果発表会での発表の練習も行った。 (文責：飯田) （下村）終下村京平前期活動の課題の設定 4月　開発するソフトウェアについての目標決め　本プロジェクトで開発するソフトウェアの内容についての議論、またはそれぞれの役割について決めていった。課題、目標の設定にはかなりの時間を費やし、議論を行った。音楽経験のあるメンバー、ないメンバーの意見をまとめることが難しかった。活動するにあたって、作業を行いやすいように二つのグループに分けることとなった。プログラミング班とアイディア班の二つのグループに分け、プログラミング班では、ソフトウェアのプログラム全般を担当し、アイディア班ではインタフェース全般を担当することになった。自分はアイディア班のメンバーとなり、主にインタフェース開発に取り掛かることになった。また、昨年本プロジェクトに在籍していた先輩にMax/mspについて教えていただいた。インタフェースの研究・開発 5月　インタフェースの研究　ソフトウェアに使用するインタフェースについて研究を行った。上旬は、グラフィック・ユーザー・インタフェースで使用するFlashのためにAction Scriptの学習を行った。中旬には、使用するコントローラーについて話し合いを行った。話し合いの結果、現在存在するコントローラーを使用することに決まり、その中からWiiリモコンを使用することになった。しかし、そのままWiiリモコンを使用するのではユーザーが思うままに操作ができない、またはWiiリモコンの送る値を正確に読み込まない可能性があるということで、Wiiリモコンを取り付けるためのインタフェースを開発することに決まった。下旬にかけては、作成するインタフェースについて考え、どのようなもので作成するか、どのような形にするかなどを話し合いを行った。Wiiリモコンの傾きの角度（ラジアン）の値によってダイナミクスやテンポを変化させるため、ユーザーが操作することによってWiiリモコンが左右に回転するようなインタフェースを作成しなければならなかった。そのため、Wiiリモコンが落ちることのないように回転させるにはどのようにするべきかを考えた。 6月　インタフェースの開発　インタフェースの作成に本格的に取り掛かった。　インターフェイスの具体的な形を決めるために、１００円ショップ等でフリスビーやワイヤーなど使えそうなものを買ってきて、簡易版のコントローラーを作成してみた。そこから具体的な形を導いた結果、円盤を２枚設置しその２つの間の軸の部分にWiiリモコンを固定すると、Wiiリモコンのロールの動きを先ほど述べたような指揮を振る動きに変換可能であると考えた。また、卓上で操作することも仮定し、ワイヤーだけでパーツ同士を固定するのではなく、しっかりとした土台が必要だということもわかった。ここから、インタフェースは主に木材を使用し、作成することが決定した。そのため、必要である木材や部品を自分たちで調べ、集めた。土台となる板やWiiリモコンを収納するための箱を作るための木材、ユーザーが握る部分の木材、土台と操作する部分をつなげるためのネジやL字型の金属部品など多くのものを集めた。集めた木材を加工し、組み立てインタフェースを完成させた。その後、プログラミング班の完成させたソフトウェアに対して、インタフェースを利用したときに、インタフェースを利用しないときに比べWiiリモコンのラジアンの値がしっかり読み込むことを確認した。その後、プロジェクトメンバー全員で話し合った結果、作成したインタフェースに「ロールコントローラー」という名をつけた。中間発表会 7月　中間発表準備、中間発表　中間発表会に向けて準備を行った。プレゼンテーションの練習、またプレゼンテーションの中で行う演奏の実演の練習を重点的に行った。中間発表会の役割をそれぞれ決め、中間発表会に臨んだ。中間発表会では自分たちの発表は全体を通して、うまくいったと思える。また、発表会には多くの方が見に来てくださり、多くの意見を頂くことができ、とても良かった。その後は、中間報告書の作成に取り掛かった。後期活動の課題の設定 9月　後期活動の目標決め　後期の目標として、前期に作成したソフトウェア「Music Fuzzy」を改良するか、または新しいソフトウェアを開発するか話し合いが行われた。中間発表会で頂いた意見などを参考にし、新しいソフトウェアを開発することとなった。内容は、簡易的な演奏システムの開発である。そのためには音楽の知識が必要であるため、音楽理論を学習する理論班を担当することになった。コード・スケール理論の学習 10月　コード理論・スケール理論の学習　開発するソフトウェアには音の判別が必要であるということで、それに伴う音楽理論が必要だった。そのためにはコード理論・スケール理論の学習が必要であり、それについて詳しく説明されている書籍やウェブサイトを検索した。まずは、コードというものがどのようにして構成されているかを学習した。コードは基本的に三つの音で構成されたものと、四つの音構成されたものがある。また、コードの構成には決まったルールが存在することがわかった。コードは数多く存在するが、コードのベースとなる音である根音さえわかれば、ほかの音が根音からどのくらい離れているかによってコードの呼び名が変わることがわかった。そのため、コードについてのアルゴリズムを構成することができた。スケールについては、スケールがどのくらい存在し、どのように構成されているかを学習した。スケールもコードと同じように数多く存在することがわかった。構成にはルールが存在するがそれをまとめるのがコードに比べかなり難しかった。 11月　コードの構成のまとめ、曲作り　上旬は、引き続きコード理論・スケール理論について学習を行った。下旬には、プログラミング班との話し合いの結果、スケールの判別をし、コードの判別を行わせるのは難しいということで、スケールの判別を行わないようになった。そこで、スケールは一般的に知られている「ド・レ・ミ・ファ・ソ・ラ・シ」で構成されているCのメジャースケールのみを使用することとなった。コードの判別を行わせるために、Cのメジャースケールで不協和音になることのないコードをまとめた。3和音と4和音で構成された使用可能なコードをそれぞれまとめ、その情報をプログラミング班に渡した。その後、最終発表会のパフォーマンスで使用する楽曲の作成を行った。ソフトウェアが音の判別を行える曲を作らなければいけないため、楽曲のスケールはCのメジャースケール、コードはCのメジャースケールの中で不協和音にならないコードのみを用いて作成した。最終発表会 12月　最終発表準備、最終発表　上旬は、最終発表会に向けて準備を行った。プレゼンテーションを作成し、全体でプレゼンテーションの練習、またプレゼンテーションの中で行う演奏の実演の練習を行った。最終発表会では、多くの方が見に来てくださり、自分たちの発表も上手くいき良かった。下旬は、最終報告書の作業に取り掛かった。全体でそれぞれ役割を決め、確認を行った。（寺井）(終) 寺井明日実テーマの話し合い・決定 4月　テーマの話し合い　　これから同じプロジェクトの仲間として活動していくメンバーと初顔合わせをした。プロジェクトについての説明を受け、テーマについて大まかに話し合った。 5月　テーマの決定　アイディア班とプログラム班にグループ分けをしてプログラム班へ配属になったが月末までは合同で活動した。4月に話し合ったテーマについてもっと具体的な内容を話し合った結果、複数人で合奏できるようなものを作るということに決まったソフトウェアの開発 5月　MAX/MSPの学習　去年のプロジェクトの先輩にMAXの基本的な使い方を習った。最初はＰＣのキーボードがピアノの鍵盤のようになるプログラムやMIDI の再生をするプログラムを作成した。月末はグループに分かれてC++で MAXのオブジェクトを作成する方法を習った。 6 月　ソフトウェアの作成　1つのPCに複数のWii リモコンを接続するのではなく1つのPCにつき1つのWii リモコンを接続することにした。PC間通信でWii リモコンの値を送受信してMIDIのパラメータを操作することに成功した。最初は Wii リモコンの値を取るのには先輩方が作成したpro10wiiを使用していたが、それを元に不具合を修正して pro16wiiを作成した。中間発表会の準備・練習 6月　中間発表会の準備　グループ内で更に開発担当と中間発表準備担当に分かれ中間発表準備担当になった。中間発表の内容を大まかに決めた。全員でソフトウェアの名前をMUSIC FUZZYに決定した。完成したプログラムの実験を行った。 7月　実演の練習　中間発表は演奏の担当になった。楽譜やピアニストの動画を参考にしながら演奏の練習をした。発表担当者の練習を聞いて改善したほうがいい部分を指摘しあった。質疑応答で質問されそうな内容とそれに対する回答を考えた。後期の作成物についての話し合い・決定 8月　後期の活動についての話し合い　後期の活動内容についてプロジェクトメンバー全員で話し合った結果、後期の活動は前期に作成したMUSIC FUZZYの機能の拡張を行うのではなく新しく別のツールを作成することに決定した。また、前期よりも表現の幅を広げるために旋律の操作を行うことが出来るものにすることを決めた。プロジェクト内のグループ構成は前期よりも細かくすることにし、理論班、インタフェース班、プログラム班の3つに分け、プログラム班へ配属になった。プログラム班内では更に役割分担をし、C++の担当となった。夏季休業中の課題が与えられ、プログラム班のメンバーにはMUSIC FUZZYのプログラムを理解することと、ツールの作成に必要とされる技術の基礎を学習してくることが挙げられた。コードを判別するプログラムの作成 9月　sortcodeの設計　作成ツールの大まかなアルゴリズムを図に書き、プログラム班内でそれぞれ担当する箇所を決めた。8月に決めた役割の通り、Max/MSPだけでは処理することが困難である部分をC++で作成することとなった。流れている伴奏のコードを判別するプログラムであるsortcodeのアルゴリズムを考え、設計を行った。値の保持のためにマルチスレッドモードを用いる方法を調査した。　 10月　sortcodeの実装　図にしたアルゴリズムからsortcodeのコーディングを開始した。書いたソースをコンパイルすると大量のエラーが検出されたため、エラーを消す作業を主に行った。ソースの書き間違いによるエラーよりも設定によるエラーが多かったため、解決方法を調べた。特に値の保持に必要であるマルチスレッドモードを使用しようとすると更に大量のエラーが検出され、エラーを消すことが困難になり、マルチスレッドモードを用いなくても済むプログラムの作成を検討した。 11月　マルチスレッドを用いないバージョンの作成　sortcodeのインレットを増やし、値の保持をMax/MSP上で行うというマルチスレッドモードを用いないプログラムの試作品を作成した。プログラム班内で話し合った結果、時間の都合上マルチスレッドモードを用いたバージョンを完成させることは困難であると判断し、用いないバージョンを採用することにした。試作品を改良し、理論班が作成した表を基に4音のコードの判別を可能にした。実際にMax/MSP上で動作テストを繰り返し行って改善点を修正し、sortcodeを完成させた。他メンバーのサポート 11月　umdecodeの修正　担当部分であったsortcodeを完成させた後は他のメンバーのサポートを行った。プログラム班の他のメンバーが作成したumdecodeの修正と機能の追加を行った。調和する音の出力が4音分のみであった部分を6音分の情報を出力するように修正した。また3音のコードにのみ対応していた部分を4音のコードにも対応できるように修正した。ボタンを押して演奏している最中に流れている伴奏のコードが変化すると音が鳴り止まなくなるというバグが発見され、そのバグを修正するためにコードが変化したら1を出力し、変化しなければ0を出力するというサポート機能を追加した。発表会の準備・練習 12月　ポスターの作成・プレゼンテーションの練習　発表会に向けての準備を始めた。スペースに配置するポスターに載せる図の作成、文章の作成、文章の英訳を行った。同時進行で発表に用いるスライドの作成とプレゼンテーションの練習を行った。後期はプロジェクトのメンバー全員がプレゼンテーションを行うことが出来るように担当を決めた。他のメンバーの前で実際に発表を行うという練習を繰り返した。（文責：　寺井明日実）（ファジ）（終）茅野裕馬方向性の決定・ソフトウェア開発 4月　プロジェクトの方向性の決定　プロジェクトの方向性を決定するためにプロジェクトメンバー全員による話し合いを行った。プロジェクトのテーマの定義が広く、方向性を決定するためにかなりの時間を要したが、昨年の成果物であるwii musicの操作を簡易化し、複数ユーザで操作ができるものを製作する事に決定した。通年のテーマとしては楽器の演奏経験の無いユーザが音楽の表現をより自由に体験できるソフトウェア、及びインターフェースの開発を行うという方向に決定した。 5月　プロジェクト全体のグループ分け・開発技術の習得　プロジェクトメンバーをプログラム班・アイディア班の2つに分割して作業を行うこととし、私はプログラム班に所属する事に決定した。　まず、開発環境はMAX/MSP とC++、Flash を使用する事に決定してたため、昨年のプロジェクトメンバーにMAX/MSPによる開発方法の基礎、及びMAX/MSP とwii リモコンの連携方法について教えていただいた。それと平行して参考書を読み、MAX/MSP とC++の開発技術の習得を行った。また、中間発表に向けた成果物に関係すると考えられる物に関する技術の調査を行った。 6月　プロトタイプ開発・中間発表成果物製作　5月に引き続き開発技術の習得、関連技術の習得を行いつつ、中間発表に向けたプロトタイプの開発に着手した。具体的には、wiiリモコンとMAX/MSPの連携部分の開発、MAX間通信の実装、MIDI制御部分の実装を行った。プロトタイプの開発はプログラム班の他のメンバーと協力して進めていった。　プロトタイプの開発の開発がある程度終了した段階で、中間発表の成果物の製作にとりかかった。開発開始当初はメンバー全員で行っていたが、最終的には中間発表報告書班と成果物班に分かれての作業となり、私は成果物班に所属する事となった。成果物製作・中間発表準備 7月　成果物製作・中間発表にむけたパワーポイント作成及び発表練習　6月末から7月頭にかけて成果物の製作を行った。具体的には、FLASH-MAX間通信で、ソフトウェアが異常終了してしまう問題の解決や、最終的な実装、打ち込んであるMIDIデータの修正等を行った。　成果物の製作が終了した時点で、プロトタイプが作成してあったパワーポイントを完成させ、中間発表における発表の練習にとりかかった。中間発表の前半で実際に観衆の前で話す役に決まったため、話す内容や実際にどう伝えれば観衆がわかりやすいのかを考え練習し、実際の発表に臨んだ。後期活動方針の決定 8月　後期活動方針の設定　中間発表で指摘された問題点などを元に、後期活動方針決定を行った。前期に作成しMusic Fuzzyには操作対象が楽曲のダイナミクスとテンポのみであったことに起因する、自由度の低さが問題として挙げられたため、楽曲の旋律をある程度自由に変化させることが出来、かつ操作の難易度が低いツールを作成することに決定した。それに伴い、プログラム班、インターフェース班、理論班の3つにグループを分け活動を行うことに決定し、プログラム班に所属することとなった。ツール基礎部分に関する考案８月　夏期休暇中の学習及びシステム基礎部分に関する考案　夏期休暇中に、開発に使用するflextやMAX/MSP、C++の学習、後期に開発するツールの基礎部分に関する考案を行った。学習はMAX/MSP、C++を使用したソフトウェアシンセサイザーの開発を通して行った。ツール基礎部分に関してはインタフェースをどのようなものにするべきなのか、ツールのおおまかなアルゴリズムの流れ、それに必要となる各プログラム部分には何があるのか、その各プログラム部分の処理を高速化するためにはどのような方法があるのかといった事を研究した。 9月　ツール開発に関する基礎部分の設定及び担当の振り分け　ユーザーインターフェースにどういったものを使用するのかや、ツールを具体的にどういったものにするのか、プロトタイプはどこまでのレベルのものを作成するのかといった事の設定を話し合いによって行った。それが決定した時点で、夏期休暇中にある程度考えておいたアルゴリズムを元にプログラム班のなかでどの部分の開発を担当するのかを振り分けそれに関する学習を始めていくこととした。私はコード判別後にそれを受けてどの音を割り当てるのかを出力するプログラムを作成した後に残った部分のプログラムの開発及び他のメンバーを助ける役となった。ツール開発 10月　担当部分の開発　コード判別後にそれを受けてどの音を割り当てるのかを出力するプログラムを作成を中心に行った。開発はC++で行いflextを使用することによってMAX/MSP上で動くエクスターナルを開発することとした。通常のC++としては合っている記述でも、MAX/MSP上で動かすためには使えない記述などがあり開発に時間がかかってしまった。 11月　他メンバーのサポートやMAX/MSP上での開発　担当部分の開発が終了した時点で、他メンバーのサポートや残った部分の開発に着手した。具体的には、プログラムチェンジ部分、オクターブシフト部分、ダイナミクスコントロール部分、FLASH－MAX/MSP間の通信部分、MIDI楽曲の先読み込み部分である。他メンバーのサポートは、本来実装しようとしていたアルゴリズムが使えなかったので、代替のアルゴリズムを考案した。 12月　各種バグの修正　開発の8割が終わった時点で各種バグの修正を行った。伴奏のコードが変化したときに、nanoPADへの割り当てが変わることに起因する音が止まらなくなってしまうバグや、演奏時の演奏動作から発音までの遅延バグ、Flash側で情報が更新されないバグ、演奏時に何度か再生を行うとソフトを巻き込んで落ちてしまうバグ等があったため、他メンバーと協力して修正を行った。　最終発表に向けて 12月　発表用楽曲の作曲や発表練習、最終発表　発表に使用するための楽曲が必要だったため、FL STUDIOとDominoを使用して、CメジャースケールでMIDI楽曲を作曲した。演奏者が弾きやすく表現もしやすいようにリズムがわかりやすいような曲になる様意識した。また、最終発表ではプレゼンテーションを行う役も割りあたっていたため、聴衆に対しわかりやすくなるように考え、発表練習を行った。　最終発表では前半第2回目の発表を担当したが、おおむね好評で発表を終えることができた。東京発表にむけて 1月　東京発表にむけての準備　東京での発表がきまったため、更にユーザーが演奏しやすくなるようにコード変更時の最初の演奏音をコードの構成音になるように改良をおこなったり、安定性の向上を図るなどの改善をおこなった。また、1対少数人での説明が予想されるため、そのようなときにどう説明をおこなうのがわかりやすいのかを意識して説明練習をおこなった。終わったら名前の横に「終」 2010-01-06T15:57:34+09:00 最終報告書　第1章 http://www23.atwiki.jp/musicprog16/pages/25.html 2010-01-06T15:54:26+09:00