電子十二影坊 (Dodeca Propeller)

長嶋 洋一


概要

電子十二影坊 (Dodeca Propeller)は、 メディアアートフェスティバル2008(MAF2008) にて発表展示したインスタレーション作品 (制作 : 長嶋洋一 + 任田沙恵 + 小畑海香)である。
SUACメディア造形学科のメディアアート展示プラットフォームである「12画面CRTパネル」を用いて、 オリジナル製作のハードウェアから12画面のリアルタイムCG映像(NTSCビデオ信号)を生成し表示する。 外部センサとしてMIDI入力に対応し、MAF2008においてはMIDIフットスイッチおよび会場のサウンドに対応して、 リアルタイムCG生成のパラメータを変容させた。
ハードウェアシステムとしては、Parallax社のPropellerプロセッサを13個搭載し、 8CPU内蔵のPropellerプロセッサによるソフトウェアによって全てのリアルタイム描画処理を実現している。 12画面それぞれに対応した12個のスレーブPropellerとともに、1個のマスターPropellerはMIDI受信による リアルタイム・パラメータ処理を制御した。

展示風景

システム

「トランジスタ技術」誌に掲載した参考Propeller回路図は これこれである。
基本的にはこの単純な応用として、以下が、現段階での"Dodeca Propeller"の回路図である。 実際には将来的な拡張のために、12画面のスレーブPropellerが、それぞれ上下左右のPropeller (画面を外れた場合にはラップアラウンドした反対側に対応)と情報交換するための 双方向信号線を配線してあるが、 今回はこの機能は実現しなかったので、回路図から省略してある。

 

  システム外観写真 

制御Max/MSPプログラム

MIDIパラメータとしては、(1)6ビットずつ2ブロックにエンコードした「個々のPropeller画面のON/OFF」情報、 (2)12個のスレーブPropellerに共通の6ビットリアルタイムパラメータ、 (3)12個のスレーブPropellerに共通の6ビット「パッチ」情報、の3種類を送るだけである。 以下が今回の展示に用いたMax/MSPパッチである。

マスターPropellerプログラム

マスターPropellerは、MIDI受信を担当するCogのプロセスとともに、 (1)6ビットずつ2ブロックにエンコードした「個々のPropeller画面のON/OFF」情報を 12ビットパラレル出力して12個のスレーブPropellerのON/OFFビットに出力、 (2)12個のスレーブPropellerに共通の6ビットリアルタイムパラメータを6ビットパラレル出力して 12個のスレーブPropellerの「パラメータ」ビットに出力、 (3)12個のスレーブPropellerに共通の6ビット「パッチ」情報を6ビットパラレル出力して 12個のスレーブPropellerの「パッチ」ビットに出力、 という動作を行う。
以下が今回の展示に用いたPropellerプログラムである。

スレーブ12Propellerプログラム

12個のスレーブPropellerは、NTSCビデオ信号出力をソフトウェア合成するCogのプロセス、 グラフィックライブラリ処理を行うCogのプロセスとともに、 (1)マスターPropellerからの1ビットの「個々のPropeller画面のON/OFF」情報により描画ルーチンをスキップ、 (2)マスターPropellerからの6ビットリアルタイムパラメータを受け取って描画ルーチンに反映、 (3)マスターPropellerからの6ビット「パッチ」情報に対応して、12個の中で自分に対応したマッピンクテーブルを 参照して該当する内部パッチ(描画ルーチン)に割り当てる、 という動作を行う。
以下が今回の展示に用いたPropellerプログラムである。 なお、この12個のスレーブPropellerのCG部分は全て、「任田沙恵 + 小畑海香」によりデザインされた。

課題と展望

もともと「PropellerのソフトウェアCG生成でどこまで出来るのか」という素朴な疑問からスタートした インスタレーション制作であったが、思いの他、Propellerのシステム開発は単純容易であり、 今後のメディアアートのプラットフォームとしての可能性を実感できた。

システムを追い込んでいく段階で直面したのは、Propellerの最大のデメリットである「メモリの制約」である。 最初は12個のPropellerだけで別にMIDIを受信するCogを起動する、という実験を行ったが、 MIDI受信のFIFOが共有メモリ領域となるためにレイテンシに問題があり、この方式は断念した。 そしてマスターPropellerを増設して、MIDI受信専用処理を行い、パラメータとパッチはそれぞれ6ビットの パラレルバスとして共有する、というあまり美しくない方式となったが、これによりレイテンシは完全に解決した。

CG描画の処理を全てスレーブPropellerの内部RAMに搭載できれば問題なかったが、 これが実際にはメモリフルというコンパイルエラーとなり、最終的には12個のPropellerごとに、 使わないCG処理をコメントアウトする、という内部的には美しくない対応によってようやく実現できた。 これはCGプログラミングのテクニックによって半分は解決できるものの、Propellerの本質的制限として 理解して取り組む必要がある。

また、グラフィックライブラリは共有RAM上の限定されたエリアとして定義するために、 CG描画プログラムのバグにより該当領域を越える描画アクセスを行った場合、 RAMのそこにあるプログラムを上書きして破壊し暴走する、というなかなか面白い現象に遭遇した。 限られたメモリを最大限に活用できればPropellerの能力は生かせるが、 プログラムをROMでなくRAMに置くPropellerではバグはシステムを即死させる、 という古来からのマイコンの本質に直面する意義も大きいものであった。

Propellerのspin言語は、グラフィックライブラリを活用することで、学生でも容易に 数理造形プログラミングを行える、という教育的な意義を見出せたことも収穫である。

今回は時間的制約から実現できていない機能として、既に配線済みである、 「それぞれのPropellerが上下左右のPropellerと通信する」という機能をソフトウェアに組み込めば、 12画面を全体として1画面のように横断するアクションを実現できる筈であり、 機会があればこの方面に発展させた新しいインスタレーションにも挑戦してみたい。

Propeller日記

MAF2008

27虎レポート