This page is a personal scratchpad.

• 6月半ばからGlisp開発関連の一切を辞めている。
• 逆説的に制作がドライブするようになってきた。
  • 数年ぶりにMVが進んでいる。
  • 久々にアートワークを作ったり、学生以来Illustratorで友達のZINEを作ったりしている。
• ツールを作ったり、プラグイン開発などを通してツールを改変する能力を持つということは、普段の制作のなかでも常に「この制作環境をより良くすることが出来るかもしれない」という可能性が脳裏にチラつくことを意味する。
• ツールの改変をハックや誤用、転用のように、イレギュラーな行為ととして捉えているうちは、ツールをありのままに使うことはあくまでレギュラーな行為であって、それ自体にフラストレーションが溜まることは少ない。
• しかし、ツールの拡張性、自己改変性を、あって当たり前のものと捉え始めた時、ツールをありのままに使わざるを得ないことは苦痛へと変わる。ツール開発は、拡張性の低さというマイナスをよりマシなマイナスにするという敗戦処理へと変わる。
• 可塑的（malleable）なソフトウェアという意味では、プログラミングや、プログラミングのためのツールに触れた体験は大きかった。一つコンピューターが本来持つ柔軟さ、アラン・ケイのいうメタメディアとしてのそれを、感覚的に知ることが出来た。
• その分、映像編集にしてもグラフィックをつくるにしても、そうしたクリエイター向けのソフトウェアが随分と低いレベルにあるのだなと悲しくなってしまう。頭の中で渦巻くパラメトリックな思考、ポリモーフィック（多相的?）な思考に、ソフトウェアが追いつかない感覚があるというか。
• そして、そんな状況をツール開発を通して変えることが出来るかもしれないと考えてしまうこともまた、一つの認知負荷になり続けている。
  • 僕一人でツール開発をして、僕一人で使っても、規模の経済は効かない。だけど、もっと多くの人に使ってもらえるものを作ったらどうだろうか。僕が使う分にはギリ問題ないツールを即興でハックするよりも、ある程度の汎用性と一般性を備えた、より大きな「作り方を作る」ための枠組みがあれば、皆幸せにならないかな。
  • だけどそれは、一作り手としての自分の時間を犠牲にすることになる。
  • また、既に可視化されている需要に応えることは、僕でなくても早かれ遅かれ誰かがやる。「人はそれを提示されるまで、それが欲しいことに気づかない」とはよく言ったものだけど、僕が作ろうとしているのもはそういうものなのかもしれない。スプレッドシートという概念を知らない経理部に、SUMIF関数の便利さを売り込むようなもの。報われないな。
  • とかとか。
• ツール開発の一切をやめて、イラレでノンブルを1から38まで手で振るということは、その反復の冗長さという無駄よりも遥かに、そうした頭の中のグルグルに付き合わされずに済むというメリットをもたらしてくれる。どういうわけか、効率も良くなる。目の前の制作に脳死で集中できるから。「脳死で集中」って、はなから矛盾してるけど。

• Adobeとの因縁でいうと、昔、Behanceのクリエイター特集でメールインタビューを受けた。
• 今はドメインごと消えているので、Gmailを検索して引っ張り出してみる。
  • プログラムとAdobe製品はどのような表現方法で使い分けをされておられるのでしょうか？

    • 使い分けは特には意識していません。AfterEffectsのエクスプレッションは、気軽にパラメーターをプログラムで制御出来る機能なので頻用しています。ExtendScriptなどを使って自動化をすることはもちろん、PixelBlenderを使って、AfterEffects用のエフェクトを書くこともあります。「こういう表現はプログラムで」という考え方ではなく、どちらかというと、普段の制作においてもパラメーターの調整に泥臭く手数を注げるようにするために、プログラミング的手法を自然と取り入れているという感覚があります。ですから、コマ撮り、VJ、モーショングラフィックス、ジャンルは問わず何かかしらコードは書いてると思います。（個人的にですが、ExtendScript自体をES6対応してほしいのと、PixelBlenderをGLSL準拠にした上で、CCで正式にサポートしてくれると嬉しいと担当者の方にお伝え頂けると嬉しいです…。）

  • さらに、橋本さんのようなハイブリッドな制作方法をされる理由と利点などについてもお教えください。

    • ツールから作る一番の理由は、Adobeに限らず、既成ツールの設計思想にストレスに感じるからです。例えば、AfterEffectsやPremiereは「前のフレームのパラメーターに差分を加えて現在のフレームを生成する」といった処理ができません。もしそういったことが可能だったら、イメージがドロっと溶けていくような映像を簡単に作れますし、速度に対してキーフレームを打つことができます。Illustratorのグラデーションの形状はリニアと円形しか選べません。（2016年当時）だけど、時計のように角度でグラデーションしたっていいわけですし、エッジからの距離に応じてグラデーションがついてもいい。時間はかかってしまいますが、そういう、「思いついちゃったはいいけど、普通にツールを使うだけだと難しいようなこと」を実現するためにプログラミングを併用しています。そもそもプログラミング的な考え方で映像やグラフィック制作を捉えていないと、ツールの機能として出来る範囲で考えるばかり、そういった可能性にすら気付けなくなってしまう。そっちのほうが怖いです。

• 今と言ってることが全く変わらない。7年前なのに。
• 恐らく言わんとしたかったことは、プログラミングは新奇なことでも、褒めそやされることでもなく、コンピューターが持っていた本来の可能性を取り戻すということ。ましてや、褒めそやされることでも、作家のスタイルとして押し出すようなことでもない。だからあくまで僕がしていたのは、Adobeがそのeasyさと引き換えにクリエイターの眼前から隠してしまったものにアクセスしようとしているだけであって、本来はAdobe自身が向き合うべき課題だと思っていた。
• というようなことを、Behanceのインタビューを引用しながら恐らく大人げない感じでシャウトしていたら、インタビュアーだった斎藤あきこさんにこのような反応を頂いた。

• 地球上でその機能を必要としている人のボリュームゾーンというものと、Adobeが私企業であって神さまとかお母さんじゃないということなどがあるかと思うのですが、プログラムで作品を作るメリットはツールに縛られないということですね。
  

• 悲しくなって、Adobeの知り合いに連絡してインタビューを取り下げてもらうことにした。もっと穏健なやりようがあっただろうにと反省している。
• ともかく、「僕の欲しいアレとコレを実装してくれなきゃやだ、Adobeは大馬鹿だ」と駄々をこねているのではなくて、ソフトウェア・エンジニアリングの世界がそうあるように「僕なり皆それぞれが欲しいと思う具体的なアレとコレを実装しやすくするための抽象的な仕組みを実装して欲しい」という、マトリョーシカのような二段構えのお願いをしたかったんだと思う。
  • PixelBlenderがそうだったように。
  • そうしたソフトウェアとしての自由さに対するニーズも、ソフトウェア・エンジニアリングの世界と異なり、デザインの世界ではあまり多くないことは客観的に理解している。しかしそうした視野狭窄状態を作り出したのもまた、Adobeのようなベンダーなのではないか。
  • 以来、「Adobeはお母さん」じゃないは僕のなかのテーゼであり続けている。知らないですけど。

• Adobeの功罪。
• PostScriptのようなローレベルな仕組みを、直感的で高級なアプリケーションで包むことで、多くの人達に門戸を開いた。だけどその多くはsimpleではなくeasyなアプローチによるものだった。
• あまり使われない機能は実装しない。細かい機能はオプションとして隠す。（Progressive Disclosure）。
• ユーザーとデベロッパーを厳密に区別し、作ることと、作るための仕組みを整えることを、スキルとして完全に分離した。
• その前提には
  • ある種のパターナリズムがある。（UX Paternalism）
    • ユーザーはギークでもなければ、多くの時間をいたずらに割きたいわけでもない。
    • だから、彼ら彼女らが路頭に迷わないように、複雑なものをは見せないようにして、拡張性を匂わせないようにする。（ジャムの法則）
    • そして、ユーザーを導いてあげる必要がある。とりとめのない自由で惑わせるのは、ユーザー体験を損ねる。
  • デコラティブな意匠（ガワ）の部分と、デザイナーがフォーカスすべきより本質的な構造とがある。という二元論的デザイン観。
    • コラボレーション機能、レビュー機能の充実。

