エンジニアが関わるパフォーマンスアート作品での裏側
はじめまして、ハコスコリードエンジニアで必要あれば何でもやってる@rinsyan0518です。 HHKB Professional2 Type-Sが愛用で、VSCode/Vimが主な開発環境です。
今回は、基本的にエンジニアは私一人で開発している「The Mirror」、「Neighbor」について、エンジニアから見た考えなどについて簡単に触れていければと思います。 それぞれの作品はシステム的にはほぼ同じものが使用されているため、制御する機材が多い「The Mirror」のシステムを中心にシステム構成から感じたことまで書いていきます。
実装要件
基本的なシステム要件については省くと以下の4つがあります
- 各機材を手動で変更する必要がないこと
- 「初期化」と「開始」以外に操作者は考えなくて良いこと
- エンジニア以外でもパラメータが調整できること
- エンジニア以外でもシーケンスの変更が可能なこと
「各機材を手動で変更する必要がないこと」については、幸いMIDI、TCPなどで外部制御が可能な機材が多いため、機能要件に合い外部制御可能な機材を選べば問題なさそうでした。また、「「初期化」と「開始」以外に操作者は考えなくて良いこと」についても、機材すべての制御がPCから操作するようにすれば問題なく動作させられます。
それ以外については以降で書いていきたいと思います。
システム構成
まず、コンバーターなど細かいものは省き、システムとして大まかに以下のような役割を持ったものが使用されています。 具体的な機材名などが書けないのは、ほぼ毎回どこかが変わっているため決まっていないからです。
（矢印は有線、無線など何かしらでその機材と繋がっていることを示しています）
カメラ →→→→→→ Videoスイッチャー →→ モニタ
↓ ↑ ↑
遅延処理ユニット→→↑ ↑
↑ ↑
↑←←←←←← メインPC →→ 照明
↑ ↓
制御端末→→↑ HMD(+PCもしくはSP)
メインPCに作品のシーケンスがあり、必要なタイミングで各機材のプロトコルに合わせてメッセージを送るようにしています。 切り替えのタイミングがシビアであったりメッセージの送り先が多くならない限りは、すべてのステートを管理するものは1つで行ったほうが、考えることが減るので不具合等原因を追いやすいです。
Max/MSPがメインPCの中で中央に位置するソフトウェアとなっており、ステートの管理と他の機材との通信はMax Patchを中継するようになっています。 （Max/MSPっぽい使い方ではないとは思います笑）
選定した理由としては以下です。
要件にあった「エンジニア以外でもパラメータの調整ができること」、「エンジニア以外でもシーケンスの変更が可能なこと」があるため、1が主な理由で選定しています。しかし、現在はシーケンスについては修正に手間が多かったためらMax/MSPから外に出し別のソフトウェアで管理されるようになっています。
私としては、2番目の理由として5の理由が大きかったです。 私があまりMax/MSPを触ったことがないこともあり、Max Patchでオブジェクトとオブジェクトを繋ぐのが慣れることができなかったため、ラップして問題ない処理はmxjで書いてしまいます。また、複雑なことを書いていると、ラインが多くなり処理が追いにくくなるので、mxjで書くのが普段と変わらないので楽ができます。
気をつけていること
体験型の作品であるためというわけではないですが、主に気をつけていることについてです。
機材、システムが置き換えやすいこと
必ず同じ構成で毎回行えるとは限らないため、ある箇所が別のなにかに変わったとしても、他の機材やシステムに影響が無いようにする必要があります。 例えば、メインPCをmacOSからWindowsにしたり、遅延処理ユニットを専用の機材からmacOSで実現したりなど過去にあったことは様々です。その中でも、特に変更が多かった箇所としてはHMDで、「Nuxus 5」→「iPhone 6 Plus」→「iPhone 8 Plus」→「HTC VIVE」です。
このように、そもそもOSが変わることもあるため、PC/SPで扱うものはクロスプラットフォームに出力できるものを使用し、足りないものはプラグインを作るように開発をしています。 またSOLIDのOCPということではないですが、、、Max/MSP含めてソフトウェアはインターフェースさえ同じであれば中の処理を気にしなくても良いようには気をつけています。
シーケンス開始後もマニュアルで対応できるようにしておくこと
「Neighbor」で発生したことがあるのですが、センサーがドリフトして期待してた方向の映像が表示されていないことがありました。 その際は、過去の映像でないタイミングでマニュアルで調整したりすることで、ある程度正常に動いているようにしていましたが、テスト中は起きなかったことが本番では起きることはよくあることかと思います。 そのため、期間との兼ね合いもありますが、、ある程度は回避できる手段を持っておくことも大切と思っています。
システムが落ちないこと
当然といえば当然ですが、可能な限り体験中に落ちないことは目指しています。今のところ、本番でiPhoneが熱暴走で止まったこと以外はない(はず)です。 iPhoneが熱暴走をしないギリギリで、気温が高い中でも冷やすために少し水を付けてサーキュレーターにあてるなどしたのはいい思い出です。
これに対しては、基本的にはテストするしか無いと思っていまして、CPU／メモリと気になるところに差し込んでいるログを主に確認するために「展示1日あたりの時間」をテストし続けたりしてます。サービス開発しているときと、そこまで変わらないかと思います。
展示作品であるあるだと思うこと
いくつかの経験からなんとなくよく思うことです。
環境での問題
Wi-Fiに関しては可能な限り5.0GHzを使用するようにしますが、端末依存で使用できない場合などは周辺の情報を確認して調整することが必要になるかと思います。 また、HTC VIVEのときでもベースステーションに干渉するようなものが近くにないか目に見えないものに気を配るケースが多いことかと思います。 そのため、想定外の動作をしている場合は、開発したものが原因だけなく、環境が原因についても考慮に入れて、考えることが必要です。 （無駄かもしれないような知識でも何でも持っておくと意外と役に立つケースが存在するのは、こういうときなのかもしれません。）
システム起動手順
長期間での展示は、会場での動作確認など必要なことが終わると、ほとんど会場から離れてしまうため、毎日のシステム起動は現地の方にやっていただくことが多いです。 そのため、起動手順については、基本的に簡単にできるよう心がけてはいますが、複数の機材やソフトウェアを使用していると、どうしても起動順に依存関係が生まれることがあります。 それが原因で、最初のシステム起動がうまく行かずに開始できるまでに時間がかかることがありました。
このことから思うことは、手順の誤りで発生する異常系動作を把握しておくことが大切です。もちろん、それ以外の発生する可能性のあるシステム外の異常系動作は可能な限り、対処方法も含めて想定しておけると良いと思っています。
終わりに
ハコスコではこのようなパフォーマンスアート作品にも携わっております。 こういった機会がまたありましたら、ブログとして掲載していくことや、今回は触れなかった技術的なことにも今後触れていこうと思います。 それでは最後までお読みいただきありがとうございました。
