日々適当

仕事で素材をもらった時、その素材に関する指示をメールなどで文章でもらいます。そうするとその素材を保管するフォルダの中にその文章もテキストファイルとして保存するのですけど、保存したい文章をコピー→テキストエディタにペースト→それをフォルダに保存、って手順となり面倒です。

ちょっとでも楽にならないかなぁと作ったAppleScript。Finderのスクリプトフォルダに保存して、スクリプトメニューから実行するようにしました。

素材ファイルを保存したフォルダを開いておいて、保存したい文章をコピー→Finderでスクリプト実行、です。汎用性を持たせるためにファイル名は日付けにしてあるけど、使う機会はこの用途しかないから、単に「メール.txt」とかいう名前で保存するようにしてやってもいいかもしんない。

set cbString to clipboard info for string
if cbString ≠ {} then
	set copiedString to the clipboard
end if

tell application "Finder"
	if exists Finder window 1 then
		set curDir to POSIX path of (target of Finder window 1 as Unicode text)
	else
		set curDir to POSIX path of (desktop as alias as Unicode text)
	end if
end tell

set fileName to do shell script "date \"+%y%m%d%H%m\""
set fileName to fileName & ".txt"

set filePath to (POSIX path of curDir) & "/" & fileName

do shell script "touch " & filePath

delay 0.1

try
	set myFile to open for access (filePath as POSIX file) with write permission
	write copiedString to myFile
	close access myFile
end try

画像のアルファチャンネルでメッシュを切り抜くという機能を探してて、そんな機能のアドオンにkei2mってのがあったので入れてみました。このアドオンのページにリンク貼るとgooブログのエディタ上でなぜか不正な書式ってなるのでリンク貼ってません。

上図、右側のアルファチャンネルをもったテクスチャから左側のようなメッシュを作ってくれる。これはこれで素敵なのだけど、僕の目的には合致しませんでした。目的というのは、透明部分はアルファチャンネルで作りたいってことで、アルファチャンネルの形よりちょっと大きいポリゴンを作ってくれればいいってわけです。

まあその挙動をするアドオンは既に見つけてて、以前も書いたけど、Tesselate texture plane [github]ってやつです。検証した当時（半年ほど前）2.92以前のみって感じだったんですよね。だからBlenderの現行バージョンでも動くものを探してました。と思ってこちらのアドオンページ行ってみたら、三ヶ月前にPythonファイルが更新されてて、2.93と3.0に対応したようです。これは試してみないとね、と思ったのだけど、このアドオンはPythonのモジュールを二つインストールする必要があり、BlenderのPythonからpipを使ってインストールすると、そのうちの一つ、Triangleが失敗します。

失敗する場合、手動で入れろって上記 Tesselate texture plane のプロジェクトのページには書いてあります。けど、Python 3.10環境ではインストールできませんでした。<追記>どうも、M1 Macだと失敗するみたいでして、Intel Macでは3.1にも入れることができました。</追記>

あきらめて2.93を入れました…。2.93のPythonは3.9.2で以前やった方法で素直に入りました。

ちなみに Triangle ってモジュールを使って、ポリゴン内側の三角形分割をしてくれているみたいです。便利っすね、これ。

Thunderbolt 4 Proケーブル（1.8m） [Apple]

上のAppleStoreへのリンクのケーブルは1.8mがお値段税込14800円。3mが17800円となります。まあ高い。

2020年の夏に登場したThnderbolt 4のコントローラと一緒に発表されたThunderbolt 4の仕様では最大ケーブル長は2mとなっていたようで、実際、現在販売されているケーブルもAppleのこの製品を除くと2mが最大のように見えます。ではAppleの3mケーブルが規格外かというと、その仕様が発表されたときでも将来的には5〜50mのケーブルも出てくる見込みとなっており、2m超えも視野に入っていたことがわかります。

IntelがThunderbolt 4の詳細要件とIntel 8000シリーズコントローラーを発表[ASCII.jp]

ということで、他社より長い3mで不安になる必要はないものの、それゆえに高規格に作られているのがAppleのProケーブルということみたいです。これを分解した記事では

