Scriptの癖

前回掲載したスクリプト文は、AfterEffectsのスクリプトフォルダに毎度添付される「Change Render Locations」を改造して、自分たちの使いやすいスクリプトに変えているのですが、大幅に書き換えているとは言え、スクリプトの作者さん(2バイト文字への配慮がないあたり、1バイト文字圏の外人さんでしょう)の癖をいくつか残した文になっています。なんとなくながめていて、ふと、気がつきました。

 

私はインクリメント、デクリメントは、例えば変数「i」ならば、

 

i++

 

とやるのですが、原文の作者さんは、

 

++i

 

‥‥と書いております。私は不勉強なもので、演算子を前に持ってきても良いことを、今さら気がついた次第です。ちなみに、前置と後置では若干動作が異なるとのことですので、私は使い慣れた(=期待する動作をする)後置「i++」を今後も使うと思います。

 

ちなみに、私が昔から慣れ親しんで今でも現役のAppleScriptでは、このような演算子はなく、

 

set i to i+1

 

‥‥と書きます。解りやすいですけど、文字数は多い‥‥ですネ。なので、AppleScriptのスクリプト文は長くなりがちです。

 

私がJavaScriptベースのAdobe Script(正式名は不明です...)を使っていて便利だなと思うのは、null, 0, undefined以外の有効な値はtrue扱いになる仕様です。いちいち「trueかfalseか」を演算しなくても良いので、文がすっきりします。

 

もし変数「newLocation」の中身がFileやFolderのObjectでなく、nullだった場合(ユーザがファイル・フォルダ選択をキャンセルした場合など)は、

 

