2,000年度森基金研究成果報告

イベント駆動による汎用MIDIライブラリの製作

                                                                                                            政策メディア研究科修士課程二年 89932621 西野裕樹


1 開発結果報告


  現在のところ、項目2で後述する計画の変更点などの理由から、当初の予定されていたUSBカメラセンサーとそれを使用したデモ作品は完成していない。しかしながら、既にライブラリ本体の基本部分の開発は終わっており、今後ドキュメントの整備およびいくらかの新規クラスの追加を行った後、報告者本人のホームページ上など公開する予定である。なお、現状のソースコード及びドキュメント草稿は以下のようである。

 現状のソースコード                (lzh windows98  Metrowerks社コードウォーリア上で開発)
  ドキュメント草稿(執筆中)       (pdfファイル

上記のソースコードおよびドキュメント草稿は、まだ非常に簡素なものであり、これだけでは本ライブラリが想定ユーザとしているプログラミング
初学者には不充分である。このため現在、詳細なクラスに関するドキュメントおよびチュートリアルなどの執筆をつぎのプロジェクトとして計画している。


2 計画の変更点について



    当初の計画に基づき開発を行ったが、開発時に以下のような問題が発生したため、開発は多少遅れることとなった。
  また当初の計画にも部分的な変更を行った。
 
    ・ハードウェアの故障におる開発の一時停止

   開発に際し、使用していたPCの故障が初期に頻発し、修理などに合計2ヶ月ほどが必要となった。
     そのため、このぶん開発のスタートが送れた。
   またHDクラッシュによりソースコードの大半が失われ、再コーディングにやはり2ヶ月ほど必要となった。
 

    ・プラットフォームをLINUXからWINDOWSに変更した

      当初予定していた開発のプラットフォームをLINUXからWINDOWSに変更した。これは以下の理由による

      @ライブラリの性格上、種々の新規デバイスの追加が予想される。このため、現状でドライバの提供されている機器の少ない
         LINUXではライブラリの目的を充分に満たせない。

   A主にプログラミングに習熟していないアーティスト達を基本的なターゲットにしている。そのため、初心者にも敷居の高くない
    統合開発環境を提供しているWindowsを開発環境に選んだ。


3 基本的なアーキテクチャについて


既に執筆中のドキュメント草稿でも多少述べられているが、開発の際に実際に採用したアーキテクチャを以下に示す。

上図は今回開発したライブラリのもっとも基本的な構造であり、ユーザーが自身の開発の際に意識する必要のある最も基礎的な部分である。

ライブラリの基本的なアーキテクチャとしては、まずこの二つの基底クラスが上げられる。
この二つの基底クラス、すなわちAbstractMessageReceiverクラスと、AbstractMessageクラスは、両方とも純粋仮想クラスとなっている。
AbstractMessageReceiverクラスにはreceiveMessageという純粋仮想関数がメソッドとして存在しており、このメッソッドに対してAbstractMessageクラスから継承されたクラスへの参照を引数として与えることにより、イベントの駆動が行われる。

実際のAbstractMessageの子クラスには、例えばMIDIデータを扱うためのクラス群などがあり、AbstractMessageReceiverクラスの子クラスにはMIDI入出力のためのクラスがある。たとえば音符の出力を扱うAbstractMessageの子クラスをMIDI出力のクラスのreceiveMessageメソッドに与えると、このメソッドはあたえられたメッセージの種別を確認し、そのためのデフォルトのハンドラを呼び出す。そして実際のMIDIデバイスから音の出力がおこなわれる。

つまるところ、この二つの純粋仮想クラスは、一方はライブラリ中ではイベントを駆動するメッセージの雛型であり、他方は、そのためのハンドラの雛型である。C++の継承の機能を利用して、適度な抽象度をもつインターフェイスを形成しているといえる。このため非常に柔軟で拡張性に富むと同時に、既存のクラスを再利用しやすい形態になっている。

実際にユーザが新しいクラスを作成したい場合は、上記のように既に用意されているクラスから継承し作成する事によって、あたらしいクラスの追加を用意に行えるようになっている。

しかしながらこれだけでは、適切なフレームワークを提供しているとは言えない。
この上記の枠組みだけでは、既存のクラス自体の再利用や拡張の可能性を提供しているとしても、それらがアプリケーションで実際に使用される際の、柔軟性がまだ不充分であると考えられる。

このため下記のようなルーティングのアーキテクチャを加えた。
 

多くの場合、インタラクティブアートでは再利用可能なオブジェクトは頻繁に見られるといってよい。しかしながら、今上に述べたような雛型だけでは、その再利用の可能性はまだ低くとどまってしまう。何故なら、既存クラス間の関係は多くの場合、インタラクティブアートが実際にどのような設計を行われるかによって変化してくるからである。
このため、上述の設計のみでは、各オブジェクトが互いを「知っている関係」になければいけないため、オブジェクト間の結合が非常に強く密になってしまう。このためVRMLなどで採用されているような、だがより柔軟なルーティングのアーキテクチャを採用した。
その恩恵として、各オブジェクトはお互いにたいして完全に隠蔽される事となり、オブジェクト間の結合は弱まり再利用性は非常に高くなった。
 

上記がルーティングアーキテクチャを説明したものである。各々のオブジェクトが実際に「知っているの」のはRouterオブジェクトに限定されている。RouterオブジェクトはSingletonパターンを利用して実装されており、インスタンスは一つに限定されている。また、AbstractMessageReceiverクラスのコンストラクタ内でRouterオブジェクトへの参照をPrivateのメンバ変数に格納して使用しているため、プログラムを行うユーザ自身はこのような機構に対しては、あまり注意を払わなくて良い。実際にユーザが行うべき事は、アプリケーションの初期化メソッドでルーティングのアーキテクチャに対してルートの設定(メッセージ配信の道筋の設定)を行うだけである。また配信/受信の際にはルートにつけられた番号で配信先を区別する事が出来る。つまりAオブジェクトがあるメッセージをルート番号1で送り出した場合はBオブジェクトのルート番号2にルーティングおよびC、Dオブジェクトのルート番号10にルーティングを行い、Aオブジェクトがルート番号2で送り出した場合はEオブジェクトのルート番号1のみにルーティングすることなどが可能である。
このような機構からオブジェクトは互いに隠蔽されたままで、複数のオブジェクトを容易に識別し通信する事が出来る。
これにより再利用の可能性は一段と高められる事となる。

また以下にスケジューリングの機構を述べる。

インタラクティブアートのプログラミングにおいて、初学者にもっとも大きな困難をあたえるのがタイムスケジューリングをどのように行うのかというのが問題である。Periodicなタイマ割り込みや、イベント配信の遅延をどのように実現するかが問題となることは稀ではない。これらの処理を実際のリアルタイムで行われる他の入出力と同時に実現しなければならないためである。

今回開発したライブラリではRouterオブジェクト同様の手法でユーザからは完全に隠蔽されたタイムスケジューリングのオブジェクトが、この処理を行っている。実際にはこのオブジェクトは他のクラスから遅延配信を依頼されたメッセージのコピーを自身の内部リストに保持し、指定された時間に他のオブジェクトに配信する。

その他特筆すべき機構としては、上記のような機構をまとめてアプリケーションフレームワーク用のクラスにパックしている事である。実際にユーザが自身の作品を制作するさいには、このクラスから継承して行えば上記のような機構を使用したアプリケーションを簡便に行う事が出来るようになっている。これによりユーザは自身の必要とする最低限のプログラミングだけを考えればよいことになっている。

アプリケーションフレームワーク用のクラスは現在のところもっともプリミティブなものであるが、今後の開発で向上させていく予定である。



4 今後の課題


・GUIを担当するクラス群の追加

 現在のところ本ライブラリにはまだ、GUIを作成するための環境がない。これは実際には、C++言語ではGUIが使用に組み込まれていないため、プラットフォーム依存の度合いが非常に高い現在のGUIの開発環境を考え、現状ではJAVAなど他の言語でGUIを作成して連携する事を念頭に置いているからである。しかしながら、今後なんらかの機構を用意し、簡便にGUIを作成するフレームワークを考える事は考えなければならない。

・音響処理の機能がない。

 本ライブラリではインタラクティブアートのアルゴリズム部分のためのフレームワークを提供する事が主眼であり、音響処理などは外部の他のアプリケーションや機器によって行う事を考えている。しかしながら音響処理機能の追加は容易な設計になっており、今後の計画に加える事を考えている。

・関連ドキュメントの整備

 詳細なクラスの説明や初学者向けのチュートリアルなどの整備に関しては、現在計画中である。