元の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月07日 17:37