• 作ることと、作るための仕組みを整えることは、どれだけ違うのだろうか。
  • プログラマーは、エディタやコンパイラというプログラムを用いてプログラムを書き上げる。手段も成果物も同じプログラム。 Emacsを使うLispハッカーは、Lispという一つのスキルを、何かを作り上げるためにもエディタを拡張することにも使うことができる。
  • だが、絵描きによっての絵という成果物は、手段としての画材とは全く種類を異にする。同様に、モーションデザイナーはキーフレームを打つことでAfter Effectsを作ることはできない。
  • しかしそこで見落とされがちなのは、「絵を描くスキル」「動かすスキル」の定義はとても恣意的なものだということ。
  • かつての職人は、自分の道具を自作していた。むしろ、道具を作ること、手を入れること、使うこととが、今ほど厳密に区別されず、なだらかに繋がっていた。

    • Design Software is an open issue because part of a designer’s work is to choose and question their tools. ” （
      Designing Design Tools ）

    • 
  • デザイナーが商品として規格化された道具を購入し、それを用いて制作することに集中することが出来るようになったことは、産業化があってこそのもの。どういった意匠にするか、どういった構造にするかという成果物に対する思索のみがデザイン行為として蒸留され、その思索のあり方そのものに否応なしにバイアスを掛けるツールやテクノロジー、環境の存在はますます透明化され続けてきた。そうした具体的で技術的な制約と向き合う人々は「現場」の人間として、職人としてのリスペクトは受けると同時に、具現化するノウハウを体得した職人であって、何かを考え出すクリエイターではないとして、疎外も受けてきた。（要出典）
    • ちょっと話が極端になってきた。そのレベルで手工業的なプロセスの一切から離脱出来る立場って、デザインにおいてもかなり限られてない？
    • アートディレクターとか。
  • 日本のソフトウェア産業におけるSE（ソフトウェア・エンジニア）も、ある時期まは設計や仕様定義のみに関わる管理職で、彼らの指示のもと実際にコードを書くプログラマーを従える存在だった。
  • 言語が十分に高級かつ抽象化されたものとなれば、コードそのものが仕様となる（≒ self-documented）。むしろ設計と実装を分離することは非効率であるという考えが主流になり、少なくともWebやアプリのようなモダンな環境においては、両者を厳密に区別せず、プログラマーが全てが担うようになった。つまり、ソフトウェア開発をするスキルに「コーディング」というものが含まれない未来もあり得たということ。
    • そこまではいかずとも、あくまでSEとしてのディレクション能力を高めるために、下積み段階で身につける現場のスキル、くらいの認識になり得た未来もあった
  • 何が言いたかったかというと、何かを作るスキルというのは、そのメディアや技術に内在する性質ではなく、単に産業構造や商習慣による惰性的で恣意的な部分も大きいということ。モーション・デザインという職能に（それがコードを直接触るのか、ビジュアル・プログラミング的な仕組みでもって抽象化されたGUIに触れるかは問わず）プログラミング的思考は必ずしも必要ないと見做されているのは、何かを小気味よく動かすアニメーター的センスと、グラフィックや動きをパラメトリックに捉えるセンスとを混在させづらい環境がそこにあるから。
  • だから、プログラマーにおける「作ることと、作る仕組みを整えること」の垣根の低さをデザイナーにそのまま要求することは出来ないという批判には、デザイナーの職能を「誰かが作った仕組みをただ一方的に利用し、作ること」だけに追いやった産業と、そうした上京を進んで内面化したデザイナーが共犯的に招いた結果でしかないと反論することができる。
• そもそも「作るスキル」と「作る仕組みを整えるスキル」は、メディアや表現手法によって予め定まっているものではなくて、そこに携わる人達の自助努力によって意識的に近づけることが出来るもの。
  • スキルの同図像性。仕組みを用いて仕組みそのものに言及できる。自己言及能。
    • Cのマクロは #記号から始まる記法によってCそのものの文法からは区別されるが、Lisp（やそこから影響を受けたJuliaなど）は、その文法そのものでコードに言及・改変することができる。（True Macros）
  • Emacsも、その開発言語としてより低級なコンパイラ言語を選んでもよかった。だけど、70-90年代の貴重な計算資源を差し置いても、インタープリター言語としてのLispや、そうした同図像性を（エディタの用法のなかでエディタを拡張できるという形で）エディタに導入するメリットを開発者たちは理解していた。
    • いや、この辺相当都合よく解釈している気がします。
  • Houdiniアーティストの多くは、Houdiniの操作体系の内側から、デジタル・アセットのような形でHoudiniに新しい機能を追加することができる。自作機能をよりローレベルな部分から最適化したい人だけが、C++ SDKや外部開発を用いてHoudiniに「外部から言及」する。
  • デザインツールだって、いくらでも同図像性のようなものを導入することができた。AdobeにおけるPixelBlenderや、多くのDCCツールにおけるPythonジェネレータのように。コードを介する形でなくとも、GenArts SapphireのEffect Builder（エフェクトを組み合わせて新しいエフェクトにバンドルする機能）のように、ビジュアル・プログラミング的な仕組みを用ながらツールの機能を用いてツールを拡張する方法をデザイナーに提供できた。