if (newLocation != null) {...

 

とやらずとも、

 

if (newLocation) {...

 

‥‥と書けば期待した動作になります。

 

私がその昔覚え始めて体に馴染んだいくつかの言語は、ifで取り扱う値は真偽値オンリーでしたので、JavaScriptの有効な値ならtrue、それ以外はfalseという仕様になかなか馴染めませんでした。‥‥が、慣れちゃえば楽です。考え方としても「有効な値だったら、スクリプトが進行する」ので、いちいち「真偽のまな板にのせる必要がない」ので手順がちょっとだけ省けます。その「ちょっと」が数百数千行になると、結構活きてきます。

 

でもまあ、結局はスクリプトを書いている人の癖みたいなものですね。

 

私は、本文から呼び出すファンクションやサブルーチンは、下に纏める習慣があるのですが、これも癖でしょうね。「main()」や「on run」で本文を纏めたいのも、私の癖というか、好みですし。

 

スクリプトやプログラムの文って、当人の考え方の手順、要素の整理の仕方を、如実に反映して興味深いです。他人のスクリプト文やプログラムコードを読むと、目から鱗が落ちることも多いです。

 

 


undefined

今日、以前作ったAfter Effectsのレンダーキュー周りのスクリプトを修正していたのですが、レンダーキュー項目って、selected、つまり「現在、選択状態」のプロパティがないことに気付きました。‥‥というか、何年ぶりかで思い出しました。

 

こんな感じでレンダーキュー項目を選択しておいて‥‥

 

 

「selected」属性を、alertで表示するようにスクリプト文で実行すると、

 

alert(app.project.renderQueue.item(1).selected);

 

返ってくるのは‥‥

 

 

 

あれ‥‥?

 

「あんでふぁいんど」。

 

ん? ‥‥‥trueは返ってこないのか。

 

itemクラスを継承してるんじゃないのか。RenderQueueItemは。

 

Layerとかは選択状態を取得できるんですけどね。‥‥RenderQueueItemはダメだったっけか。

 

 

そもそもなぜ、レンダーキューの選択状態を取得したいかというと‥‥

 

300〜500個のRenderQueueItemがある場合、任意の150〜250個だけレンダリング先を一気に変えたいからです。要は、大量処理です。

 

例えば、下図の選択状態のレンダーキューだけ、レンダリング先を変更したい‥‥わけです。(見やすいように、数を少なくしています)

 

 

After Effectsは謎の多い仕様で、レンダリング設定や出力モジュールは複数選択で一気に設定を変更できますが、レンダリング先だけは一気に書き換わってくれません。複数選択しようが、全選択しようが、最初にクリックした項目だけです。

 

そればかりか、何度書き出し先を指定しても、「前回指定した場所を覚えてくれない」という状態が続いています。どのバージョンからだったかな‥‥。

 

 

‥‥以前は、覚えてくれてたんだけどなあ‥‥。環境設定か何かを削除すれば良いのかな‥‥。でもそれだと、他の環境設定も消失するから嫌なんだよね‥‥。

 

まあ、図のように、5個だけなら、手作業で再指定しても良いんですが、これが100個、200個レベルになってくると、もう手作業では無理です。そんな作業にマンパワーを費やすのは、制作費の無駄遣いです。

 

一度のレンダーキューではなく、数回にプロジェクトを分ければ、レンダリング先をプロジェクト単位で一括変更もできます。After Effectsに昔から添付してあるサンプルスクリプトの「Change Render Locations」をプロジェクト毎に実行すれば良いです。‥‥ただ、サンプルプロジェクトはレンダーキュー項目ごとにalertが表示される「お試し仕様」なので、実際に使用する場合はalertの行をコメントアウトして使うのが良いです。100個あったら、100回アラートウィンドウが出てOK(=リターンキー入力)するのはアホすぎるもんね。

 

でも、そうじゃなくて、いちいちプロジェクトを分けるなんていう手間なしに、レンダーキュー項目から任意の項目のレンダリング先だけをちゃちゃっと変更したい場合は、そもそもどうやって「任意の項目」を取り出せば良いのか。

 

任意の選択状態を表す「selected」プロパティが、RenderQueueItemでは「undefined」=該当なし・存在しないので、思い描いたスクリプトが書けません。

 

頓挫。

 

でも、簡単に諦めては、様々な大量処理が待ち構えている映像制作の世界では生きていけません。くじけるべからず。

 

要は、任意のレンダーキュー項目をどうやって「スクリプトに選別させるか」を、新たに考えれば良いのです。選択状態が取り出せないのなら、他の方法で、任意の項目を取得すべし。

 

レンダーキューのウィンドウには、各項目ごとに「レンダリング」のチェックボックスがあります。これで「レンダリング先を変更する項目を指定」すればうまくいきそうです。

 

 

各項目の「レンダリング」にチェックが入って待機状態の場合、レンダーキュー項目のstatusが「QUEUED」になります。「RQItemStatus.QUEUED」です。

 

RenderQueueItemのstatusがRQItemStatus.QUEUEDならば、レンダリング先の変更を適用する‥‥というスクリプトにすれば、100個も200個も並んでいるレンダーキューの中から、特定の項目だけレンダリング先の変更が一気に可能になります。

 

チェックボックスをON/OFFするのは、項目を選択しておいてチェックボックスをクリックすれば瞬時に変更可能です。

 

 

「レンダリング」のチェックボックスで変更したい複数項目を切り替えていけば、レンダーキュー項目全てではなく、自分の処理したい項目だけを抽出できます‥‥ので、その通りに、スクリプトを書きます。

 

 

SCRIPTNAME = "レンダリング先を変更";

if (checkRenderQueueItems()) {
    ChangeRenderLocations();
}else{
    alert('アクティブな項目が0です¥nレンダリング先を変更するレンダーキュー項目をアクティブにして下さい.¥n¥n(レンダーキューウィンドウの「レンダリング」チェックボックスを確認してください.)', SCRIPTNAME);
}

function checkRenderQueueItems(){
    for (i = 1; i <= app.project.renderQueue.numItems; ++i) {
        if (app.project.renderQueue.item(i).status == RQItemStatus.QUEUED){return true;}
    }
    return false;
}
    
function ChangeRenderLocations(){
    var iCount=0;
    var newLocation = Folder.selectDialog("新しい保存先を指定してください");
        
    if (newLocation) {
        app.beginUndoGroup(SCRIPTNAME);
            
        for (i = 1; i <= app.project.renderQueue.numItems; ++i) {
            curItem = app.project.renderQueue.item(i);
                
            if (curItem.status == RQItemStatus.QUEUED) {
                for (j = 1; j <= curItem.numOutputModules; ++j) {
                    var curOM = curItem.outputModule(j);
                    var oldLocation = curOM.file;
                    curOM.file = new File(newLocation.fullName+"/" + oldLocation.name);
                    iCount++;
                }
            }
        }
            
        alert(iCount+"項目を、新しいレンダリング先に変更しました.¥n"+newLocation.fullName+"/", SCRIPTNAME);
            
        app.endUndoGroup();
    }
}

 

 

‥‥という感じのスクリプト文で「やりたいことが解決」しました。

 

もし、うっかり、レンダーキュー項目のチェックボックスが全て外れていたり、レンダリング済みの項目だけで有効な項目が無い場合は、以下のようなアラートでそっと教えてくれます。

 

 

自分で使う際にやらかしてしまいそうなミスに対し、事前に手を打っておくのも、自作するスクリプトの利点ですね。

 

実は、このスクリプト文の原型は、前述したAfter Effectsサンプルスクリプトの「Change Render Locations」なんですが、そうこうして自分らの使いやすいように改造してたら、ほとんど原型がなくなってしまいました。

 

ちなみに、オリジナルの「ChangeRenderLocations」は、toString() でパスを文字列化しておりましたが、JavaScript Tools Guide を読むと、「fullName」で「The full path name for the referenced file in URI notation. 」が取得できますので、変更しています。

 

toString() だとさ‥‥、日本語(2バイト文字)が文字化けするんよ。

 

 

別に取扱上で実害は無いんですが、文字化けは気持ち悪いので、fullName に変更すると、

 

 

‥‥のように、文字化けせずに済みます。

 

どんなに日本語を使おうが、文字化けなし。

 

 

 

もし、こうしたスクリプトを自分たちで作れない場合、何らかの手間を割いて、余計に時間を消費して、対応することになります。

 

言わば、After Effectsを使う上でスクリプトやエクスプレッションは、CQBのハンドガンやアーミーナイフのような「自分を身を守る、サバイバルツール」のようなものです。

 

身につけておいた方が格段に有利ですし、もしグループならば、誰か一人は使えた方が良いです。

 

次世代のコンピュータベースの制作現場を形成したいのなら、コンピュータを効率的に使う知識は、草の根から必須だと思います。次世代知識に聖域なし‥‥です。誰もが知り得るべき基本事項でしょう。実際に自分がコードを書かなくても、今までと違う何ができるか‥‥を知ることが重要です。

 

制作システムと同調すれば、ファイル名(=コンポ名)から識別してサーバの各所に自動でレンダリング先を割り当てるようなことも可能でしょう。システムと各個人のリソースは、有効にバインドしていくのが肝要です。‥‥もちろん、各個人のテリトリーを保護・保証した上で‥‥です。

 

After Effectsの「瑣末な事務作業」なんて、本来、アニメーター・コンポジターとしては最小限に労力を抑えるべき要素ですからね。

 

 


APFSとAppleScriptその後

APFSでフォーマットされたディスク上で、AppleScriptのFinder操作でエラーがでる件、どうも再現性があやふやで困っております。

 

他の用事でiMac 5Kの電源を落として、改めて起動したら、APFSのディスク上でも正常にAppleScriptでFinderアイテム(フォルダやファイルなど)が扱えるようになりました。

 

ぎゃふん。

 

全てにおいてAPFSとAppleScriptの組み合わせがNGなわけぢゃ‥‥なさそうです。

 

APFSにおいて、AppleScript上で扱うFinder Itemに必ずしも障害が出るわけではなく、正常に動くこともままあるようです。なので、ネットを検索しても障害例が出てこなかったのかも知れません。High SierraでAppleScriptを使う人って、あまり多くはなさそうですもんね‥‥。

 

うーむ。スクリーンショットを撮っておけばよかったかな。

 

しかしまあ、再起動すれば治る時点で、どのあたりの不具合かはなんとなく見えてきました。私のiMac 5Kは、それこそ1年中電源が入りっぱなし(システムアップデートの再起動や不在時のスリープはしてます)なので、なんとなく思い当たるフシはあります。

 

でもまあ、再起動で治るって‥‥一番、嫌なパターンですね。

 

いずれまた、同じ障害が発生するかも知れませんので、その時はもう少し色々と試して検証してみたいと思います。例えば、Finderの強制終了(Finderだけを再起動)で治るのか‥‥とか。

 

今回のAppleScriptの件に限らず、新しいOSとファイルシステムを使う以上、どうしても負のリスクはつきまとうものですから、障害が立ちふさがった時は慌てず回避策や代替案で切り抜けるべし‥‥です。

 

 

 

しかし、APFS。いや‥‥、最近のディスク関連。

 

少々戸惑うことが多くて、例えば「パージ」という仕組みは、ディスクの残り容量がよくわからないことがあります。

 

最近、他のディスクに600GB分のデータを移して、元データを消去したことがありましたが、ディスク容量表示が変化しないことがありました。600GBをゴミ箱に送ってゴミ箱を空にしたのに、消去したはずの600GB分の容量が当該ディスクで増えてくれない‥‥という状況です。

 

「空にしたのに、空になっていない」ような状態ですが、それはどうも「パージ」の機能が作用しているらしいことがわかりました。ゴミ箱を空にした容量と「パージ可能」な容量が一致していたので、判明した次第です。

 

仕組みの細かい点はわかりませんが、ゴミ箱を空にしてもFinderウィンドウの表記や「情報を見る」ウィンドウの表記で容量が回復しないのは、「パージ機能」によって空にしたはずのゴミ箱の内容がプールされているから‥‥みたいです。

 

以下の「ディスクユーティリティ」のスクリーンショットでも、2TBのディスク容量にも関わらず、利用可能が「1.28TB」、使用済みが「1.37」TBで、合計がおよそ2.6TBとなっていますが、パージ可能な容量の0.6TBを差し引けば、ちゃんと2TBになるのです。

 

 

 

うーん、ややこしい。

 

ゴミ箱を空にした後は、その空にした容量分だけ、サクッと容量表記が増えて欲しいですネ。‥‥じゃないと、わかりにくいもんな。

 

 

しかし、Appleの説明もよくわからん。説明文では、クラウドが‥‥とか言ってますが、私の場合はゴミ箱に送ったファイルなので、いまいち要領を得ないです。

 

https://support.apple.com/ja-jp/HT206996

https://support.apple.com/ja-jp/HT202867

 

ただ、「https://support.apple.com/ja-jp/HT206996」の最後に‥‥

 

  • APFS フォーマットのボリュームでファイルを複製した場合、そのファイルがボリューム上の容量を追加で消費することはありません。複製したファイルを削除した場合、その複製ファイルに追加したデータが占めている分の容量だけが解放されます。ファイルを取っておく必要がなくなったら、複製ファイルとオリジナルのファイルを両方とも削除して、そのファイルが消費していた容量をすべて解放できます。

 

‥‥とあるので、このあたりの関連かな‥‥と思います。

 

APFSの「実体をともなわないコピー」が返って裏目に出て、別ディスクに複製したのちに消去したはずのファイルが「パージ可能」なファイルとして存在し続けるのか‥‥、まあ、APFSの仕組みは今後、徐々に作業しながら理解していけば良いかな‥‥と思います。

 


APFSとAppleScript

今日初めて気がついたんですが、どうも、macOSの新しいファイルシステム「APFS」だと、AppleScript上でまともに処理できないっぽい‥‥感じです。

 

ファイル・フォルダの扱いがまともにできないので、ファイルシステム上で何もできません。

 

例えば、APFSのディスク上で何かを選択しておいて、

 

tell application "Finder"

 set theSelection to selection

 set theItem to item 1 of theSelection

 name of theItem

end

 

‥‥なんてやろうものなら、「name of」がひっかかってスクリプトがエラーで停止してしまいます。(正しくは、項目が取得できないので、その項目の名前も取得できない‥‥という連鎖のエラーです)

 

なぜ「name of」がエラーになるのか、何か大ポカをやらかしているのか自分の書き方を疑いましたが、そもそもあまりにも基本的な要素なので疑いようもないのです。AppleScriptの場合、一旦変数に入れてからでないと期待した動作にならないことは昔からありましたが、今回はそういうわけでもないです。

 

試しに他のAPFSではないディスクで試したら、あっさりとエラーなく動作しました。

 

つまり、HFS+上でなら普通に動作しますが、新しいAPFSだとエラーになります。

 

エラー内容も、当該項目のcontainerのcontainer(Finderの場合、containerとは親フォルダを指します)が返ってきたり‥‥と、かなりめちゃくちゃです。

 

theItem as unicode textとか、POSIX path of theItemとかもNG。パスすら取得できんです。

 

つまりitem〜ファイルやフォルダがまともに扱えません。

 

 

どぐあ。

 

ショック。

 

 

私のiMac 5Kは、FusionドライブなのでHFS+のままでセーフ。しかし、外付けのSSDはHigh Sierraのアップデートで自動的にAPFSになるのでNG。APFSに変換したHDDもNG。HFS+のままのHDDはセーフ。

 

 

これ、何時、治るかな。それとも放置かな‥‥。

 

Appleさん。頑張ってください‥‥。

 

 


Swift Playgrounds

最近知ったのですが、Appleから出来るだけ簡単に(=気構えなく気軽に)Swiftプログラミングを習得できるように、「Swift Playgrounds」というAppが無料公開されていたのですネ。知らなかった。

 

https://www.apple.com/jp/swift/playgrounds/

 

ちょっとやってみたのですが‥‥‥、そうか‥‥、こうすれば、プログラム習得って敷居が低くなるのか‥‥と、関心することしきりでした。今までのプログラム入門の「入門とは言え難しい」という常識を覆す、ゲーム感覚で「プログラムの概念」を覚えられる「欧米ならではの」発想の入門書です。

 

いきなり「概念」から覚えられる教え方には、感服しました。私が過去学んできた学習書には全くなかったタイプです。

 

そもそもプログラムで何が出来るのかを知らなければ、プログラムを学ぼうなんて人間が増えなくても当たり前です。カリキュラム‥‥という観点で考えれば、「何のために学ぶのか」を一番最初に理解してもらうことが、「学ぶ行為として合理的」です。

 

‥‥凄いよなあ‥‥、欧米の合理性は。

*もちろん、今までの日本の学習書でも「概念」には軽く触れてはいましたが、逆に言えば、軽く触れる程度で、何よりも最初に概念について徹底的に反復するようなことは無かったです。‥‥私の買った学習書では、です。

*まあ、日本人の学習は、たとえ「ゆとり」なんていう言葉を使っても、考え方が「詰め込み型」になりがちなのは、「民族性」なのかも知れませんね。「ゆとり」なんていう言葉のチョイス自体が、「詰め込む量を少なくして、ゆとりを持って」という考え方そのもの(=詰め込む思想自体は変化なし)ですもんネ。決して、「イメージを最初に掴む」タイプの学習法ではないです。‥‥私も反省せねば。

 

変数に値を代入する‥‥なんてことを最初に覚えてもらおうとしても、「それが何のためか」が解らなければ、よほどプログラムに興味があって忍耐強い人でなければ、挫折しちゃうもんネ。

 

Swift Playgroundsは、「Byte」という名前のゲームキャラクターを、コード(プログラム文)で操作して、ミッションを達成する‥‥という流れで習得は進みます。これは言わば「任意の対象を、プログラムで処理して、意図した結果を得る」という流れをそのまま「ゲーム風」に体現した内容です。いきなりコンピュータの専門用語責めにされるより遥かに馴染みやすく、「まず最初に根本的なプログラムのイメージを掴め」ます。

 

そして、「ゲーム風に噛み砕き過ぎている」こともなく、最初からプログラム文の習得を意識して、プログラム文独特の、例えば「moveForward ()」のような文体を、学習者の目に馴染ませています。

 

うーむ。私が学習してきた日本人著者の書を振り返るに、なんで日本人は、Swift Playgroundsのような教え方ができない民族なんでしょうかね。

 

まあ、日本人は、目的よりも手段を重んじる気風が「なんやかんや言っても」ありますから、目的よりも手段から教え始めることが多いのかな‥‥とも思います。日本人は目的の「地」ではなく、至る「道」を重んじますからね‥‥。それは善くもあり、悪くもあり‥‥。

*目的よりも手段を重んじる気風は、まさにアニメ業界そのものです。じゃなければ、ここまで旧来の技術に固執せんわな。

 

 

で、Swift Playgrounds。

 

例え映像制作でも、これからコンピュータで飯を喰っていこうとする若い人は、Swift Playgroundsをゲームノリの軽い感覚で始めてみても良いように思います。プログラムを覚えておいて、損な事はないですから。

 

 

思うに、このSwift Playgroundsでプログラムの概念や流れを習得すれば、他のプログラム言語も馴染みやすくなると思います。プログラム言語は呪文ではなく、ましてや感情表現や暗喩を盛り込んだ詩でもないので、何らかのプログラム言語を覚えると、書式の違いこそあれ、いくらでも「考え方の応用」が効きます。

 

実際、私は最初Apple Scriptでプログラムを始めて、その次に、インターフェースも自分でデザインして「ソフトウェア」っぽいものが作れるREALbasicに熱中しましたが、その後はPerlやPHPなどのWebで用いられる言語、After EffectsやPhotoshopで使えるJavaScript、ShellScript、Xcodeなど、必要に応じて色々なプログラム環境に難なく馴染むことができました。1つの言語を熱心に勉強した後だと、他言語への「読み替え」が効くのを実感しました。

 

 

 

私も、こんなに気軽にカリキュラムが進むのなら、Swift Playgroundsをやってみようと思います。実は、忙しさにかまけて、Swiftの習得は失速気味なので、丁度良いです。

 

でも、今のiPhone・iPadのApp開発って、どうなってんのかな‥‥。昔は、結構面倒な縛りというか、段取りがあって、オリジナルアプリをローカル限定で使うようなことも気楽にはできなかったはず‥‥です。その辺は多少、今は緩くなってるんだろうか。

 

ちなみに、私がMac版のソフトウェアを思いついたその場でどんどん作って、どんどん使えたのは、外部に公開しようと思わなければ、何の面倒もなかったからです。ファイルと同じで、コピーすればすぐ使えたんですよね。

 

あ‥‥、でも、今はMacのアプリも縛りが多少キツくなっているようです。開発元不明のアプリは、管理者権限がないと実行できないようになってます。なので、30分くらいで作った急凌ぎのアプレット・ドロップレットのAppleScriptなんぞを、他のマシンに持ち込んでも簡単には実行できないようになっています。

 

‥‥まあ、それもそうか。ウィルス社会だもんね‥‥。

 

 


プログラ

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

 

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

 

例えば、コンポジションの尺を変更する際、内包されているコンポジションの尺も伸ばさなければならない場合がありますが、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ソフトウェア自動処理の一番簡単な実行方法は、

 

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

エディタ上で実行する

 

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

 

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

 

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

 

 

 

 

簡単な例をば。

 

After Effectsで何らかのコンポジションを開いておいて(もしくは新規コンポジションを作成して)、タイムラインにフォーカスを入れておき、以下の1行スクリプトを実行すると、コンポジションの尺が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」の設定内容にて追加する

 

 

 

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

 

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

 

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

 

var myCompo=app.project.items.addComp("新規コンポジションの自動作成テスト2",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("新規コンポジションの自動作成テスト2",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、コンピュータ作画が入り乱れる「大混戦」の作業現場へと移行していきます。現場のハンドリングが今まで以上に大変になるのは解りきっています。

 

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

 

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

 

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

 

 

 


表計算

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

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

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

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

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

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

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

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

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

=ROW()

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

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

=ROW()-3

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Swift

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

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

display dialog "Hello, World."

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

”Hello, World.”を表示する

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

theItemをtheItemsのおのおのにして(=repeat with theItem in theItems)

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

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」の最大の悩みのタネは、コンテンツが無い事‥‥ですもんネ。

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

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


calendar

S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM