PHP

久々にPHPの現在を調べてみると、バージョンは7。‥‥うーむ。私が沢山書いてたころは、3だった記憶があるので、もはや修正するよりも書き直した方が速いレベルですネ。‥‥‥‥まあ、私が撮影業務のアシストアプリとデータベース/Webを必死になって作ってたのって、もう10年以上前だもんなぁ‥‥。

 

宇宙船演算子なんてのも7から加えられたようで、PHPを今後また本格的に使うようなら、7基準でゼロから考え直したほうが良いですネ。

 

<=>

 

その昔、撮影はコアレタスじゃないとできない‥‥なんて言われていた頃から、私らは撮影業務をAfterEffectsでおこなうべく色々と模索していましたが、なぜコアレタスを使わなかったのかというと、「価格が高い」「アニメに特化し過ぎてて拡張性・未来性が乏しい」そして「スクリプトに対応していない」のが理由でした。

 

例えば、何らかのスクリプト対応の表計算があれば、その表計算ソフトをタイムシートアプリにして、タイムシートをキーフレームとして流し込むことも、AfterEffectsからキーフレームをもとに表計算に流し込むことも可能でした。miなどのテキストエディタもタイムシートの入力・編集アプリに早変わりしました。

 

それだけでなく、データベースと連携して、カット情報とタイムシートデータを元に、AfterEffectsで「素組み」レベルまで自動ビルドすることもできましたし、AfterEffectsのレンダリングエンジンとは違う自動レンダリングシステム(データベースと通信しつつレンダリング後の事後処理もおこなう)も実現していました。

 

その際、データベースやライブラリのフロントエンドを提供していたのがPHP3でした。

 

進捗状況を棒グラフ(のようなルック)でHTML上で表示したり、任意のカットの詳細情報を表示したり、終了作品のムービーライブラリを提供したり、当時バージョン3だったPHPでも、撮影作業に有用な色々な事が可能でした。

 

PHPは、個人単位がスクリプトで効率化を図る目的には何も貢献しませんが、「ワークグループ」という概念を実践するのならば、制作進捗情報の共有と同調を可能にして、状況把握の齟齬を解消する大きな役割を果たします。

 

まあ、PHPと同じことができるソリューションなら何でも構わないと言えば構わない‥‥のですが、PHPは何と言っても「手軽」だったのがよかったのです。「ほにゃらら.php」のファイルを作るだけでしたからネ。

*サーバ上でのリダイレクトやエイリアスを活用する場合は、Apacheのコンフィグをイジって連動させる必要はありましたが‥‥。

 

 

 

しかし、PHP。

 

今、私は、Pythonの習得を時間の合間でぼちぼち開始していますが、何だか、PHPとPythonでできる事がかぶってる気がします。

 

管理上の視点からも、もし色々と機能的にかぶっていて重複も甚だしいのなら、どちらかにしぼるべきでしょうネ。

 

 

まあ、PHPは昔覚えたし、今はPythonを主眼にしておこうと思います。

 

 

 

ちなみに、Python。

 

まだ私は始めたばかりですが、ざっと見る限り、言語的にはごく普通にとっつきやすい内容のようです。

 

アニメ作業関係者の人でもAfterEffectsのJavaScriptでスクリプト文に慣れているのなら、ちょっと読みかえれば基本構造は理解しやすいと思います。まあ、何らかの言語をそれなりに突っ込んで覚えた経験のある人なら、「まるで異質には感じない」でしょう。

 

なので、作例や使用例・運用例をいくつか実践してみて、Pythonの流儀に慣れれば問題なくイケそうな感じです。

 

 


Photoshopの自動処理

私は原画作業をProcreateで描いた後に、「共有」でPSD形式でAirDrop越しにiMacやMac Proに書き出します。そして、そのPSDから、紙チェック用の200〜300dpiの印刷データをTIFFで書き出します。

 

アニメ現場でおなじみのTGA(Targa)はそもそも解像度の概念がなく印刷に全く不適合なので、解像度情報を保持できる一般的なTIFFやPSDやJPEG(クオリティ100%で)で書き出しています。‥‥まあ、今の所は、です。

 

‥‥で、そのPSDから「紙の原画仕様ファイル」への書き出しは、結構、面倒です。ケアレスミスも呼びやすいですし。

 

なので、そういうことは一番得意なコンピュータにやらせます。仕様に準じて、ミスなく出力する‥‥なんて、コンピュータの大得意な分野ですもんネ。

 

やるべきことは、PSDファイルを開いて、レイヤー重ねの上からでも下からでも、総当たりでレイヤーの名前と階層を分析し、何をどうすべきかを把握した後に、順番にTIFFで保存する‥‥という段取りです。

 

事前の条件として、PSDファイルの状態は、

 

  • レイヤーおよびレイヤーセットの名前は、規則通りであること
  • レイヤーセットの階層は、検索する深さに準じておくこと

 

‥‥が必要です。

 

 

ちなみに、最近までレイヤーをフォルダに格納した状態を「レイヤーフォルダ」という名称でこのブログで用いていましたが、Adobeの正式な呼称は「レイヤーグループ」のようです。

 

https://helpx.adobe.com/jp/photoshop/using/create-layers-groups.html

 

だが、しかし。 

 

‥‥スクリプトの英文マニュアルには「layer set」との表記があり、実際のスクリプト上でのタイプネームも「LayerSet」です。

 

俗称(他のソフトウェアの呼び名からの転用)も日本語呼称も、スクリプト作成時にいちいち読み替えるのが面倒なので、以後は英文リファレンスに従って、レイヤーセット、もしくはlayer set、LayerSetと呼ぶことにします。

 

 

話を戻して。

 

PSDファイルのレイヤー名やレイヤー階層を事前に規定・規約をしておくことで、コンピュータは「PSDファイルのレイヤーの中身を判断できる」ようになるのです‥‥が、それは人間とて同じことです。

 

例えば、「A3」レイヤーが存在する一方で、他のレイヤーセットの階層深くにもう1つの「A3」レイヤーが発見されたら、どっちが「本当のA3」なのか‥‥なんて、作った本人しかわからないですもんネ。「作った本人しかわからない」ものは、コンピュータも他人も扱いようがありません。

 

場当たり的な名前付けや階層構造は、著しく生産性を低下させます。当事者であっても、数ヶ月・数年経過すると、状況把握が困難になります。当事者ですら持て余す無整理・無秩序状態を、他者やコンピュータが理解できるはずもないのです。

 

まあ、だからと言って、「自動処理の都合に合わせて、人間が余計な労力を割いて従属する」のも本末転倒です。自分の仕事の効率化を図ろうとして自動処理を導入したら、コンピュータの流儀に何もかも合わせるのが重荷になって逆に仕事が増えちゃった‥‥というヤツですネ。

 

つまりは、

 

自分なりの整理整頓術と、自動処理のための状態管理の、接点

 

‥‥を探れば良いのです。‥‥まあ、往々にして悩ましいんですけど、あきらめずに攻略したい命題です。

 

 

話を本題に戻して。

 

繰り返しになりますが、今回の自動処理の達成目標は‥‥

 

PSDドキュメントファイルを開いて、もしくは開いているドキュメントの、レイヤーの状態を分析し、各原画やレイアウトのプリント用のTIFFファイルを生成する

 

‥‥です。

 

そのためには、まず何よりも、レイヤー構造の規定です。

 

3種類のパターンを想定しました。

 

 

 

常時表示したいレイヤーやレイヤーセットは、タップ穴の他にも、レイアウトフレームだったり話数やカット番号の表記だったり(レイアウト作業時)、白紙の背景だったり、色々ありますよネ。いちいち、全てのレイヤーに共通の表示パーツを複製してフラット化する必要はないですし、修正時(表記の間違いなど)に面倒でもあります。常時表示レイヤーの定義は必須です。

 

非表示レイヤーは、例えば提出時には不要だけど消去したくない下書きやアタリとか、メモとか、色々考えられます。常時非表示レイヤーも必須です。

 

順次表示レイヤーは、例えば、A1, A2, A3, A4‥‥のようなセルのシーケンスや、BG, BOOK1, BOOK2のような素材別のレイヤーを、個別出力するのに当然必要です。そもそも、この自動処理を作成する動機が、素材ごとの出力ですからネ。

 

レイヤーセットは、1枚のレイヤーへとフラット化したくない場合、つまり、1枚の絵を複数のレイヤーに分けておけたい場合に必要です。第1階層に未整理のレイヤーがバラバラっと乱雑に置いてあると整理がつきませんが、どんな状態であれレイヤーセットの中にブッ込んでおけば「それ以上は干渉されない」と規定しておけば、執拗にレイヤーの整頓に努めなくても作業は進みます。‥‥なので、レイヤーセットへの考慮も、規定では必須でしょう。

 

最後に「イメージシーケンス」のレイヤーセットです。まあ、普通に考えて、Aセルごと、Bセルごと、Cセルは1枚だからそのままで‥‥みたいな整理整頓はしたいですよネ。ゆえに、セルごと=イメージシーケンスのレイヤーセットを考慮し、その中に入れ子で「表示」「非表示」のレイヤーとレイヤーセットの内包状態を想定する必要があるでしょう。

 

イメージシーケンスをレイヤーセットにまとめて、中身を分析するのは、特に問題なくできましょう。スクリプト的には、レイヤーのタイプ判定してLayerSetだったら、その中身を「LayerSet.layers」により配列で取得して処理すれば良いだけです。

 

問題は、第1階層に存在するであろう、「1枚絵にフラット化したくないレイヤーセット」と「イメージシーケンスのレイヤーセット」を、どう見分けるか‥‥です。

 

一番スマートなのは、レイヤーの状態から分析すること‥‥ですが、ぶっちゃけ、今考えた時点では「何の状態をジャッジして分析するか」が思いつきません。

 

‥‥なので、今のところは、「レイヤーセットの名前から判断」するように規定します。イメージシーケンスであることを示す識別文字=ラベル文字列を規定して用いればよいです。

 

イメージシーケンスのレイヤーセットは、例えば「Aセル」の場合は、「A/」とか「a/」にして判別、ファイル出力時はレイヤーセットの中身のレイヤー名に準ずる‥‥とか、レイヤーセット名とレイヤー名を(スラッシュは抜いて)結合するとか‥‥色々考えられます。

 

気を付けたいのは、検索と置換とか、正規表現などで妙にてこずらないように、ラベル文字列を規定することです。後で、「何故、よりによって、こんな文字を使うかな。過去の自分の馬鹿馬鹿馬鹿」と後悔しないように、先を考えて規定しないとアカンです。自作のスクリプトで自分だけ自己嫌悪に陥るのならまだ良いですが、これが作業現場のシステム設計上だと目も当てられません。

 

う〜ん、どうしようかな‥‥。レイヤーセット名の文字列を「/」で終わらすというのは、安易かな‥‥。コメントの「//」と如何にも被りそうだから、たとえば「:」とかでも良いのかな。iPadで入力が楽な記号はどんなかな‥‥。‥‥いまのところ、文字の考えはまとまらず。

 

妙に長い文字列にすると、入力の際、面倒ですしネ。

 

まあ、常時表示と常時非表示のレイヤーも、レイヤー名の先頭文字列で認識しようと思っていますので、何かしっくりくる文字でキーボードで打ちやすい文字を探してみます。

 

 

 

今日はここまで。

 

もう、書けばすぐに動作するくらいには、考えがまとまりました。

 

ただし、「もし、ユーザのケアレスミスで同名のセル番号が存在した時、どのように動作させるか」などの「エラー対策」はまだまだです。書き出し処理を始める前に、レイヤーを全てチェックして、状態を分析する必要もありましょう。

 

 

 

 


AppleScriptのJavaScriptとExtendScriptのJavaScript

タイトルからして「Script」だらけでややこしい。

 

そして、実際もややこしい。

 