• それを怠ったのは単にマーケットの需要が無かったから。そもそも別にそんなに効率性も表現の『新しさ』も世の中求めちゃいない。
• そう言ってしまえばそうなのだけど、ここまで作ることと作る仕組みを整えることが世界として分離してしまったこの状況は、個人的にあまりおもしろくない。
• 実際に、DTP黎明期の頃はどうだったんだろう。ツールに手を入れること、少なくとも疑いの目を向けることは、デザイナーの態度としてそう珍しいものではなかったのではないかと想像したりする。
  • PostScriptを直書したり、Design By Numberを開発したジョン・前田や、Illustratorのプログイン「信用ベータ」を開発していた立花ハジメがいた。時代が下っても、Scriptgrapherを開発したJürg Lehniのようなデザイナーは居た。
  • 実際どうなの？　立花ハジメ自身がコードを書いた？
  • 書いてない（関係者）

• Gen-Arts近辺の身として「僕こそがSTEAM教育の賜物だ」という自意識がある。思い出してみる。
  • プログラミングをはじめたのは12歳の頃。「小学校5・6年生にもわかるやさしいJavaScript」がきっかけ。実際5・6年生だったし。アラートでYes/Noが分岐してif-elseがネストする、何か心理テストのようなものを書いていた気がする。
  • そこから図書館で借りたCの本でコンソールアプリを作りはじめる。圓和道 に一緒に通っていた友達と、送迎の車の中で、対向車のナンバープレートの数字4つを加減乗除して10にする遊びをしていたので、それを総当りで調べるプログラムを書いたっけ。文字の色変更、描画位置の行・列指定を覚えて、上から落ちてくるASCII文字を避け続けるゲームを作っていた
  • そこからVisual C++、C#を覚えた。やっぱりGUIアプリを作りたくなったので。Windows VistaのAeroインターフェースがとても好きで、僕にとっての「舐めたくなるようなUI」はそれだった。Visual Studio上でボタンやプログレスバーを好きなだけ配置できるだけで涎が出るような体験だった。あのすりガラスの質感をウィンドウ全体に適用する方法や、透過したフレームレスウィンドウにラジオボタンだけを配置して宙に浮かせる方法を調べて、GUIパーツを使ったブロック崩しを作った。ブロック（ウィンドウ）が消える時のアニメーションも含めて、とてもsatisfyingなものを作ることができたのを覚えている
  • 中2の頃にiPhoneが発表され、その翌年にiPod touchを購入してもらう。当時はJailbreak（脱獄）する方法が流行っていた。App Storeも無く、Cydiaなんかがあったっけ。2D物理シミュレーションエンジンのBox2D（だったかな）をiPhone OS向けに移植したSandboxで、ビー玉ころがしゲームを作ってリポジトリに追加してもらったことがある。
  • その頃に、クラックしたPhotoshopとIllustratorのCD-ROMを、何故か祖父の友人に貰った。特にスクリプティングに手を出す訳でもなく、プログラミングとグラフィックを作ることは同じ「パソコンいじり」の中で混じること無く同時並行していた。
  • Generative art的なものに初めて触れたのは、WOW/未来図画工作の鹿野護さんの『Quartz Composer Book』がきっかけ。高一の頃にMacBook Proを祖父に買ってもらったので、スクリーンセーバーを作ることが出来るという触れ込みにワクワクした。
  • Processingに触れたのは、推薦入試が終わって勉強する気が失せた頃だった。ActionScript 3は、推薦合格した人でも受ける規則となっていたセンター試験をサボり、その自己採点のための登校日にやることがなかったので勉強したのが最初。Flashよりも先にFlash Builderを触っていたことになる。
  • openFrameworksは大学中退してからかも。