ショーコントロール・照明制御の技術屋 株式会社ハイパーアクティブスタジオ（HyperActiveStudio） のWebサイトです。こちらは、HyperActiveStudioの関わった現場・機材について、そしてh_inoのblog的メモです。

前回紹介したコントローラフレームワークがカタチになりました。
BBCというパッケージ名をつけてみました。

チラシなんかもつくってみたりして＞＞BBC cutsheet

よろしくお願いいたします。

いろいろあって、このページ、２ヶ月近く放置してしまいました。
（簡単な活動ご報告は左コラムのtwitter窓でご確認を．．）

今年のはじめから温めていた、インタフェース／コントローラのオリジナルフレームワークがようやくカタチになってきました。フレームワークというのは、なにか形の定まった製品を作るわけではなく、カスタムメイドの土台を共通化する試み、という感じです。

ポイントはユーザインタフェースの部分。
PCを置けない／置きたくない／そこまでじゃない現場だけれども、エンドユーザさんにある程度操作してもらうためにわかりやすさは必要、ということがあったりしますよね。
そこでタッチパネル搭載。別にiPhoneがどうのではないですが、タッチパネル的操作感はますます当たり前になる世の中。これが使えればユーザビリティはかなりアップしますよね。

納入システムの付加価値のひとつとしても認められることも期待します。もちろんコストありきの昨今ですが．．．

まだ、ハリボテ状態なので、引き続き作り込んでいきたいと思います。

i Player 2 をコアとしたコントローラを先日納めたのだが、タイムラインで組んだシーケンス時間とスタンドアロンでの再生時間がずれているような気がして、気になっていた。
マージン見てシーンの切替をおこなっているつもりだったのが、お尻が切れてる感じというか。だとすると、結構、10分で1分近くとかズレるのか？？などといぶかしく思い、確かめてみることにした。
カラキネさんから i Player 2 をお借りし、実験をしてみる。
カラキネさんのお話でも「ズレる」とのことだったので、いかほどのものかと．．．

で、計ってみると。
負荷が10球でも100球でも、固定色でもレインボウでも、1エフェクトでも細切れエフェクトのつながりでも、50fpsでも30fpsでも、10分のシーケンスは10分ジャストなのだ。±0.1〜0.2秒出ているけど、手ストップウォッチなので当たり前、カッチリジャスト10分なのである。

前回の e:cue butler での計測も同様だが、結局、レンダリングしてレコードするタイプのリプレイユニットなので、コンテンツがどうであれレンダリングさえ正確にできてしまえば、あと再生時間を左右するのは再生機のクロックのみ、ということなのだろうか。

この一台しか計測していないので、個体差があるものなのかどうかわからない。
でも、そんな個体差が大きく出るようなクロック（発振源）をわざわざ持つことなんてないでしょ．．．


てことは、現場での違和感は別のところに原因があるのだ。
マズイ、気になる〜もう一回見直そう．．．

またまたPLC＞e:netネタです。
KEYENCEのPLCに手を出しました。最上位機種だとEtherポートが本体内蔵なのです。
注目に値するのは、こいつ、「KVスクリプト」というよくできた言語が載っていて、ラダーを書かずにプログラミングできるのです。
イーサネット使って細かいことするなら、高級言語っぽくプログラミングできた方が楽でしょうからね。
いままで実験してきて来週現場投入するPanasonicのセットより、コスト的には高くはつくのだけど、期待通りのパワーなら．．．

というのが、まさに証明されました？
なにせ、ある案件が、急に仕様が変わって、3日間でシステムを組み直さなきゃならなくなった。パナのセットを取り寄せてる時間もないし。（明日、仕込み）
初めてとっかかって、1日でとりあえず動かせるようになりましたよ、スクリプトありがて〜。

いや、よっぽど、e:cue butler xt を買っちゃおうかと思いもしたのですが．．．
結論的には、開発？が進んだのでこっちでヨカッタ。かな。

しかし、先日のMEDIALONの記事ともあわせて、ショーコントロールの道、どう歩いていくかな．．
まあ、適材適所だから、選択肢は広いほうがいいとは思うけど。

いや、お勉強になりました。やはり？小型のスタンドアロンプレーヤのクロックって精度高くないんですね。
e:cue butlerをスタンドアロンで使って、頭だけ出して曲と同期できるか？という課題があり、ストップウォッチで計ってみました。

3secのキューｘ60＝3min のループをサンプルに計ります。

まず、butlerをアウトプットデバイスとして、PCから出力。

　1回目：2:59.97　2回目：2:59.99　3回目：2:59.95

手ストップウォッチですし、こんなもんでしょ。
次、butlerにエクスポートしてスタンドアロンで再生。

　1回目：3:08.68　2回目：3:08.65　3回目：3:08.71

がーん．．こんなにズレるんだ．．．
再エクスポートしてみる。（butlerはレコーダ系の記録にしかたなので、エクスポート時にレンダリングをしている）

　1回目：3:08.75　2回目：3:08.76

もう一回エクスポート。

　1回目：3:08.71　2回目：3:08.65

エクスポート（レンダリング）ではばらつかないわけですね。
butlerの内部クロックがタイムコードレベルの精度は持っていないって解釈になりますよね．．
では、個体差はどのくらいあるのでしょう？

別の個体で同じループを走らせる。

　1回目：3:08.70　2回目：3:08.70

もう一回エクスポート。

　1回目：3:08.75　2回目：3:08.75

へええ．．．個体のバラツキがない．．？
じゃあもう一台．．

　1回目：3:08.70　2回目：3:08.78

個体のバラツキがないな．．．
これら3台のbutlerは購入時期も年単位で離れていて、基板の作りも違ったりしているので、製造ロットも全くちがう。

てことは、キューリストのタイムを組むときに何らかの補正をしてやれば、スタンドアロンでも走るときには安定して走る？

では、ループの組み方を変えてみましょう。
30secのキューｘ6＝3min のループで。

　PC出力：3:00.02
　スタンドアロン：
　個体1−1回目：3:08.66　2回目：3:08.75
　個体2−1回目：3:08.72　2回目：3:08.75

そうきますか．．．キューの数なんかではあまり影響を受けないのか？
そりゃそうか、レコーダタイプなんだから、レンダリングした時点で1本のDMXストリームに違いはないんだから。
もしここで差が出ていたら、PC（Programmer）のレンダリングの時間精度が悪いってことになっちゃうもんな。

では、30secのキューｘ12＝6min のループで。

　個体1−1回目：6:17.48　2回目：6:17.45
　個体2−1回目：6:17.45　2回目：6:17.40

3min=180secが188.7secになったってことは、104.8%に延びたってこと。
6min=360secが377.4secになったってことは、104.8%に延びたってこと。

これはアレでしょうか、「CPUのクロック使うと、正確なんだけど、どうしても実時間とズレるの。でも、5%もいかないぐらいだから、やさしく許してね（はあと）」という感じなんでしょうか。

てことは、Programmerで同期取ってキューリスト組んで、タイムを95.4%に補正すれば、けっこうイケルってことなのだろうか．．．

えー、今日はここまで．．．

あとは、温度特性とかあるかな？
でも、butler稼働しているときはけっこう熱持ってるので、外気温の影響をモロに受けるよりマシな気が。

e:cue Lighting Application Suite (LAS) が5.0から5.1へバージョンアップしてからすでに1ヶ月以上が経っており、弊社もひととおりPCをアップデートさせたので、とりあえず What's New メールでも自分のために読んでおきましょうか。

けっこう大きめのフィーチャーがあるのですよね、今回のバージョンアップは。というか、e:cueのバージョンが0.1上がるのはけっこう大きいバージョンアップなのでしたっけ。

　まずは箇条書きまとめ

・RDM対応
・Art-Net対応
・DMX入力および出力のレコード機能
・統合環境としてレベルアップしたPatchelor5.1とe:scriptウィザード
・NCT(NetworkConfigurationTool) がプログラマー内に統合
・UDP(イーサネット)メッセージの送受信によるトリガー機能
・e:scriptに50以上の新しいコマンド
・マクロがバックグランドで走る

というようなところが、今回のフィーチャーになります。

　RDM対応

DMXラインを使った双方向通信プロトコルのRDM。じわじわと浸透してきていると聞きますが、ここにもその現れが。
DMXアドレスのオートアドレッシングや機器の設定情報取り込み、ステータスのモニタなどの機能が実現できるRDMですが、今回は機器の状態のモニタリング機能をサポートしました。
他の機能についても、今後のリリースで追加対応していくと書かれています。


ちなみに、この機能の使用にはエンタープライズ版（要ダングル）が必要です。

　Art-Net対応

イーサネット出力がArt-Netに対応しました。通常のエンタープライズ版では1ユニバースのArt-Net出力が可能です。
それ以上のユニバース数については、Art-Netアップグレードというオプション商品が用意されているようで、8/16/32/64ユニバースの単位で購入できるようです。



　DMXレコーダー機能

入力デバイス excite+ から入力されたDMXストリームを、キューリストにスタックされるキューとしてレコードすることができます。
同様に、現在のプログラマーの出力（ステージアウトプット）もレコードすることができます。



　Patchelorの進化

