Pd/GEM 環境の使用感


GEM（Graphics Environment for Multimedia)はMark Danksによって開発・配布されている、Pd(Miller Pucketteによる)のためのグラフィックスプラグインパッケージである。GEMはPdのexternalオブジェクトの集まりであり、ユーザーはGEMに用意されているオブジェクトを使用することで、OpenGLによるリアルタイムレンダリングのコントロールをPd内から行うことができる。

GEMをPdとともに用いることのメリットは、
 


ということが挙げられる。簡潔な書き方であるが、この2点のメリットは非常に大きい。このことは、例えばC言語などでスクラッチからマルチメディア作品を開発したことのあるユーザーであれば容易に納得できることであろう。X-Windows、MS Windows、Mac OS、その他、ウィンドウ環境でのプログラミングは、複雑ではないにせよ、記述しなければならないコードの量は決して少ないとはいえず、一言で言えば煩雑になりがちである。GEMの環境は、マルチメディア作家の寿命を延ばすことに貢献できる可能性があるかもしれない。

しかしながら、現在のGEMはまだ実験的なステージにあるものであり、実用を考える際にはクリアすべき課題が残っているように感じられる。筆者は音楽情報科学研究会の夏のシンポジウムにおける長嶋洋一氏との共同発表のために、Pd/GEMを用いたサンプルパッチの開発を行った。その際に感じた不便さをリストアップしてみる。

このうち、「ループを組んで…」の部分について補足すると、Pdでも配列(array)は使用できるので、予め配列にパラメータを格納しておき、select のようなオブジェクトを用いて下位のオブジェクトを順次選択しながら処理していく、といった手法は可能である。しかし、扱うオブジェクトの数が増えると編集作業が煩雑になるし、動的なオブジェクト数の動的変更という問題は残る。

このオブジェクト数の動的変更ということについていえば、予め上限数を設定してオブジェクトを作成しておき、必要な分だけをアクティブにする、という手法はもちろんあり得る。しかしこれはFortranやBasicのように動的なメモリ確保・解放に弱い言語で、使わないかもしれない巨大な配列を予め確保しておいてデータサイズの変更に対処しなければならなかった、というような暗い過去を思い出させるものである。Cのように動的にメモリ確保を行う方法にはガベージコレクションやメモリリークの問題が存在することも事実ではあるが、それはどちらかといえばOSレベルの問題であるし、なによりもマイコン＆アセンブラ上がりの人間には使いもしないメモリを占拠しておくという事態が心理的に耐えがたいという側面もある。

さて、以上は結局、
 

  1. GUIベースであるためのプログラミング手法の問題
  2. インタープリタベースであるための速度的な問題
の2点に集約されると考えられる。

これらの問題点に関しては、例えば

といった対処法が考えられる。例えば、生成するオブジェクト数をパラメータとして取り、各オブジェクトへのパラメータをリストとして受け取るようなexternal を書けばよい。実際にGEMにはparticle という、微粒子の噴水のようなイメージのアニメーションオブジェクトが用意されており、重力などをパラメータとして与えることができる。同様なことを自分で行えば速度の問題もある程度解決されると期待される。
パッチのコンパイルに関しては、externalの制作に比較して労力が大きいと思われるが、もし実現されれば速度的な問題はかなり解決されるだろう。しかし、多数のオブジェクトにムービーをマップしつつ、MIDI/audioといったタイミング的にシビアな制御を行う、という場合にはやはりまだ真っ正直にCなどのコンパイラベースでの開発を行うことになるのではないだろうか。
ネットワーク利用などによる分散環境という方向は、今後発展してくると期待されるが、現状では安定性や速度の面でやはり実作品への応用には不安が拭いきれない。
今後、ハードウェアの一層の高速化や、OSの安定度の進化などが期待通りに進めば、ここに述べたような問題点は過去のものとなるかもしれない。しかし、筆者にはそれはどうも「ゴド−待ち」のような気もするのである。