第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月06日 16:00