パチェラーには多くのフィクスチャと新機能が追加されており、よりシンプルに複雑なマトリクスパッチが組めるようになっているとのこと。
そしてテスト機能により、パチェラー内部からマトリクスパッチのテストができるようになりました。
さらに、背景に画像ファイルを取り込んでフィクスチャのレイアウト調整が容易になった、など全般的に底上げされ、統合環境的なソフトウェアに進化している感じです。



　そのほか、

・新しい e:script ウィザードはマトリクス上でのエフェクトコンテンツをより簡単に作れるようになりました。

・他の機器とのイーサネット通信機能、UDPパケットの送受信に対応し、他のシステムにトリガを送ったりトリガコマンドを受け取ったりできます。

・NCTがプログラマ内に統合され、システム内のエンジンやインタフェースのIPアドレスや設定項目を簡単に操作することができます。

・e:script言語に50以上の命令が追加され、上述の新機能のスクリプト上での実行を可能にしています。

・複数のマクロを同時に走らせることができるようになりました。これにより、たとえば外部機器との通信などの常に走らせておく別プロセスなどの実装が容易になりました。


というようなことが、リリースメールの内容でした。

前々回の「スクリプトでキュー！4」で書いた、PLCからe:cue butlerをイーサネット越しにたたく、というシステムのランニングテストを始めてみました。
単に、延々、キューリストを切り替えてループしていくというのをやっていくだけですが。テストといっても、トリガを拾い損ねたらわかるようになっているわけでもなく、単に走らせているだけなんですけどね。ときどき抜き打ち的に観察して、ちゃんと動いているかな、ってだけで。どっちかというと、自分に対するちょっとした自信つけってとこです。


あらためて、なんでイーサネットでトリガを送りたいか考えてみました。
今はbutlerをたたいてますが、PCへトリガを送ることまで含めて考えます。イーサならそれができるし。

で、ひとことで言えば、汎用性とシステムのモジュール化、ということになるでしょうか。

1.システム組みの自由度の点から、汎用性の高いモジュールを汎用的な接続でつなぐシステムにメリットがある。
2.PCを核としたシステムを考えるときも、アフターメンテを考えて、モジュール化＋汎用接続としたい。
3.汎用接続（通信）といえばちょっと前まではRS-232Cだったが、今はイーサネットへの移行が進んでいる。

1.についていえば、クローズドなシステムはなるべく使いたくないんですよね。メーカーが囲い込んでるやつ。
「あとちょっと○○」なんて時にどうにも高くついてしまったり、そういう自由度が少なくなりがちだし。システムの先行きをそのメーカーに委ねることになりがちだし。
それから、既成のシステムつかっているだけでは、誰でも同じことができるわけで、「システム屋」としては商売的に何にもアドバンテージをとれませんしね。（「デザイナー」としてなんかなら別ですよ）

2.についていえば、常設のシステム組んで何がイヤって、後日トラブって走り回るのがイヤですよね？そのとき、いかに簡単にシステムを立て直すか？
最も早い立て直しは、そっくり入れ替えです。でも、PCベースのシステムなんかだと、PCをあらかじめ用意（セットアップ）しておかなければ、すぐに入れ替えは難しいということが多かったと思います。PCのモデルチェンジは早いし、OSもバージョンアップするし．．数年経ってからPC入れ替えなんて、イチからやるみたいなもんです（自分が忘れているせいも大きい．．）。
いままで納めてきた中には、自社でまったく同じ状態にセットアップした予備機を保管している物件や、同様の予備機を現場に置いてきてある物件があります。それでもヒヤヒヤし続けるのです。

できれば、そのとき入手できるPCに「ソフトウェアとデータだけ入れれば同等品ができあがり」それを「コネクタひとつでつなぎ替えればOK」という状態に持って行きたい。
PCと接点のシステムで言えば、PCにハード（ボード）を入れるという手がありますが、これはやりたくない。ボード自体が汎用性とは正反対の存在だし、初期設定など考えると、その「PCモジュール」はカスタムメイドということになってしまいますからね。

3.についていえば、最近のPC、特にノートではRS-232Cはレガシーポートってことで装備なしなことからもわかるように、他で置き換え可能なものとなっています。つまり、イーサネットとUSBですね。
USBは汎用の通信プロトコルというのはないですから（ですよね？）、後継はイーサネットですね。
ソフトウェアがイーサ上の通信にネイティブに対応してくれて、ソフト的に送受部分がいじれるプロトコルが載っているような通信があれば、RS-232Cと同じように扱えます。
いまでは、RS-232Cをつなげる機器よりもイーサネットをつなげる機器のほうが多くなっているような気がします。（身の回りの狭い範囲に限って言えば、なんでしょうけど。）

おまけに、イーサネットなら、ケーブルは長距離引っ張り回せるわ、HUBでスター接続できるわ、通信として考えてメリットがいっぱいです。さらに、ありふれたケーブルで、説明ナシで電気工事屋サンに工事を投げられる。HUBはどこでも売っている。

e:cueについていえば、今回利用したe:netプロトコル上でe:comエミュレート、というのは、（半？）オープンな規格ですし、まだ追求できていませんが、最新のLAS5.1ではこれとは別にHTTPだUDPだOSCだとイーサネットベースの通信を積極的に取り入れようとしています。これが前述の「ソフトウェアがイーサ上の通信にネイティブに対応してくれて」ということですね。

長々と書いてしまいましたが、とにかく、これからの（制御）システムはイーサでつなぐ、ということになるんではないかなあと。まあ、DMXの世界でも、もはやArt-NetやACNを知らない人はいない（？かもしれない）わけで．．．


ちなみに、弊社がPLCに傾倒するのも、共通した理由です。モジュール化して置き替え容易、という。
PLCはラフに扱っても壊れない、小さなPCみたいなもんですから。制御用途に限って言えば。さらにモデルチェンジも、互換性の問題になるようなOSのアップデートもそんなにしない。
結局こういう考え方って、産業用途と同じなわけですよね。

次は．．．PLC＞Art-Netか．．？
（そんなこと書いちゃっていいのか？）

GongInternationalさんの別館サイトNatureGirlにて、弊社サイトをご紹介いただいてモチアゲられてしまったので、何か出さんといかんな〜ということで。
ArKaosのAudio-reactive Flashの話題。

GrandVJVariables.swf
GrandVJVariables.fla

ArKaosのForumあたりから拾ってきた、ActionScript用変数リストです。ArKaosの独自拡張ってことでOK？
ActionScriptにもサウンドを扱うクラスがあったりしますが、この拡張変数の方が圧倒的に特化していますネ。
（それと、テキスト関係の変数もアリ）

とりあえず、Flashは2Dエフェクトジェネレートだ！バナシは、今はここまでですかね．．弊社としましては（？）。
ちょっと、現場の関連もあって、PLC系の方に流れがち。

こんなもんつくりました。
何って、「PLCで直接e:cue butlerをたたくしくみ」です。

butlerってPCの出力デバイスとして使う分にはいいんだけど、スタンドアロンで使おうとすると、どうしても外部トリガ受けたくなるんですよね。でも受けられない。
受けるにはターミナル的な外部機器が必要になってしまいます。もしくは、最近出たbutler xtを使うか。
せっかくこんなにお手軽でパフォーマンスの高い製品、なんとかならんか、と思って早幾とせ？

写真の右上にある、イーサをつなげる一番安いPLCセットで、8接点入力でbutlerのQL1〜QL8をたたくという基本パッケージをツルシで作るとすると、9万円ぐらいの出し値（butlerは含みませんよ）になるかと思うのです。

でもそれだけだったら、純正のターミナルをつなげばいいとも。
こいつは「スイッチやセンサの入力を処理しながらbutlerをたたく」という案件でコストパフォーマンスが急上昇？すると思われます。よくあるパターンは、「演出のかかっている間はスイッチ入力を受け付けない」（先出し優先）や、それと後出し優先のミックス、時計でGoのタイムスイッチ的使い方など。
そのような処理では、弊社はほぼPLCを使ってしまいますが、カスタムメイドでPLCのグレードが上がったりプログラミング費用が発生したとしても、トータルでコストパフォーマンスが上がるように思います。

他にも特徴として
・LAN配線なのでお手軽＋HUBで自由に分配
・グループ分けできるので、ネットワークでまとめた複数のbutlerを個別にトリガできる（16グループまでだと．．）
・QLは99まで呼べる（らしい）

そのほか、タイミングなどの細かい部分のスペックチェックや、信頼性的なチェックなどはまだしていません。
まあ、信頼性的なものなどは、PLCの信頼性を疑うわけでもなく、e:netの仕組みはe:cueのプロトコルだし、残るはソフト部分のバグぐらいですよね。
スペックの確認は実験していきます。

いかがでしょう、ソリューションとして、けっこう使えると期待しています。

前回までのFlashバナシとはちょっと別ルートに入ります。
iPhone(iPodTouch) Appの「iCue」を試しました。
（スクリプトな内容じゃないように見えますが、予備実験ってことで。）

これは、サードパーティーが出しているe:cueのターミナルエミュレータ、つまり、e:comモドキなのです。
スタンドアロンのbutlerを外部トリガで叩く実験をしたかったのですが、トリガを出す機器としていくつかありますがどれも持っていないので、手近なところでこのアプリを使ってみたわけです。
iTunesStoreで2,600円しますが、まあ、機器を買うより圧倒的に安いので。

今日の収穫、なるほど、スタンドアロンのbutlerは、存在するQLだけe:comのFキーにダイレクトに反応するのね。
確認ヨシ。

「iPhoneからコントロール」にはあんまり興味ないんですが（あんまり実用にはならないでしょ？）、デモとかではウケるかもしれないですね。

「2次元のエフェクトは映像だ」「メディアサーバの上でスクリプト＝Flashでエフェクトを書く？」などと一月半ほど前に言い始めて、ようやくちょっとつつく。Arkaos+Flash編


ArKaos（MediaMaster）を実験台にして、スクリプトで汎用的、もしくはインタラクティブなエフェクトを書く実験をほんのちょっとだけ進める。

まずは、Flashかじりということで、LEDをドライブするイメージでレインボーチェイスっぽいことをやってみる。
これは、全然スクリプトとかではなくて、Flashのシェイプトゥイーンという機能を使って書いているだけ。
うん、いちおう、できるっぽい。

それから、もうひとつ細かいことで確認できたのは、ArKaosのライブラリの中で、Flashソースと映像ソースは分け隔てなく、どのライブラリフォルダに混ざっていても大丈夫そうだということ。

さて、サウンドアクティブを映像でやるには？と考えたときに、ちょっと目をつけていたのがMADRIXというグラフィカさんが（いちおう．．）扱っているソフト。

ちなみに、別系統としてはMax/MSP/Jitterとか、そっち系があるのだけど、映像レベルならまだいいのだろうけど、DMX出力なんて考え始めると大変ゴトになっちゃうので、まずは専用ソフトから。


VJっぽい見た目だが中身は全然違って、
制御対象は映像もいけるがLEDマトリクスに重点が置かれている。コンテンツもサウンドアクティブのエフェクト群の組み合わせを使うというところに重点が置かれている。スクリプトでエフェクトを書ける。キューリストもついている。常設用の冗長構成というかバックアップシステムも組める。

相当ニッチというかマニアックなコントローラです。
しかし．．いかんせん、ニッチすぎる．．マイナーすぎる．．．いや、ビッタリハマる物件があったら使ってみたいですよ、いまでも。


いま、いちばん身近にある（というか、他はまだ見られていない．．）メディアサーバ系のコントローラはArKaos。
ゴングインターナショナルさんが代理店さんになられましたし。
ちなみに、ここでArKaosとはMediaMasterバージョンのことをいいます。

で、コイツには、AudioFlashというサウンドアクティブのコンテンツがいくつも入っているのです。
なにー！フラッシュなのかー！とちょっとびっくり。なんの驚きかというと、フラッシュなんていうあまりに汎用的なプラットフォームでそれをやるのか、と。
調べていくと、FlashというかFlash内のプログラミング言語であるActionScriptにはサウンドを扱うクラスがあって、FFTもイッパツだ。（音の周波数分析する仕組みですね、これでスペクトラムアナライザとかやるわけです。一般的にはイコライザという言葉が（間違って）浸透しているやつですが．．）

うわー、映像とシームレスに扱えるメディアサーバの上で、汎用的な技術であるフラッシュでエフェクトを書く．．こりゃかなわないわ．．と漠然と思う。シェアのあるプラットフォーム上の汎用的な技術は進歩のスピードが段違い、マイナーでは太刀打ちできないって感覚．．．

このエリアでエフェクトをバリバリ使いこなすには、フラッシャー（って言う？言うよね？）になれってことか．．．
このメディアサーバ上で、意図するアウトプットを得るのに道はふたつ。映像（完パケorミックスできるからパーツでも）を作るか、Flashコンテンツを作るか。


で、まあ、AdobeのサイトからFlashの体験版なんかダウンロードして開いてみたわけですが。
（家の都合で遠出のいっさいなかったワタシはGWはこんなことをやっていたのだ．．）
うへえ、学生時代にCまでなので、20年近く経っているうえにオブジェクト指向は全然だし。

だいたい、仕事として考えて、自分がフラッシャー修行をすることはないよな（たぶん）。どうかな、ある程度理解して外注、というふうにしないと、本来の仕事できなくなっちゃいそうだもんな．．．

さて、オチというかいままでの成果として。

実は、ActionScriptのFFTはナマ音（マイク入力）にはかけられないことを知る。mp3とかのファイルになった音じゃないと解析できない、と。
じゃあ、ArKaosのサウンドアクティブ（9バンドスペアナとかがある）はどうなっているのか？

実は実は、ArKaosがFlashのサウンドアクティブ用に独自に変数を拡張（この表現で正しいのだろうか？）していることを知る。ArKaosはただのFlashプレーヤじゃないってことです。
ArKaosがここのところを進めていけば、フラッシュという媒介を使ってもっともっとインタラクティブなコンテンツをプレイできるようになるってことだよね？！（そういう開発をする方向かどうかは知りませんが。）

そうですか、そう来るのですか。スバラシイね、ArKaos。映像側から来るとその発想の方が自然なのかも。ていうか、フラッシュ＝アニメーション＝映像ってそのまんま。
上に例に出したMADRIXは自分たちでエフェクトを書く言語体系を丸ごと作り、その上で自らのエフェクトを書くということをしているのだと思うけど、まったく切り口が違う。作ったヒトの嗜好なのかな．．．

うーむ。
フラッシャー！オーイエー！

ずっと考えてたんですが．．．なんか、自分のお勉強もかねて、機材クエストというか技術クエストみたいな記事を継続して書けないかな．．と。
とりあえず、始めてみましょ。尻切れトンボの危険も大いにあるような気もしますが．．．まあ、気負わず。
「お勉強もかねて」なので、実践投入前なわけです。アタマでっかちとも言えるわけですが、鶏と卵ってことで。

さて、引っかかるポイントはいくつもあるのですが、そのひとつ、映像系について、ちょっと。

ちょっと前から、やっぱり映像を扱うようにしなきゃダメかな、と考えているのです。まあ、世の中というか業界の流れもそうなっているんで、そのまんまですが。

自分の中での、映像に至るロジックは次のようなもの。
コントロール（制御）のソースとして、エフェクトを扱ってきた。もしくは、もっとインタラクティブなものを求めてスクリプト的なものを扱ってきた。
LEDマトリクスというデバイスとか使い方（デバイスの形態と光点の粗密で幅広くとらえて）が流行っているし演出効果としても魅力的だ。
面的な制御対象に対するソースは？映像でしょう。ビデオ信号という意味ではなくて、生成モトが何であれ、面に提供するソースは映像というカタチになるのですね。
だったら、（従来の意味での）エフェクトも映像で考えなきゃ、スクリプト（で生成された出力物）も映像で考えなきゃ、ってことです。
先にLEDマトリクスと書きましたが、制御対象は何でもいいんです。逆になんでも制御できなきゃいけないんです。それが、一次元的なの制御じゃ足りなくなって二次元です、という言い方もできます。

DMX系コントロールソフトのパッチはマトリクスを扱うのは普通になったし、カラキネiPlayer3のエフェクトも二次元になったし、e:cueのエフェクトは二次元になってないけど映像プレーヤを取り込む方向ですしね。
いちおう前置きはこんなとこでしょうかね。

さて、シュミ的に「ただ映像出力です」というのじゃ面白くないので、ずっとストーカーしているジャンル、音調、サウンドアクティブ、このあたりを攻めてみたい。
映像で言えばビジュアライザーですかね、PCのメディアプレーヤで音楽鳴らせば映像がグリグリ動くし、ありきたりとも言えますが。
制御という切り口で見ればまだ面白そうな余地が残ってると思うんで。
まあ、冷静に考えると、それ何か仕事の役に立つの？ってことなんですが。


J-WAVE＋六本木ヒルズのSingingTowerにやられちゃったワタシが、はじめて仕事でまねっこしたのはe:cueのエフェクトを使ったAoyamaChristmasCircus。


この路線で。

さて、先日「e:cue がバージョンアップしましたねー」という記事を書いてから、特に仕事上でも進展無いままなんですが。まずはWhat's new のドキュメントを読んでみましょうか。

ホントはひとつづつ実験しながら書くのが正しいのでしょうが、まずは予習ってことで。あと、前バージョンと比較しながらコメントも付けたいところですが、前バージョンのすべてを把握してるわけではないので．．．間違いがあるといかんので控えときます。


　はじめに

メジャーバージョンアップなんで、そりゃすごい数の改良がなされていますよ、と。
ところで、なんで3.8から4.0じゃなくていきなり5.0なんでしょう？インパクト狙い？

　まずはプログラマ

プログラマがメインアプリであることは変わらず。それだけに、簡単にたくさんのコントロールをイイ感じでお届けする、大きな改良が施されていますよ、と。

　シーケンサ

5.0からの全く新しい機能というのが、このシーケンサでしょう。
これだけは画像引っ張っておきますね。


タイムラインですね。
キューリストコントロール、マクロ、フェードなどのイベントを登録できる複数のトラックを持つシーケンサを複数作ることができます。
さらに、それぞれのシーケンサは完全に独立しているので、バラバラにスタート、ストップして並行して走り、お互いに呼び出しもできます。