Apple純正のThunderbolt 4 Proケーブルはなんでこんなに高いの？を検証 | [PALMFAN]

AppleのThunderbolt 4 Pro Cableは、信号伝送を安定させるライセンス取得済みのIntelチップなどの、耐久性が高く干渉の影響を受けにくいプレミアム素材で構成されていて非常によくできているとしていて

金額的には特に不思議ではないことを示唆しており、他社が3m製品を発表してきたとしても同じような価格帯になってくるかもしれません。

個人的にThunderbolt 4ケーブルが必要だとして、とりあえずMacStudio周りの機材を繋ぐなら必要なケーブル長は1m程度なのでもっとお安く手に入ります。それでも4千円から6千円ほどはするんですけどね。Thunderbolt 3ケーブルでも代用できるって記事も見るけど、対Thunderbolt 4機器については安心安全のためにもThunderbolt 4ケーブルを買っとくのがいいのだろうなぁ。

コピペで済ましてきた人生なので、よく分かってなかったのですよ。たとえばファイルに青色タグ（青ラベル）をつけたいととき、ファイルに色をつけるのはFInderで set label index of [ファイル] to [ラベルの色番号] なのだけど、それを

tell application "Finder"
	set filePath to "/Users/userName/Desktop/test.txt"
	set label index of (filePath as alias) to 4
end tell

とかするとエラーになります。テキストで示されたパスはPOSIX fileに変換しないといけないということでした。

tell application "Finder"
	set filePath to "/Users/userName/Desktop/test.txt" as POSIX file
	set label index of (filePath as alias) to 4
end tell

素人感丸出しですなw 分かるまで30分溶かした。