AppleScriptをJavaScriptで書ける‥‥という言い回しがそもそもややこしいですが、利点は大きく、AppleScriptにはないJavaScriptのMathとかStringやArrayの処理がAppleScriptにも使えます。文字列の分解とか配列の結合とかをAppleScript's text item delimitersに頼っているのは、なかなか厳しいですもんネ。

 

じゃあ、Photoshopのスクリプトを書くときに、AppleScript上でJavaScriptを使うと、どんな具合かと言うと‥‥

 

var app=Application("Adobe Photoshop CC 2018");

app.preferences.rulerUnits="pixel units";

var doc=app.Document({name:"TEST",height:1080,width:1920,resolution:200});

doc.make();

 

‥‥のような感じです。「1920px, 1080pxで200dpiの新規ドキュメントを「TEST」という名前で作れ」と言う命令文です。

 

実は、あわよくば、AppleScriptのJavaScriptとExtendScriptのJavaScript(あーややこしい)共用できる部分があるといいな‥‥と思ったのですが、

 

如何にもダメそう

 

‥‥ですネ。

 

ExtendScript、いわゆるESTKで同じ内容を書くと、以下のような感じです。

 

app.preferences.rulerUnits = Units.PIXELS;
var doc=app.documents.add(1920,1080,200,"TEST");

 

‥‥うーむ。共通しているのは、「app.preferences.rulerUnits」の箇所だけか。ESTKのPhotoshopだと、new Document()のコンストラクタが無いんですね。AppleScriptのJavaScriptとは段取りも違います。

 

まあ、たしかに、AdobeのExtendScriptでは、ドキュメントやレイヤーなどはコレクション(たとえばlayerならlayers=複数形で表す)からadd()するのが、昔からの流儀です。importOptionsとかはnewでもいけますが、コレクションオブジェクトのaddで大体は新作しますよね、AfterEffectsとかは。

 

 

まあ、今以上にややこしくしないために、おとなしく、PhotoshopのスクリプトはESTKで作って、必要に応じてAppleScriptはUI程度(Photoshopスクリプトを実行するための窓口)に留めます。

 

 

ちなみに、Photoshopのスクリプトに関するドキュメントは以下から入手できます。

 

https://www.adobe.com/devnet/photoshop/scripting.html

 

歴代のドキュメントが並んでいますネ。2018年現在の最新版はCC 2015みたいです。

 

 

 

 


AppleScriptのJavaScript

Pythonは楽しみですが、まずは目先の問題から。‥‥作画済みPSDデータの内容を印刷出力するスクリプトを書かねば、レイアウトや原画がアップするたびに手作業出力で時間がかかります。

 

AppleScriptで書いても良いんだけど、AdobeのESTKでPhotoshopは操作可能だし、ESTKのJavaScriptベースで書こうか‥‥と思いました。

 

‥‥が、そういえば、AppleScriptって、JavaScriptでもスクリプトが書けるようになったんですよネ。全く弄ってなかったですけど。

 

試しにお約束の「Hello, World.」を、おなじみの

 

tell application "Finder"

    display dialog "Hello, World." default answer "はいはい" buttons {"閉じる"} default button 1

end tell

 

‥‥ではなく、JavaScriptの流儀で、

 

var app=Application("Finder");

app.includeStandardAdditions=true;

app.displayDialog("Hello, World.",{defaultAnswer:"はいはい",buttons:["閉じる"],defaultButton:1});

 

‥‥にて実行してみたら、

 

 

‥‥の通りに。

 

 

あれれ、言語の翻訳がすごくラクだぞ。

 

display dialogがdisplayDialogに、default buttonsがdefaultButtonに、リスト { } が配列 [ ] に変わっただけで、覚え直しが極小で済む。‥‥って、まだAppleScriptに留まるつもりか?

 

どうやら、Math.sinなどの、JavaScriptのライブラリが使えるようなので、そりゃあ便利だわ。‥‥って、また、2018年の今、AppleScriptをやる?

 

 

ほどほどにしとこう。

 

じゃないと、せっかくPythonとか覚えようと思ってるのに、未練が残る。

 

 

 

 


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



calendar

S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 
<< January 2020 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

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