ezBlog

何かしらの効率化を求めて、スクリプトを書く時に、必ずと言って良いほど使うのは「繰り返し文」です。

 

「for」で始まる構文は、フッテージアイテムやレイヤーがひしめくAfter Effectsにおいては、必需です。私がプログラムの習得を開始した頃（ちょうど20年前くらいです）、繰り返し文とサブルーチン（ファンクション）の再帰処理を理解するのは、初心者の第１関門のようなものでしたが、初めて繰り返し文で大量処理した時の驚きは、まさにコンピュータを使う驚きそのものでした。

 

例えば、コンポジションの尺を変更する際、内包されているコンポジションの尺も伸ばさなければならない場合がありますが、After Effectsのスクリプトで、for文とfunction()を使えば、再帰的にコンポジションを探し出して、孫の孫の孫...のコンポジションでも行き着くところまで掘り進んで尺を伸ばす事が可能です。最上位のコンポジションの各レイヤーインアウトポイントを考慮して、尺伸ばしの不必要なコンポジションは対象から除外する‥‥なんていうことも、if文で可能です。

 

「総当たり」のような繰り返し文は、「for( var i=1; i<=app.project.numItems; i++){ ... 」みたいな感じで何かしらのアイテムのアイテム数をきっかけにループすれば良いですし、再帰処理をしたいのなら、「function setCompDuration(myItem) { ... 」みたいにテキトーなファンクション名を与えて、内部で「if (myItem instanceof CompItem){ setCompDuration(myItem); } else...」のように「自分自身（ファンクションから見て）を呼び出す」分岐を作れば、延々とコンポジションの階層を掘っていくスクリプトが出来上がります。

 

オブジェクト指向なんて最初から気負わなくても、リピート文やIF文、サブルーチンを使いこなすだけで、かなりの身の回りの効率化が計れますし、自分らの小規模作業グループの定番ツールも作れます。

 

 

 

今どきの人々は、iPhoneなどで気軽にアプリをダウンロードして機能を増やすことに慣れているかもしれません。しかし、自分たちの作業場で必要な作業補助アプリは、iPhoneのAppStoreでは入手できません。

 

最近の傾向を思うに、人々はスマホやネットで何でも便利な機能を手にできたように見えて、実は「プログラム能力の貧富の差」は格段に開いていると思います。

 

もし、コンピュータがアニメの制作現場を徐々に包囲して覆い尽くしていくのなら、プログラムやスクリプトの能力を持っている人間は、まさに「勇者の剣」を手にいれたようなものです。

 

TVPやクリスタの使い方講座も当座必要かも知れませんが、長い目で見れば、アニメ制作者のためのプログラム講座も必要だと感じます。

前回、プログラムは決して難しくないことを書きましたが、重要なことを書き忘れていました。

 

マニュアルの存在です。

 

addComp()などのメソッドやdurationなどの値の「固有名称」は、私が予知能力で知っているのではなく、ちゃんと「あんちょこ」、つまり「マニュアル」や「ガイドブック」「ヘルプ」があり、用語も全て記載されています。

 

After Effectsの場合は、After Effects 開発者センター内の、以下のPDFドキュメントになります。

 

After Effects CS6 Scripting Guide (PDF, 1.6 MB)

 

開発者センターもガイドブックも、開いてみればお判りのように、全て英語です。

 

結構多くの人が、「マニュアルが英語だ」というだけで、心が折れます。

 

でも、中身を読めば、英文としては大したことは書いてありません。詩的な表現も暗喩的な表現もありません。「my home」を「己の魂のふるさと」なんて読み解かなくても、マニュアルは充分に読解可能です。

 

義務教育の中学校レベルの英文法の知識があって、あとは「specular」「syntax 」などの専門用語をネット辞書で調べれば、書いてあることはほとんど解るでしょう。

 

 

今はアニメ業界でもほとんど全ての人が高校を卒業し、大学まで卒業している人も多いはずです。

 

なのに何故、英文を見ただけで怖気付くのか？

 

‥‥‥。要は、また「イメージに負けている」のです。

 

 

プログラムは「プログラムが解る頭の良い人だけが作れる」というイメージに負け、英文マニュアルは「英語がすらすら話せる人だけが読める」というイメージに負けて‥‥

 

「できない」と自分を過小評価する人間は、どれだけイメージに負け続ければ気が済むんだ？？？　‥‥というキツい言い方ではありますが、真実の話です。

 

英文の小説を読むわけじゃないのです。簡潔に機能やメカニズムを書き表したマニュアルを読むのです。‥‥そのどこに、難しさが潜んでいるのか。

 

しかも、皆の前で日本語訳して朗読するわけではなく、プログラム開発時の参考書として参照すれば良いだけです。

 

いかなる場面においても、人は「自分は苦手だと決めつけることで、自分の能力を低く制限し続ける」のです。英語やプログラムだけでなく、絵画や映像表現においても。

 

プログラム‥‥と聞くと、自己開発版のPhotoshopやAfter Effectsを開発する「無用に大規模なイメージ」を持ってしまい、英文‥‥と聞くと、英語のスピーチを同時通訳する「英語のスペシャリストのイメージ」を持ってしまい‥‥と、「できない」という人の多くは「イメージが極端」なんですよネ。

 

 

‥‥とはいうものの、50年近く生きてきて思うのは、「イメージの持ちかたも才能のうち」かなと思います。さらに言えば「自分の能力の解き放ちかたも才能のうち」‥‥と言いますか。

 

潜在的に能力を有していても、鍵を開けて門を開放する術を知らなければ、一生、自分の能力は倉庫の闇の中で眠り続けます。

 

中学・高校を卒業したのなら、マニュアルなど眺めているうちに意味はどことなく解ってきますヨ。

 

英文のマニュアルを「読めない」「わからない」という人のほとんど全てが、5分と経たずにマニュアルを閉じてしまう人でしょう。5分ではなく、まずは飛び飛びでも5時間は眺めないと、解るものも解ってきません。

 

自分の能力を阻害する敵は、外ではなく、自分の内にあり。

 

 

お母さんから生まれてくる時は、何のノウハウも技術も持っていないのです。あるのは、生存本能とお母さんへの連帯感だけ。生まれてきて開口一番、「お父さん、お母さん、初めまして。私が息子（娘）です。今後ともどうぞ宜しくお願いします。」なんて言うのか‥‥という話です。誰しも「おんぎゃあ」と泣くところからスタートするのです。

 

作画にしてコンポジットにしても、プログラムにしてもシステムにしても、自ら制限するのはナシでいきましょう。だって、泣くことしかできないところから、現在まで成長してきたんですから。

 

 

ソフトウェアを作るために、プログラムのコーディングをおこなう‥‥というと、いかにも難しそうに聞こえますが、まずは身近なところから着手すれば、さして難しいものではありません。何度も書きますが、「プログラムは頭の良い人だけが作れる、難しいもの」という「イメージに負けている」だけです。

 

もしAfter EffectsやPhotoshopを使っている人なら、ESTKで自動処理のスクリプトを作って実行してみるのが、余計なお金もかけず、気軽な気持ちで習得を開始できます。

 

ESTKを用いた、Adobeソフトウェア自動処理の一番簡単な実行方法は、

 

エディタでソースコードを書く

エディタ上で実行する

 

‥‥という２ステップです。

 

After Effectsを起動して、ESTKのエディタも起動して、実行した際の送信先を「Adobe After Effects CC....（自分の使用しているバージョン）」にすれば、おもむろにソースを書いて、おもむろに実行できます。

 

ESTKは「Adobe ExtendScript Toolkit CC」という名前のフォルダでアプリーケションフォルダの中にあります。ない場合は、インストールされていないので、Adobeから入手します。Adobe CCを使っている場合は、CCのマネージャーアプリケーションから入手できます。

 

 

 

 

簡単な例をば。

 

After Effectsで何らかのコンポジションを開いておいて（もしくは新規コンポジションを作成して）、タイムラインにフォーカスを入れておき、以下の１行スクリプトを実行すると、コンポジションの尺が12秒に変更されます。

 

app.project.activeItem.duration=12;

 

日本語にすると、

 

アプリケーションのプロジェクトの現在アクティブなアイテムのデュレーション（尺）を、12にする。

 

‥‥です。

 

ドット「.」は、日本語で言うところの「の」を表します。

 

「=」は「...を...にする」、つまり値をセットする役割を果たします。

 

 

app.project.activeItem.frameRate=24;

//アプリケーションのプロジェクトの現在アクティブなアイテムのフレームレートを、24にする。

 

app.project.activeItem.frameRate=23.976;

//アプリケーションのプロジェクトの現在アクティブなアイテムのフレームレートを、23.976にする。

 

 

構造は簡単ですよネ。

 

何かの値を変更したい時には、マウスとキーボードで直に操作するだけでなく、上述の通り、スクリプト文でも遠隔操作で実行できます。

 

では、今度は「メソッド」を使って、「何かを変更」ではなく、「新たに作成」してみましょう。

 

app.project.items.addComp("新規コンポジションの自動作成テスト",1920,1080,1,6,24);

//アプリケーションのプロジェクトのアイテムに、新規コンポジションを名前「新規コンポジションの自動作成テスト」横「1920px」縦「1080px」ピクセルレシオ「1.0」尺「6秒」フレームレート「24」の設定内容にて追加する

 

 

 

結果は上図の通り。新規コンポジションを自分の思う通りの設定内容にて自動作成できます。

 

もっとエスカレートして、新規コンポジションを作った中に、新規平面レイヤーを作成し、さらに１秒で2回転動くようにエクスプレッションを設定して、モーションブラーによる像の流れも付けてみましょう。

 

本文５行のスクリプトになりますが、文１行ずつの内容はシンプルなので、めんどくさがらずにじっくり読めば、読み解けるかと思います。

 

var myCompo=app.project.items.addComp("新規コンポジションの自動作成テスト２",1920,1080,1,3,24);

//アプリケーションのプロジェクトのアイテムに、新規コンポジションを名前「新規コンポジションの自動作成テスト」横「1920px」縦「1080px」ピクセルレシオ「1.0」尺「3秒」フレームレート「24」の設定内容にて追加し、その結果を変数「myCompo」にセットする

var mySolid=myCompo.layers.addSolid([0,0,1],"回転針",40,800,1,myCompo.duration);

//myCompo（新規作成したコンポジション）に、新規平面レイヤーを色「ブルー」名前「回転針」横「40px」縦「800px」ピクセルレシオ「1.0」、尺「myCompoの尺と同じ」の設定内容で追加し、その結果を変数「mySolid」にセットする

mySolid.rotation.expression="time*360*2;";

//mySolid（新規作成した平面レイヤー）の回転プロパティのエクスプレッションを「時間x360度x2回転」にセットする

myCompo.motionBlur=true;

//myCompoのモーションブラースイッチをオンにセットする

mySolid.motionBlur=true;

//mySolidのモーションブラースイッチをオンにセットする

 

 

日本語で読み砕いた文を付けるとゴテゴテとしますが、スクリプト本文はシンプルにまとまっています。以下のように。

 

var myCompo=app.project.items.addComp("新規コンポジションの自動作成テスト２",1920,1080,1,3,24);
var mySolid=myCompo.layers.addSolid([0,0,1],"回転針",40,800,1,myCompo.duration);
mySolid.rotation.expression="time*360*2;";
myCompo.motionBlur=true;
mySolid.motionBlur=true;

 

 

実際にAfter Effectsで実行してみると判りますが、一瞬でコンポジションが出来上がります。同じことを手作業でやると、手際よく操作しても30秒くらいかかるのではないでしょうか。コンピュータだと1秒以下です。

 

 

まあ実際は、回転する針を自動で作成するニーズなんて無いとは思います。これはあくまで「どんなことができるか」の軽いデモではありますが、これを発展させると、「背景とセルをテンプレートのAEPに読み込み作業コンポに配置し、セル素材にはタイムシートを適用し、素組みの状態を作って、然るべきカット名で保存する」なんていうこともできます。さらには、作業者のアカウント名と日時をデータベースに記録し、コンポジット作業情報を更新する‥‥なんていう「連続技」まで可能です。

 

自動でコンポジット作業準備が整えば、あとはまさに「人間の出番」です。

 

人間が、その美意識を最大限に発揮させて、かっこよく美しい映像を作り出すのです。コンピュータでもできるような準備などに時間を割くことなく、人間だけができることのみに人間のリソースを投入するわけです。

 

胸を打つシーンを想像できますか？　作風に応じた描線の駆け引きができますか？　美しい色を彩れますか？　刹那の空気感を表現できますか？　人の機微を汲み取りモチベーションや士気を鼓舞できますか？　‥‥コンピュータにはできないことばかりです。だから人間が必要なのです。

 

一方、コンピュータだけが可能な「正確さと速さ」があります。

 

カットの命名規則を決める、サーバのフォルダ構成を標準化する、データベースサーバを稼働する‥‥など、いろいろな下地作りは必要ですが、それがまさに作業現場のシステム化であり、IT＝情報技術の足場にもなり、結果的に作業の効率化にも繋がります。

 

やろうと思うからできるのです。やらなければ、何も始まりません。

 

 

これから先の未来は、デジタル作画、紙作画、3DCG、コンピュータ作画が入り乱れる「大混戦」の作業現場へと移行していきます。現場のハンドリングが今まで以上に大変になるのは解りきっています。

 

我々のスタンスは２つに１つ。ごまかし続けてさらに苦境に陥るか、積極的に迎え撃って勝ちを取りに行くか、‥‥です。

 

大混乱を迎え撃つには、現場の「プログラム苦手癖」を徐々に当事者自らが解きほぐして、人間とコンピュータの人馬一体で臨むのが肝要と心得ます。

 

コンピュータによって混乱する状況を、コンピュータの活用術にて相殺する。‥‥なんとも皮肉で痛快なことですネ。

 

 

 

表計算ソフトは作表のソフトではありません。表を用いて計算するソフトです。ですから、ワードプロセッサソフトの表機能とは根本的に異なります。

セル（枠）の数値を合計するなど、表内の数値計算をするのは、まずは誰でも思いつくことでしょう。表を自動で集計する「表と電卓が合体したものだ」とイメージするのは、作表より一歩進んだスタンスですよネ。

加えて、コンピュータのプログラムの要素を、表計算に用いるイメージを持てば、表計算はさらに頼もしい存在となります。

表計算ソフトを使うのなら、「作表＋数値演算＋プログラム」をイメージして活用することが、まずは何よりの足場となります。そしてさらなる発展を考えるのなら、表計算を外部とリンクする仕組みを取り入れても良いでしょう。つまり、最終的には「作表＋数値演算＋プログラム＋ネットワーク＋制作集団オンライン」という展望も見えてくるわけです。

そのためには、まずは表計算を、「作表＋電卓」以上の存在になるように、色々と使ってみることが肝心です。

表計算ソフトウェアはその気になれば、外部のアプリケーションから指令を出して、自動制御をも可能になりますが、とっかかりはセルに記述する「式」からスタートするのがプレッシャーも少ないので良いと思います。After Effectsで言うところのエクスプレッションのようなものですネ。

例えば、表の１列目にカット番号を記載する例を考えてみます。

まさか、手で１文字ずつタイプするわけにもいきません。カット番号を人間がいちいち手で入力していたら、何のためのコンピュータだよ！‥‥ですよネ。

誰もが「だったら、行番号をうまく利用できないかな」と考えることと思います。アニメ現場ですと、ABカット（Cut 100a, 100bなど）への対処はありますが、大半は行番号で対応できそうです。

=ROW()

これでOK。行番号をセルに表示してくれます。

「いや‥‥。表計算の１行目が必ずしも、カット１になるとは限らないんだけど‥‥」と思う人もいるでしょう。だったら、仮に表計算の４行目からカット番号が始まるのなら‥‥

＝ROW()-3

‥‥でOKです。行番号をオフセット（数値をスライドする）することなど、造作もないことです。

もしABカットが出た場合は、そこだけは手入力でかわして（ABカットの数なんて限られていますし）、ABカット以降の行は、オフセットの値を変更して追随すれば良いです。

こうすることで、１列目のカット番号は一瞬で入力されます。しかも、自分の思った通りの状態で。

「でも、あの‥‥。できれば、カット番号は３桁にしたいんだけど‥‥。」という場面もあるでしょう。‥‥だったら、これで。

=MID(1000+ROW(),2,3)

「MID()」は文字列を抽出するファンクションです。超便利ですネ。例えばカット３の番号は一旦「1000+3=1003」になり、その後、２文字目から３文字分を抽出して「003」になります。ROW()だけでは「3」としか表示されないのを、工夫するわけです。

この「欲しい桁数に１桁足した数を加算して、その後で２桁以降を取り出す」方法はいろんな場面、例えばAfter Effectsのフレーム数表示でも活用できます。ifで"0"や"00"を追加する方法を見たことがありますが、わざわざ if なんて使う必要もなし。命令文が１行で済みますからネ。

After Effectsのテキストレイヤーで４桁のコマ番号を表示するエクスプレッション；
String(timeToFrames(t = time + thisComp.displayStartTime, fps = 1.0 / thisComp.frameDuration, isDuration = true)+10001).slice(1);

ちなみに、表計算の式での、型（"1"と1は違う）の扱いとかルーズに見えるでしょうけど、その辺は暗黙の型変換をしてくれるようです。おもむろにやりたいことを手短にできるのが、表計算の式の良いところですネ。

「シーンの名称をカット番号につけたいんだけど」というニーズもあるでしょう。私の現在の仕事の１つはまさにソレが必要な状態です。そういう場合は文字列を連結します。

="A_"&MID(1000+ROW(),2,3)

こうすると、１列目のセルには「A_001」「A_002」「A_003」「A_004」‥‥と自動入力されていきます。シーンの切り替わりで、連結する文字列とオフセットを変えてやれば、簡単に現実のカット番号に追随できます。アンダースコアではなくハイフンが良い場合は、"A_"を"A-"にするだけですネ。

ちなみに上記の式は、Googleのスプレッドシートで活用できるので、他の表計算との互換性もあるように思います。NumbersやExcelでも使えるはず‥‥です。（未確認ですが）


今まで、数字の先頭に00や0、シーン名を追加するのに、手で入力していた‥‥のだとしたら、その人生の時間はドブに捨てたのも同じです。これからは限りある命の時間を、ドブに捨てないようにするのが肝要です。

数多くの何かを把握して管理する時、今では誰でも表計算で表にまとめることと思います。しかし、誰もが表計算のマクロやプログラム制御を習得しているわけではないでしょう。結果、表計算の使い方に大きなバラつきが生じ、能力のヒエラルキーを形成する原因の１つともなります。

アニメ業界は、表計算に限らず、コンピュータのソフトウェア全般において、コンピュータの長所をあまり活用していない状況です。作画にしても、ペンタブばかり上達したって、コンピュータプログラムを活用する足場を持たなければ、その後が続かないのですよ。

「それは、コンピュータができる奴の言い分だ」

ソレは全く違います。逆に、そのような言いかたこそ、「覚えるのをめんどくさがっている人間が、自己弁護をする際の詭弁」です。

母親から産まれ出た時から、式やマクロが書けたのでしょうか。誰しも「覚えたから、使えるようになった」だけなんですヨ。そこを誤魔化して、さも「天性の有無であるかのように」逃げるのは、よくないことです。難しいプログラムを扱えるようになるのではなく、日常会話レベルのプログラムを覚えれば良いだけですから、そこに天性も才能も必要ありません。

私なんて、コンピュータの電源すら入れられないところから、スタートしたのです。拡張子「.psd」を全角で「．ＰＳＤ」とか入力してファイル名にしていた男ですヨ。しかもその「ＰＳＤ」ファイルは実はPICTだった‥‥とかネ。（昔のMacは拡張子ではなく、ファイルタイプ、クリエータタイプというリソース（メタ情報）で、ファイル管理していたので、そんな珍事もおきたのですが）

今だと笑い話ですが、私は「を＝wo」を入力できなくて、メールを書く際にしばらくの間は、「を」を使わない文章で書いていた‥‥なんてアホのようなことをしていたのです。とてつもないコンピュータ無知だったのです。26〜27歳くらいの頃です。

でも、覚えようと取り組んだら、覚えられた。‥‥ただ、それだけのことです。

ソフトウェアを売り物にする本職ならともかく、現場で使うスクリプトやプチアプリを作る目的ならば、「日本語や英語を覚えて、さらに小説を書くレベル」まで到達する必要はありません。コンピュータを使う際の、基礎的な足場たりえれば良いのです。

これから先の未来、コンピュータを用いて仕事をするのなら、「コンピュータを使用する人間」と「コンピュータを活用する人間」の差は、あからさまにヒエラルキーとして表れると思います。「使用と活用」の差が表立って出てくるでしょう。だって、コンピュータを使う仕事なのですから。

現場のすべての人間がコンピュータのプログラムまで出来る必要はないと思います。しかし、コンピュータで大量の画像映像・ファイルやフォルダを扱い、四六時中コンピュータに接するのであれば、「アニメのソフトしかわからない」のでは明らかに限界は近いです。

ソフトウェアが高度化しても、そのソフトウェアが全て面倒を見てくれるわけではないので、ソフトウェアがどんなにトラブろうが、様々なアプローチで事態を切り抜けられる「強い」人間が存在感を表していくことでしょう。ソフトウェアが不調になった途端、全くのお手上げになるような「弱い」状態で、これから何十年も生きていけるはずもなし。

まるでＦ１レーサーのように、多くの人間が誰か一人をサポートするような状況なんて、コスト的にありえないですよネ。自分の状況は自分で改善するのが基本です。若い人は、20代の頃にプログラム習得の門戸を叩いて、コンピュータで未来を切り開く足場作りを早々に開始することをお勧めします。

そういった意味で、表計算の式・マクロは、うってつけの初級教材です。式の入力を間違えたからって、コンピュータが爆発するわけもなく、「！」のエラーが表示されるだけですからネ。

私は本格的にコンピュータをイジりだした1996年の翌年くらいから「プログラム」を独学で学び始めました。‥‥とか書くと大仰なんですが、要は「コンピュータを使うんだから、プログラムができないとツブシが効かんだろう」と思って「できそうな事から始めてみた」わけです。

昔はIDE、すなわちプログラムの統合開発環境が高価で、しかも敷居が高そうな気がしたので、「なんか手軽なプログラムはないもんかな」と探してたら、AppleScriptに出会ったわけです。Macを買えば、他に買い足しせずにいつでも出来るのが、魅力でした。

display dialog "Hello, World."

‥‥とかやってたのが、97年の春くらいの事でした。コード文的に正確には、

”Hello, World.”を表示する

‥‥だったと思います。私は最初、日本語版のAppleScriptから始めたのです。

theItemをtheItemsのおのおのにして（＝repeat with theItem in theItems）

‥‥とか、今考えると「余計、覚えにくいわ！」と思うような日本語ベースのプログラムでしたし、そもそも「AppleScript人口」が少ないので、マイナー感が拭えませんでしたが、「プログラムのなんたるか」を覚えるにはちょうど良かったと思います。
＊その後、Appleは日本語版のAppleScriptの開発を中止、私はゼロから覚え直す事になったのですが、今考えると、覚えなおしのプロセスで得る収穫も多かったように思います。その当時は「Appleの馬鹿野郎」と恨んだものでしたが、なまじ１つの言語の「癖」に馴染みすぎて応用が利かなくなるよりは、良かったのだと思います。

AppleScriptは辺鄙な言語でしたが、他のオブジェクト指向の言語を覚える際には、役立ちました。PerlやPHP、REALbasicやXcodeなど、AppleScriptと全く言語スタイルが違っても、「考え方」が色々と流用できましたし、そもそも、「プログラムに対するネガティブなイメージが払拭できた」のは大きかったです。


しかし、現在は2015年。

AppleScriptでラッピングして、中身はJavaScriptやShellScript‥‥みたいな誤魔化しが、いつまで続くのか、「普通に不安」です。

Appleは現在、MacOSXやiOS用に、「Swift」という新型のプログラム言語をリリースしています。次のOSX10.11では「Swift 2」もお目見えするようです。

ならば、OSXだけでなくiOSのプログラムにも使えるSwiftあたりをカジってみても良いのかも‥‥と思い、ネットの指南テキストを読んでみたら、そこそこ敷居が低く、After Effectsのエクスプレッションやスクリプトを使っている人なら、すぐにでも始められそうなくらいの印象でした。オブジェクト指向の洗礼を受けた人なら、かぶりついて、そのまま喰えるような感じです。

映像制作に用いるツールの開発は、当然ながら映像制作現場のニーズを色濃く反映しており、さらに未来の現場の発展も考慮すると、10年前に開発したツールはそのままでは使えない事も多いです。私がアニメの撮影現場用に作った「xtools」がまさにその状態で、今の「アニメ撮影作業のスタイル」が持続している間は、メンテナンス程度で使い続けられますが、私の考える未来の方式には、全く対応できないのです。

未来のツールを、さすがにAppleScriptベースで作る気にはならないので、Swiftあたりが妥当なのかな‥‥と思います。現場でのiPhoneやiPadの有効活用も今後は必須でしょうしネ。

ただまあ、こうして「ハコ」ばかり用意しても、肝心の「ハコの中身の開発」も重要かつ急務です。どんなにプロジェクトを立ち上げても、「ビジュアル」がなければ、どうにもならんですからネ。いつの時代も、ビジュアルを持つ者が台頭するのです。絵を作れない人々は、カラのハコばかりを用意して盛り上がろうとしますが、映像の商売なんだから、「プロジェクトだけ立ち上げて中身無し」では如何ともしがたいです。‥‥実際、「4K」の最大の悩みのタネは、コンテンツが無い事‥‥ですもんネ。

絵だけ作っても、実働のプランが白紙で実現不可能では、どうにも立ち行かない。しかし、実働のプランだけ進めても、絵がなければ、そもそも映像を売る商売として成り立たない。

両方を良い塩梅で進めていくのが、腕の見せ所‥‥なのかも知れませんネ。

今年、久々にアニメの撮影監督をやる案件があり、眠っていた「xtools」を復活させ、プログラム内部のメンテを初夏には終わらせたい目論みでいます。「xtools」とは自己開発のアニメーション制作補助ツールで、特に撮影業務の一式を補助するツールです。対話式の簡便なUIですが、After EffectsのコンポジションのオートビルドやQTの内容確認（もちろんスペック上の、です）など、手作業でやると煩わしい部分を代行してくれます。

言語は、AppleScript、JavaScript、ShellScriptなど、各種を混合して使っています。モジュールは共用できるようにライブラリ化し、ソフトウェアアップデートツールで、自動更新できる仕組みを作っています。また、データベースと連携機能を組み込んであり、ツールを使うと作業者も管理者も手間を軽減できる仕組みになっています。

現在の私は、アニメ業界の撮影業務とは違った作業を数多く引き受けており、xtoolsも大幅な機能拡張の時期を迎えています。また、「撮影」と言うカテゴリには当てはまらない、新しいアニメーション技法での各作業カテゴリもxtoolsに統合したい考えもあり、まずは春に旧来ツール群のプログラム内部面の大掃除を敢行する予定です。

「CBX」というコンポジションオートビルドのツールは、「素材の内容確認」「タイムシートの解析」「レイヤー配置の解析」などをおこなうので、ルーチンが複雑で大規模となり、メンテにも時間がかかります。加えて、「動く背景」素材（3D素材とは別に）に対応するなど、この10年で拡張を重ねた痕跡がメンテの障害になっていて、気が重くて放置していたのですが、そろそろ腹を括って「大メンテ」をしなければなりません。xtoolsは仕様をまとめながらコードを書いたので、つぎはぎ・増設の箇所が汚いのです。

ただ、xtoolsがあるのとないのでは、作業効率に大幅な開きが出ますし、作業事故の抑制効果も強いので、面倒で大変でも汚いコードを書き直してこまめに奇麗にしていこうと思います。それに現在は「撮ま」があって、撮影のベース部分をしっかりと固められるので、「撮ま」準拠のプログラムへと手直しする目的もあるのです。

プログラムって、アニメ業界だと今でも特殊な能力っぽく扱われますが、結局はプログラムを「やるかやらないか」だけだと思います。私が生き証人のようなもので、1996年春の初心者の頃は、同じ作業場にいた清積さん（ねこまたやさん）に頼らなければ「Macも起動できなければ、Photoshopを立ち上げる事もできなかった」のです。

96年にはPhotoshopすら起動できなかった、この俺が‥‥なのです。

プログラムは理数系の学校で授業を受けなければできない‥‥なんて、単なる思い込み、大ウソなのです。コンピュータがあれば、今日からでも始められて、身に付くものです。初めての頃は全角で「．ＰＣＴ」なんて拡張子を付けてたコンピュータの右も左も解らない人間でも、プログラムを習得する事によって、自動でフォルダの内容を分析してAfter Effectsに読み込んでレイヤー配置とタイムシートを適用するプログラムが書けるようになるのです。プログラムを習得する事は、コンピュータを理解する事でもあるので、畳み掛けるようにコンピュータ全般の知識が備わっていきます。

私の考える現場は、プログラムが出来る人間が常駐しているのが「デフォルト」です。誰かが作ったソフトウェアに依存するばかりで、自分らの現場にツールを自作できる能力を持たないと、色んなものを諦めなければならないからです。xtoolsを作っていた時は苦難の連続でしたが、今では作って良かったと実感しています。ツールそのものもそうですが、「コンピュータで何ができるか」を遠く深く見通せるようになったのは、得難い知識と経験です。

googleで「フリーソフト　ファイル　名前変更」なんて検索せずに、自分で名前変更ソフトを作ってみれば良いのです。「フリーソフトがあるのなら、それを使えば良いじゃん」とか思うかも知れませんが、それはすなわち、名前変更程度の事すらフリーソフトに頼らなければならない体質であり、さらにはその体質から永久に抜け出せない事でもあるのです。自分でプログラムが書けるようになると、ホントに、様々な場面で融通が利くようになりますヨ。

私は最初の頃、「を」の打ち方（＝wo）が解らなくて、「を」を使わないメール本文を書いていたほどの無知な人間でした。お笑い草としかいいようがありませんが、事実です。そんな人間が、プログラムに触れて身につけていく事で、数年後にはShellコマンドを打ったり、メールサーバの仕組みが解るほどに知識を得られるのです。‥‥でもまあ、初心者の当時に、一緒に仕事をしていた清積さん（当時から作画とプログラムの両刀使い）が、私にとってのお手本になっていたのは大きいでしょうネ。


しかしまあ、そんなこんな、96年から換算すると、コンピュータと深く関わり始めて、今年でもう18〜19年か。そりゃあ、「コンピュータをもっと上手く使わなきゃ」と言うキモチになるのも仕方ない、「長い付き合い」になるんですネ。

私はWebを構築する際、HTMLとPHPを用います。PHPはとっつきやすい言語で、JavaScriptに慣れている人なら、少々の読み替え・シフトで、すぐに使えるようになると思われます。「My Name Is Hisashi.」と「Mein Name Ist Hisashi.」くらい似ています。

私は今、「atDBx」という「アニメーション制作技術データベース」をチクチクと開発・構築し続けていますが、AppleScript用、JavaScript（ESTK）用のatDBxライブラリに続き、PHP用もそろそろ作る段階に差し掛かってきました。PHP用ライブラリを作らないと、データベース上の情報を人間の目でみる事ができないのです。情報データをWebブラウザで閲覧するには、それ相応の計画と工夫、そして実際のプログラムが必要です。

atDBxの前身であるatDBでも、PHPとの連携をおこなうライブラリは作っていたのですが、「どんなライブラリを作れば良いのか？」という基礎的な部分から手探りだったため、場当たり感満載でおよそ流用には適さない状態となってしまいました。とにかく「すぐに動作する」事が優先されたので、計画性に乏しく、無理に流用すると弊害も出そうでした。

何でもそうなんでしょうけど、最初から良い出来のものは作れませんよネ。「何が良いのか？」も解らないのですから、まずは手をつけて経験をつまないと、先には進めないのです。今のご時世は、最初から完璧なものを目指して（実は「完璧とは何か」すらわからないまま）、期待した結果を得られなければ即撤退‥‥という感じですが、技術はニジニジとした蓄積が必須なのですから、長丁場を覚悟しないとダメなんですよネ。何でも「自販機感覚」で手に入るわけじゃないのです。

今、私が取り組んでいるのは、各言語への「ライブラリの共通化」です。言語毎の文法はともかく、呼び出すサブルーチン・ファンクションくらいは共通化を図ろう‥‥というわけです。外部ファイルをそれぞれ用意しておいて、load script、readとeval、includeで各言語共通の命令系統を実現する仕組みです。以前は言語毎にバラバラだったので、コード記述時の効率が悪かったのです。

ライブラリ作成は、すなわちスクリプト作成・アプリ開発のお膳立てなので、ライブラリが存在しなければスクリプトを書き始める事もできないわけで、焦っていると「ライブラリなんて作らずに、すぐ作り始めちゃえ」となりがちです。‥‥でも、その行動が後になって、とんでもないフリクションロスやカロリー損失につながるのです。この辺の事は、同じような体験をした人なら解ってます‥‥よネ。

ライブラリを用意しておけば、実際のプログラムはスリムで明快な構造で作成できます。私のような映像制作の片手間でアプリを作る、プログラム専任ではない人間ほど、実はライブラリの構築が重要ではないか‥‥と思うのです。

ここのところ、作り続けていたグレーディングシステム用のパイプラインアプリですが、ほぼ完成し、あとはバグ潰しや機能改善をチクチクと地道に進めていくのみです。どんなに気を配ったつもりでも、実際に運用すれば、ポコポコと穴は出てくるものです。

After EffectsをAppleScriptで駆動する方法は、丁寧にAppleScriptとAfter Effects間でやり取りするのではなく、ESTKの命令文を作って丸投げする方法です。AppleScriptでPhotoshopを操作する際は、様々な返値を利用できるのですが、After Effectsの場合は貧相なexitCodeしか返ってきません。exitCodeは整数のみで、文字列などは扱えないので、スクリプトを実行した結果は実質受け取り不可能に等しいです。例えば、コンポジションのレイヤー名一覧を外部から取得する‥‥なんて事は通常の段取りではできないのです。

じゃあ、どうやってAfter Effectsをスクリプトで転がすかと言うと、ソケットや独自のクリップボードを使う‥‥などもありますが、環境の整備がそこそこ面倒なので、私は「変数を泳がす」方法で切り抜ける事が多いです。恐らく、一番安易で簡単です。

After Effectsの変数はゾンビのように、After Effectsが死ぬ（アプリ終了）まで生き続けるので、これを利用して、「ゾンビ変数に値を持たせたまま泳がせて」外部から上手く操作するわけです。

AppleScriptなど外部からは、変数・定数の中身ではなく、あくまで変数名だけで、転がしていきます。つまり‥‥
 
‥‥として、変数に普通に代入しておけば、スクリプトを一旦終了しても、After Effectsが終了しないかぎりは、いきなり、
 
‥‥と書き始めても、undefinedになる事もなく、普通に取り扱い可能です。変数の中身は外界に取り出さずに、変数自体を外部からあっちゃこっちゃと転がして、上手くいった場合は0、そうでない場合は0以外をexitCodeに代入して、「result as integer = 0」でBooleanに変換し「結果報告だけを聞く」カタチにするのです。

いつまでも変数が死なないこの習性（？）を利用すれば、結構自由にAfter Effectsを「遠隔操作」で転がせるのですが、反面、変数が暴走（大袈裟ですけど）する危険性もあります。JavaScriptはDimとか宣言しなくても、おもむろに変数を使う事ができますが、ゆえに、既に前の前の前のスクリプトで使用済みの変数を、意識無しに使ってしまう可能性もあります。なので、ゾンビ変数を意識的に転がす際は、変数の名前のお約束を自分の中で定義してキッチリと運用する事が必須となります。


変数 i に10が代入されたところでスクリプト終了。


別のスクリプトで 変数 i をおもむろに使うと、既に10の値がセットされているので、結果は30。うひー。‥‥もちろん、変数 i の使用前歴がなければ「iは未定義」となってエラーです。スクリプト作成者の「管理能力」が問われる仕様ですネ。undefinedねらいの軽妙な文面でなく、しっかり変数の宣言と初期化をやっておかないと、後で弩壷にハマる仕様となっております。


‥‥ちなみに、エクスプレッションはそういう事（ソンビ）はないようで、１レイヤー１フレームごとに値はクリアされるみたいです。まあ、全てのエクスプレッション上の変数が生き残りまくってたら、わけがわかんなくなるでしょうからネ。

 

AppleScriptは、Macユーザかつスクリプトを常用している人間でないと使わないので、マイナーなアプリではありますが、その能力はあなどれません。私の自作ツールのほとんどはAppleScriptベースですが、業務の生産効率を左右するほどの影響力があります。

ただ、AppleScriptに何も不満がないわけではなく、こんなのがあるといいのにな‥‥と思う機能はそこそこあります。すごく基本的なところではループ文における「continue」です。

AppleScriptでも「continue」はあるのですが、「処理を続ける」という命令で、ループの処理を抜けて次回へスキップする内容ではありません。JavaScriptのcontinue相当はどうもAppleScriptには存在しないようです。breakはexitでイケるんですが。

要は、処理を抜ける構造が実現できれば良いので、以下のようにしてcontinueと同等の動作は実現できます。

set myList to {}
repeat with i in {1, 2, 0, 15, 2, 2.1, 2, 3}
    repeat 1 times--continue実現の為のrepeat
        set i to i as number
        if i = 2 then exit repeat
        set myList to myList & i
    end repeat
end repeat
return myList
--結果は{1, 0, 15, 2.1, 3}　〜変数「i」が2の時はexit（break;）して、以降の処理はスキップします

入れ子のrepeat上でexitを使えば、exit以降の処理は実行されずにスキップされるので、continueと同じ働きをします。

しかしなんでしょ‥‥、行儀は悪いですよね。continue実現のために、repeatを本来とは違う目的で用いているのですから。

インクリメントとかは、単に「set i to i+1」とやればよいので、文字数の冗長さにガマンするだけで済むんですが、continue模倣の為だけにrepeatを使うのは、後になってコードを読み返した際に「何でここでrepeatを使ってるんだ？」と自分でも判らなくなりそうで、面倒でコワいです。

ちなみに‥‥。参考文中の「set i to i as number」を読んで、「なぜ、そんなクドいキャストを？」と思う人もおられるかもしれません。変数 i には当然Numberクラスが代入されていると思うわけですが、その変数 i を「is」「=」の比較演算子を用いて評価すると、実際はうまくいかないのです。AppleScriptにはありがちな動作ですネ。「item 2 of {1,2,3}（つまり2ですネ） 」は、2ではない‥‥という比較演算‥‥。でもまあ、もう16年もAppleScriptと付き合ってると、他の言語にはないクセもお馴染みなので、もはや混乱する事はあまりないです。AppleScriptが「何でヘソを曲げているのか」は大体察しがつきます。しかし、JavaScriptなどの他の言語に慣れた人がAppleScriptを使うと、「？？？」の連続かも知れませんネ（苦）。

まだ当分の間、AppleScriptにはお世話になる感じなので、現在JavaScriptの基本的なメソッドをAppleScriptに翻訳してライブラリ化しています。

AppleScriptは、「大文字を小文字に」とか「配列をスライスする」「文字列を置換する」などのよく使う操作を、一発で呼び出せません。プログラム文をガシガシ書きまくる際に、何かと面倒です。なので、.toLowerCaseや.slice、.replaceなどをサブルーチンとして作って、簡単に呼び出せる仕組みを実践中です。共通のコンポーネントとして１つのスクリプトファイル内に蓄積して、スクリプトを作る際に「load script」すれば管理も簡便です。

スクリプトのコンポーネントの扱いは、難しい事はありません。以下のようにとても簡単です。
 
映像制作に使うJavaScriptのメソッドは、基本的なもので充分です。join、slice、replace、match、toUppserCaseやtoLowerCaseくらいでほとんどカバーできます。substringやsubstrなどは、sliceで代用可能でしょう。なので、AppleScriptに翻訳するメソッドもそれほど多くはならないと思います。‥‥ただ、RegExpの翻訳（というか、導入）はどうしようかな‥‥とは思っていますが。。。AppleScriptで正規表現が使えたら楽は楽‥‥ですけどネ。

メソッドは翻訳できるものの、文章表現そのものの特質までは操作できません。例えば、AppleScriptはundefinedやnullをfalseと同義に評価する機能はありませんから、制御構造はAppleScriptの流儀でおこなうほかありません。JavaScriptは未定義の変数やNaN、0なども「偽」として評価されるのが楽なんですけどね‥‥。
 

でもまあ、各言語の文章表現までは介入できなくても、メソッドを共通にするだけで、随分とスクリプト作成は楽になります。これもインフラの一環と言えますが、インフラを怠ると、後でとんでもない代償を払う事になりますから、根気よく地道に貯め込んでいく所存です。