確かに、いままではキューリストでタイムを積んでいくしかありませんでしたからね、「ショーコントロール」的使い方には大歓迎って感じでしょうか。それこそ、ウチにしてみれば、PLC の必要性が薄くなっていく感じです。PC 入れられるような現場なら。

　butler xt と glass touch のサポート

新ハードウェアであるところの、butler xt とglass touch（コントロールパネル）をサポートするのは5.0からです。
butler xt のスペックについてはここでは深く突っ込みませんが、ひとつ、glass touch との接続である e:bus のマスタになる、ということがあります。glass touch を使うには butler xt が必要で、それらのプログラミングには5.0が必要、ということです。

glass touch は、オンラインでプログラマにつながっていればプログラマをトリガしますし、オフラインであれば、butler xt をトリガします。

と．に．か．く．butler xt が使ってみたいです。

　デバイスマネージャ

デバイスマネージャはいままでのショープロパティの1項目から独立しました。glass touch などの e:bus デバイスの管理もここからおこないます。

管理要素が増えてきてるってことですね。システムはより複雑なことができるキャパシティを備えてきているってことです。

　アクションパッド

ボタンやらフェーダやらのアイテムが整理されてすっきりしました。アイテム毎のプロパティをより素早く自由にいじれるようになったからです。
ページ間のコピー＆ペースト、プロパティの一括変更などの機能により、大きな（多要素の）コントロール画面をより簡単に編集できるようになりました。

アクションパッドのユーザインタフェースをパリっと使ったシステムを設置物件に入れてみたいなあ．．

　HTTP サーバ

webサーバ機能がついて、ブラウザからプログラマをたたけるようになりました。
これによって、LAN 上の PC から、または外部からインターネット越しに、プログラマをリモートできるようになったと。
近いうちのバージョンアップで、アクションパッドで作った操作画面を html に書き出す機能も付く予定とのこと。

これは、どうでしょうね、なんか面白いことできそうな気もするし、早くいじってみよう。まず思いつくのは iPhoneからリモート？

　パッチ

LED マトリクス的フィクスチャを考えたとき、いままでのパッチの概念は「単純なマトリクス（マス目）の上の何処」ということしか扱えていなかったので、（物理的に）フィクスチャの間隔があいているとか、置き場所がずれているとか、そういうことを考慮したようなエフェクトをかけるにはたいへんな労力が必要だったと。
新しいパッチファイルは、フィクスチャの（物理的な）寸法と置き位置の情報を含むので、上記のように複雑な配置をしたフィクスチャ群にエフェクトをかけるのも簡単にできます。
それに伴って、プレビューも新しく「マップビュー」という、実際のレイアウトに沿った見え方を表示する機能が搭載されました。

このポイントはパチェラの項目にも強く書かれています。

　メディアプレーヤ

2面目のメディアプレーヤが使えるようになりました。2つのメディアファイルを並行して走らせられます。（この恩恵に関しては、当方あまり経験がないのでよくわかっていません）
リモートメディアプレーヤがプログラマの中に統合されました。

　その他の変更

として書いてあるのは、
・ログが自動セーブになりました。あらかじめ設定したファイル容量まで自動的に取っておきます。
・ツールアイコンと画面構成がリニューアルして使いやすく。（画面構成はかなりキープコンセプトな気がしますが）
・Art-Net サポート（基本的にオプション追加が必要ですが−後述）
・セクション数8の制限がなくなりました。（フィクスチャの画面上でのグループ分けのセクションのことですね）
・ショーをセーブすると自動的にバックアップファイルを作ります。


　今回の大きなフィーチャーであるパチェラについて

プログラマのパッチの項にも出てきていますが。
いままでのパチェラは単なる（理論的なというか．．）マトリクス、しかも1セクション1種類のフィクスチャで構成された単純なものしか扱えなかったと。だから、自由な配置とか、縦横比とか、ノーマルなマトリクスじゃないものを作ろうとすると、たいへんな労力が必要だったので、そこんところを完全にリニューアルしたと。

今度からは、物理的な寸法を持ったフィクスチャを物理的な距離のある面の上に並べていくスタイルになりました。
置く場所も自由、回転も自由、複数の種類のフィクスチャを混ぜて置くことも自由、ドラッグアンドドロップでスイスイと、というわけです。

たぶん周りを見渡せば、ようやく今風、という感じでしょうか。

　Look & Feel

メニューがマイクロソフトオフィス風のリボンスタイルになっています。そしてそのツールバーのカスタマイズの自由度が高いことを強調してますね。

リボンってオフィスの方では賛否両論あるらしいですけど、どうなんでしょうね、当方は好きなんですが。