ちなみにこちら、ffmpegで変換したファイルにタグづけしたくてやった処理なのだけど、ffmpegのコマンドを do shell scirpt させるのも苦労してました。2時間溶かしました(^^;

数式を出力する用事が発生したので、身近なところで数式入れられるのは何かなって思ったら、Apple Pagesがあったのでそれを使ってみたわけです。

フォントをいじれないかなって思っていたのだけど、それはできない模様。TeXの書式の範囲でイタリックとかそんなふうにいじることはできるけどフォントに選択の余地はないらしい。ちなみにその範囲内では

ローマン体
\mathrm
イタリック体
\mathit
タイプライタ体
\mathtt
太字
\mathbf
サンセリフ体
\mathsf

を受け付けました。

筆記体
\mathcal
ドイツ文字
\mathfank
黒板太字
\mathbb
花文字
\mathscr

この辺りは認識しませんでした。

まあ結局、こうして出力した数式画像は、積分記号の形が気に入らないからと没になったんですけどね。MacTeXを入れてそれで描画したデフォルト？のComputer Modernってフォントの数式でOKもらいましたけど、手軽にTeXの数式を作るなら、Mac環境でPagesって良い選択肢だなと改めて思った次第。ちなみにPagesで使われる数式のフォントはSTIXみたいです。フォントブック見るとSTIX Two Mathってのが入っているのが確認できるので、それかね。

ソースとなる映像素材の中にエラーのフレームがあるとどうもM1シリーズでのCompressor（Final Cut Proも）の書き出し処理に失敗するっぽい。

FCPで編集したタイムラインをCompressorに送ってH264でファイル出力しようとすると、エラーでエンコード処理に失敗することがあります。Compressor上ではそれは単に「失敗しました」ってメッセージが出るだけなのだけど、と共にそのフレーム数が表示されます。FCPから直接ファイル出力をするともうちょっと詳しい情報をもらえて、例えば

フレーム 76693の作成中にエラーが発生したため、操作を完了できませんでした（エラー（10004）: フレームの準備中。“0410”を00:42:38;29でレンダリングできません。
エラー（-12909）: ソースファイルのデコード中。“0410.mp4”を00:49:06;23でデコードできません。）。

となり、フレーム76693に問題があり、出力しようとしている動画ファイル内の00:42:38;29がレンダリングできないと言ってくれました。
フレームナンバーから直接FCPのタイムラインのどこかを知る方法を知らないのでちょっと困ったのだけど、それは00:42:38;29とたぶん一致するだろうからと該当フレームを見てみると、そこの部分、確かに絵がちゃんと来ていません。乱れてる。

ちょっと前から、エンコード処理はM1の方から早いからMac mini 2018ではなくMacBook Air M1 2020の方で行っていました。で、MacBook Airの方でエラーになるFCPのプロジェクトはあったのですが、Mac miniの方でやり直すと処理が終了していたので、今まではその問題をなんとなくスルーしていました。しかしメインマシンがMac Studioになったことで、ちょっと真面目に検証する必要が出て調べてみたらそんなことだったわけです。

エラーの出ているフレームをそのまま無視してエンコードしてくれるのと失敗するのと、どちらがありがたいかは状況にもよるでしょうが、今回は無視して適当に辻褄あわせてくれればいいよと思う種類の動画なので、これから問題が起こるたびに該当フレームを見つけるという対処をしなければならないのかと思うと、少しモヤっとするものがあります。
一方でお金をもらうような納品物を出力する場合は、問題がなかったかのように処理が完了するよりエラーで止まってくれた方がありがたいのは確かで、そんな意味では正しい挙動かもしれません。（一番いいのは、問題箇所の詳細を記したエラーを吐きつつ最後まで適当に辻褄を合わせて処理を終了してもらうことだけど）

<追記>

FCPのタイムラインをフレーム数で制御するとき、環境設定から時間表示をどうするかを設定するところで設定可能でした。

</追記>

というわけで、自己満足のためのベンチマークをしてみました。
性能は以下の通り。

Mac mini 2018にはeGPUでVega 56を繋いでます。

Compressor 4.6.1での結果。ProRes 422 HQ素材を変換設定のプリセットの中の「ビデオ共有サービス→HD 1080p」で変換にかかった時間と、H.264のmovファイルをProRes 422 HQに変換にかかった時間です。動画は29.97fpsで10分の尺のものを用意しました。

Mac miniと比較してH264への変換は1.6倍程度でしたが、ProResに変換する速度が桁違いになってますね。11.5倍。これはハードウェアを使ってのエンコードが強力ってことでしょう。これはM1 Max(Ultra)がもつProResのアクセラレーションの機能のおかげでしょうか。

Blender Benchmarkの結果です。これはMacBook Air M1 2020の結果も入れておきます。

こちらの結果を見ると、CPUこそMac miniの倍以上のスコアなものの、GPUはちょっと優っている程度ですね。だから単純に計算速度だけみるとちょっと期待外れな部分もありますか。MacBook Airと比べると、さすがにGPUコア数が4倍なだけあってそれなりにスコアが伸びてます（リニアに4倍とは行きませんが）。

ちなみに上図はベンチマーク中のGPU使用率の推移ですが、Vegaの方はパワーを使いきれてない印象があります。BlenderのMetalへの最適化はまだこれかららしいですが、それが進んだ時、あるいはVega 56がM1 Maxに追いついちゃうとかあるかもですか？

Blenderそのものでも回してみました。Blenderのデモシーン配布サイトで手に入る"monster_under_the_bed_sss_demo_by_metin_seven.blend"ってシーンでのレンダリングを見てみます。これはCyclesでのレンダリングで、GPUとCPUの両方を使うことができます。

少し興味深い結果が出ましたか。
Mac miniが遅いのはレンダリングを実行してから実際に計算が始まるまでのシーンのロードにすごく時間がかかったのが原因なのだと思います。あるいはユニファイドメモリであるM1シリーズのメリットがGPU、CPU両方使って計算するときに生きてくるのかもしれませんな。Mac mini 2018 + Vega 56でGPUのみで以前測った時は3m11sでしたから、CPUを加えることでむしろ大きく悪化しちゃっていることが見て取れます。ちなみにMacBook Air M1 2020ではGPUのみで8m56sでしたので、CPUを加えるとちょっと速くなります。Mac Studio 2022では（裏でSafariでウェブ見てたりしてたけど）2m57sでした。こちらはわずかに遅くなってます。…GPUを使うとき、CPUを加えない方がいいってことか？

もう一つベンチマークをしまして、ネット上で配布されているAfterEffectsのプロジェクトファイルを使ってのものです。AdobeMAX 2020のセッションで使用されるデータを集めるために配布されていたシーンらしく、結果は主にCPUでの計算速度を見ることになるようです。それをAEの最新バージョンで実行しています。（Premiere / AfterEffects 全国一斉ベンチマークとかで検索するとヒットすると思います。）

3.96倍ですね。これはなかなか大きな差がつきました。AEもApple Siliconネイティブになりましたからその恩恵でしょうか。ちなみにRosettaでAEを起動してやってみたら43sでした。Apple Siliconネイティブ版では何か処理が端折られているかと疑いますが、Rosettaから書き出したものと比較してみたところ、見た目上は同じモノになっていると感じました。なので（このプロジェクトを使ったアンケートをやった当時の人々の環境との比較はともかく）僕の自宅での比較では成立していると思ってます。

<追記>iMac Proの一番下のやつでやってみたら54sでした。ついでにCore i9-9900K/64GRAM/GeForce RTX 2080TiのWindows PCでも測ってみたら44s。いずれも3年以上前のマシンですが、その辺と比べると段違いな速さってことすな。</追記>

ということで、速度としてはそんな感じなのですけど、消費電力はどうだったか。ラトックのBluetoothワットチェッカーを持っているので、それで計測してみました。（今回は目視でリアルタイムの数値を観察。だから正確さには欠けます(^^;）

まず、アイドル持の数値は、Mac miniは51W〜67Wの間で推移しました。60W台になることはほとんどなく、だいたい50W台でした。ただし、これの結果はeGPUボックスに入ったVega 56も含んだ数値です。一つの電源タップにMac miniとeGPUボックスを繋ぎ、その電源タップに流れる電流を計測したので。ちなみにeGPUを繋いでいない時のAppleが公表している数値は19.9Wだそうです。一方でMac Studioは11W〜27Wの間で推移しました。だいたい10W台中盤で推移していました。Apple公式のMac Studioの数値は11Wということです。（Apple、Mac Studio (2022)の電力消費と熱出力情報を公開。[Apple Ch.]）アイドル時ではMac Studioの方がだいぶ少ないです。

それじゃ負荷をかけた状態ではどうかと言いますと、これは上記ベンチマーク結果のうち、BlenderのCPU+GPUの計算をさせているときの値で比較しました。Mac Studioが54W〜80Wの間で推移し、おおむね70W台中盤の消費という印象なのに対し、Mac miniは208W〜295Wで270W台で大体推移していました。Apple公式の情報ではMac Studioは最大115Wで、Mac miniは122Wということです。Mac miniはeGPUによる消費電力がかなり大きいということがわかるし、Blender的にはちょっとだけ上の性能を1/3以下の消費電力で実現するのだから、家計には優しくなりましたな。まあフルパワーで丸一日ぶん回してても、1台だけなら月の電気代はたぶん1000円、2000円とかそのぐらいしか変わらないのだろうけど、UPSも小さいのでいいし、それはメリットだろうなと思うわけです。

<追記>余談ながら、別件で1200W電源にGeForce RTX 3080Tiを積んだPCで上記Blenderシーンを回したところを計測して、600W強の数字が出ました。</追記>

というわけで、買ってよかったと満足感を得ることができたので、今日はぐっすりです。

<追記>Affinity Photoはヘルプメニューからベンチマークを実行できるので、ちょっと試してみました。なを、Mac miniは上記ベンチマーク結果と違い内蔵GPUのみの状態です。

Affinityシリーズはかなり真面目にApple Siliconに対応しているアプリなのではと思いますけど、そうすると対MacBook Air M1 2020であってもMac mini 2018は遠く及ばないスコアになっちゃいます。eGPUがアクティブになった際にどうなるかはちょっと分かりませんが、CPU側のスコアは変わらないわけで…</追記>

日曜日に出社したので振休取って、たぶん今年最後の桜見物に行ってきました。
長野県小川村の立屋の桜と呼ばれている桜とその周辺の桜たちの風景です。昨年、長野県に桜を見に行ってちょっと時期が遅くて悔しい感じだったのと、きっかけは忘れたけどそこの桜の事を知ったこともあり足を運びました。上信越道長野ICから西に進路をとり県道31号線に乗って途中で脇に入って、そこそこ細い道（休日で車が多いとすれ違いにちょっと難儀するかも？）をぐいぐいと登っていったところにある集落の桜たちって感じでしょうか。個人の敷地を駐車場として開放してて、そのうちの一番手前にあったところに停めさせてもらいました。ちなみにそこからの景色がこちら。

テンション上がります。
一番手前の駐車場に停めたので、目的地まで少し歩くのですが、このあと歩くところを大体一望できるところを通ります。

色の濃い桜たちが咲き誇ってます。画面左の車が止まっているところが桜見物のために開放している一番奥の駐車場あたり。一番右の少し白い桜がたぶん立屋の桜です。駐車場から奥に歩いていって、この敷地の所有者？が手入れをしているという桜の木々の中から山々をのぞんだりしつつ、

歩いて行くと到着するこちら↓が立屋の桜。

樹齢350年以上というエドヒガンザクラだそうです。ここいらの桜はピンクのが多いけど、台木はこの桜の種から生やしたものだそうです。それにベニシダレザクラを接木したと看板に説明されてました。

もう一個、名前がついている桜があって、それが番所の桜。この↑写真の一番色が濃い桜です。そこまで樹齢が古いわけじゃないみたいですが、こうしてみると一際色が濃いですな。

というわけで1時間ほど散策して満足してこの地を後にしました。

んで、まだ咲いていないって情報は仕入れていたものの、白馬村の野平の一本桜ってのに足を伸ばしてみました。いや、小川村での桜散策で気温はおそらく20度近くまで上がってたので結構暑く感じてですね。だから白馬の桜も開花が進んでいるんじゃないかと僅かに期待して、でございます。

…まあそうですよね。そんな一足飛びには咲きませんよね。見頃には一週間ほど早そうですが、こちらも背景の山が見事でした。桜単独の迫力としては福島県の滝桜を筆頭とした連中には敵わないと思っちゃったりしますけど、周りの風景の迫力が圧倒的なのがこの地なのでしょう。

白馬の桜見物は9年前に行って惨敗してまして（行ったのが遅すぎた）、しかし今回は逆に早すぎたというわけで、でも今回も惨敗するのはちょっと悔しいのでもう一箇所足を運びました。

大出公園です。前回は完全に桜の花が散ってましたが、今回は咲き始めで前回よりだいぶ花を見ることができてますな。

ということで、白馬についてもまあまあ満足して帰路につきました。

長野県は気温の地域差がとても大きいからか（標高差が大きい）、場所によって桜が咲く時期が結構ずれている印象で、車で30分程度離れた範囲の桜を両方ともいい状態で見れるってのはもしかしたら難しいのかもしれんすね。

移動距離は往復で630km弱。片道5時間はみておくべき行程となります。日帰りではこれぐらいが限界すな（一昨年900km超えを走ったけど、あれはダメだと思った）。そいえば行きと帰りで犀川あたりを通る際、ナビが違うルートを通しましたな。行きは旧道を走らせる感じ、帰りは有料道路を通されました。白馬長野有料道路でお値段210円。Googleマップによると有料道路を通ると3分短縮できたということみたいです。微妙ですw まあ相当走りやすいので、2025年に予定通り無料開放されたら、そっちがメインルートになるんでしょう。

昨日、注文してから36日目にようやく届いたMac Studioのセットアップをしておりました。 メインマシンとしてLC520から数えてどうやら10代目らしい（少し記憶が曖昧…）記念すべきマシンかもです。
Mac miniはその薄さですごくコンパクトに感じますけど、フットプリントこそ同じものの厚みが増したMac studioは、机上におくとなかなかの迫力です。ここまで厚いと、厚さではなく高さと呼ぶべきでした。
ところで、一体型Mac以外を机の上に置くのは個人的には珍しく、Mac miniすら机の下に置いてました。しかしMac studioはSDカードスロットが本体前面についてますから、そこへのアクセス重視で机の上に置くことを計画します。少し誤算だったのは使ってるDellのモニタの下には純正のスピーカーをぶら下げてたのでした。結果、スピーカー分モニタの高さを上げねばならず、少し視線が高くなったかなと思いますが、まあ慣れるでしょう。

環境移行はMac mini 2018からですから、Intel CPUからApple Siliconへの引越しとなります。そのため以前の設定は持ち込まず、手動で移行にする事にしました。とはいえアプリのインストールはApp StoreやAdobe CCといった、選んでインストールボタンを押すだけのものがほとんどで、インストーラをダウンロードしてから入れなければならないものは最小限で済むし、iCloudを通じて同期される情報も多いので、クリーンインストールであっても以前から見ると楽になりました。
/Users/[自分のユーザ名]以下のデータのコピーは、デスクトップやピクチャ、書類フォルダなどの中の必要なものをMac miniから有線LAN経由でコピーしたのですが、これも思ったほど時間はかかりませんでした。もちろん未だギガビットLAN環境なので通信速度は最大100MB/s程度ですけど、Mac miniもMac studioも内蔵のSSDが高速で（前者は3000MB/s近く、後者は7000MB/sあたり）、細かいファイル転送時も速度低下が昔に比べて少ないというのが大きいのかもしれません。
一番心配してた手動でのメール環境の移行も、必要ファイルとフォルダのコピーでとりあえずは新環境に持ってこれた模様。

結果として途中3時間ぐらい外出したり撮りためてたビデオ見たりしながら、夕方ごろにはとりあえずの環境構築は完了しました。他、足りないとこは必要になったら都度入れていきます。Homebrewも入れてないぐらいなので道は長いけど、ぼちぼちやっていきましょう。

とりあえず、Mac miniとの速度比較と消費電力比較をして満足感を得たいけど、それは来週かなあ。

以下、セットアップ中の画像を。

インストールされていたOSは12.3でした。

Drobo 5Dを動かすためにセキュリティーレベルを下げます。このユーティリティには、コールドスタート時に電源ボタンを押しっぱなしにすることで開く画面からアクセスします。

Rosetta必須です。そういえばParallelsでIntel CPU用Windowsが動かなくなってんだった。どうしようか…

AdobeアプリはApple SIlicon対応のものが増えてきました。プラグインを使わないならApple Siliconネイティブで動かしてもいいでしょう。

内蔵ストレージは高速です。

いやー、TexTools、入れとくべきでしたわ。UVアイランドをUV平面いっぱいに拡大したいとき、こいつで1発でしたわ。

半分に切った球のUVをいっぱいに拡大したいとき、この場合、一番上をセンターにしてV方向に二倍に拡大すればいいけど、こんなふうにわかりやすい形じゃない時、それなりに面倒なのですよね、Blender標準機能だけでやろうとした時。

そんな時はTexTools[GitHub]です。

UVを選択してFillボタンを押すとあっという間に、UV平面いっぱいに拡大されます。

このコマンドのためだけに入れる価値があると思いました。ちなみに隣にあるCropはアスペクトを変えずにUV平面にフィットさせる時に使えるみたいです。

<追記>…と思ったんですけどね。下図、左に対してFillを実行したら右になっちゃう。この場合、回ってほしくないのだけどねぇ。

</追記>

<追記>…というわけで、拙いスクリプトでカバーです。

import bpy
import bmesh

obj = bpy.context.active_object
bm = bmesh.from_edit_mesh(obj.data)

uv_layer = bm.loops.layers.uv.active

u = []
v = []
for face in bm.faces:
    for fLoop in face.loops:
        u.append( fLoop[uv_layer].uv[0] )
        v.append( fLoop[uv_layer].uv[1] )

uScale = 1.0/( max( u ) - min( u ) )
vScale = 1.0/( max( v ) - min( v ) )

for face in bm.faces:
    for fLoop in face.loops:
        fLoop[uv_layer].uv = ( ( fLoop[uv_layer].uv[0] - min( u )) * uScale  , ( fLoop[uv_layer].uv[1] - min(v) ) * vScale  )

bmesh.update_edit_mesh(obj.data)

たぶん無駄な処理をしているけど、一応目的とするところはできている。速度は知らんw

</追記>