　ライブラリエディタ

パチェラとあわせてライブラリエディタも完全リニューアル、と。
新パチェラに合わせた＝寸法付きの、新しいフィクスチャを作ることができます。


　5.0からのグレード分け（ライセンス）について

いままでの standard と enterprise の「あいだ」に「elements」というグレードができています。
そして enterprise の上にアップグレードオプションとして、外部制御を無制限に増やせる「automation upgrade」と、多ユニバースの Art-Net 出力を可能にする「ArtNet upgrade」が販売されるとのこと。
このオプションってどういう販売形態なんでしょうかね？enterprise に後付け追加できるとうれしいですが．．．
これからマトリクス系やるなら、Art-Net は重要ですよね．．普通の enterprise でも1ユニバースだけ出力できる仕様らしい。

それから、従来とのライセンスの互換性についてですが、
・従来の enterprise ダングルで5.0 enterprise が使える
・5.0の enterprise ダングルで3.8 enterprise が使える
・5.0の elements ダングルでは3.8 enterprise は使えない
と書かれていますね。


と、長々でしたが、以上が what's new ドキュメントの中身でした。

画像はe:cueサイトより

いやー、ついに来ましたね〜。待ってましたよ〜。
本国サイトからオフィシャルリリースのメールニュースが入りました。

まず、butler xtですね、上の写真の。外部入出力の端子のついたゴツいルックスで、かっこヨイです。
RS232が直接入るってことで、けっこう、PCいらなくなる予感。いやもうホント。当方、PC使うときもPLCと組み合わせてPLCをアタマに使ったりするのですが、そのまんまPCがこいつに置き換わります、きっと。
DINレールスタイルなので、この赤銀（そういや、ウルトラマンカラー？）のbutler xtと白いPLCが並んで組み込まれている画を想像するだけでヨダレが出てきます（謎）。
いくらになりますかね〜。


プログラマーソフトも、メジャーバージョンアップして、まだインストールしてないですが、期待してます。
フリーダウンロードできて、旧バージョンがアーカイブ扱いになってるってコトは、現行ダングルで使えるってことかな．．？それだとひと安心。いや、グレードが細かく分かれるんで、まったく別の管理体系になるのかと思ってちょっとヒヤヒヤしてたんですよ．．．


ちょっとオシャレすぎる気がするglass touch壁付けコントロールパネルとか、LEDディマーなんて製品もオフィシャルリリースになったってことのようです。


というわけで、かなり興奮気味ですが、グラフィカさん、ディストリビューション頑張ってください！

プログラマ含めたLAS5.0をインストール＆テストランしてみました。

とりあえず、WinXP(SP2)でも無事インストール＆起動できたようです。（システム条件がXP(SP3)と書いてあったので．．．）　　そして、いままでのMMdongleでenterprise版が起動し、AutomationやAudioDSPが有効化されました。ひと安心。

とりあえず、デザイン的にはアイコン以外キープコンセプトのProgrammer内で、まったく見たことのないのはタイムラインのシーケンサというヤツですね。

おいおい、いじっていきたいと思います。今日はここまでだ．．．

某多目的ホール物件の相談にmileruntechさんを訪ね、照明におけるネットワークインフラのご教授をいただく。
メチャクチャ勉強になりました〜。これからを見るシステム提案にはネットワークは欠かせないです。コトバでいうと当たり前のようですが．．．

さて、あわせてCatalystについても教えていただく。ビックリである。
Catalystって、HighEndのムービングプロジェクターのイメージがいちばん（ミラーのヤツ）。
いまでは、メディアサーバーになったんでしょ？のイメージが二番。
でも、そんなモンじゃないらしい。
どう見ても、ワタクシ好みの（？）ショーコントローラなのだ。
いいなーこれ。使ってみたい、これ。現場やりたい、これ。
Macってのがハードルあるけど、Macにはdellがない（？？）ってだけで、毛嫌いする理由はないしね。
アドレナリンの出るブツである。

.

仕事で、e:cueのマクロスクリプトを書いています。
テキスト連ねたタイプのスクリプト書くなんて、10年以上ぶりでしょうか。（PLCのラダーは書いてましたけど）

ツールの「（かくれた）チカラを引き出す」とか「思い通りに動かす」というのは、動物的に快感があります。I've got the power な感じというか？

深い比較対象がないのでイメージですが、このe:cueのスクリプトはシンプルな構成で、メインのプログラマを補うという位置づけであると思われますが、使いやすくまとまっているのではないかと思います。うまい割り切り方というのでしょうか。
もっと使いこなしてみたい気がします。
そのような物件に当たってみたいですね。