日々適当

コピペで済ましてきた人生なので、よく分かってなかったのですよ。たとえばファイルに青色タグ（青ラベル）をつけたいととき、ファイルに色をつけるのは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

</追記>

3/29に出荷完了ってメールが届いて、AppleCare+登録書が3/30に届き、そこには こんな←感じのことが書かれていたのですけどね。出荷されたから（おそらくそこから予想されるお客さんへの到着日を基準に）保証終了日が設定されたよってことだと思うのだけど、25年4月4日が終了日になってます。

そして商品の現在のステータスがこちら→
まだ出荷完了で止まってます。配送状況を確認するとまだ「海外荷物受付」ってステータスで場所が「上海支店（中国）」となってました。あらためて、MacからSafariで商品のステータスを見ると「配送遅延」って状況になってましたから、遅れていることは認識している模様。

さて、Apple Careの終了日がこれにより更新されることがあるのかないのか。仮に当初の予定日いっぱいの4/15に届いたとしたら、10日も保証期間が短いということになります。

3年の期間のうち10日って小さいようだけど、（Appleの製品じゃないけど）3年保証の残り一週間で修理依頼をしたことがある身からすると10日って結構大きいので、出荷されたところでちょっと聞いてみましょうかね。

<追記>と思ったら唐突に届きました。
4/14に出荷指示とかされて同日9:45にADSC支店に到着しすかさず発送されてる模様。この時点で既に日本国内にいるわけで、夕方に到着しました。
セットアップいつしよう…</追記>

そういえば4日にワクチンをうってました。3回目接種。
3回全部モデルナワクチンでしたけど、1回目の初日は腕が痛くなったぐらいで二日目午後に37度を下回るぐらいになり三日目はほぼ普通に暮らし、2回目接種では翌日に37.7度まで上がったもののさらに翌日はちょっと高めかなって体温で普通に出社してました。で、3回目である今回、接種翌日は38度台から始まって午後に37度台後半で推移、その翌日は体温は下がったものの１、2回目には無かった調子の悪さが残る状況でした。3回目が一番状態が悪かったかな、って感じです。3回目接種日から3日目には大体回復できて往復500km超ドライブとかできてたけど、もともとこのドライブは1回目・2回目の経験から、うった翌々日に行くつもりでした。でも翌々日は流石にそれは無茶な体調だったと思います。
ということで話に聞くすごく体調が悪化しちゃった人に比べれば全然楽な状態だったと思いますけど、そんな体調の推移を思うと、すぐ4回目うってねって言われたら「ん〜？」って思います。

うったところは左肩で、そっち方向への寝返りがうてない（痛い）ってのは地味に困りました。結果姿勢が制限されて腰が痛くなる。寝具のせいってのも当然あるので、こんな寝返りうてない状況になった時に備え、いつかその辺の環境に手を入れたいす。

桜の早いところはもう完全に散っていたり終盤といった雰囲気になる4月頭、そんな地域の山梨県に足を運びました。身延山はもう完全に終わっていた感じだけど、北杜市あたりはまだギリギリ大丈夫かな、って状況だったようなので、話に聞く、神代桜というのを観に行ってみようかと思った次第。

それだけ見るってのもなんなので、もう一本ぐらい一本桜を見ておきたいと思った時、ちょうどいい位置関係にあってまだ花が残っているっぽい桜にわに塚の桜ってのがありました。

これはとても良かったですね。見応えがありました。散り始めって時期であるので、来年以降、これを目的にここに行ってもいいかなと思いましたです。

この桜が韮崎市にあって、そこから甲州街道を北上すると山高神代桜がある地に至るわけですが、何気にこの辺りってスーパーカブの舞台だったりしたのですね。ってことで、せっかくなので、釜無川橋ポケットパークに寄ってみたりそこから牧原交差点を渡って高校のモデルになった中学校の横を通って神代桜のある実相寺に行ってみたりしました（あるいは交差点から甲州街道を南下するルートを走ったり）。

ちなみに北杜市は4/9〜5/8にスーパーカブのスタンプラリーをやるそうです。行ったのがちょっとはやかったすな。ポスターがいろんなところにはってありました。

そして、神代桜です。

二千年以上ってのは伊達じゃない風格と言えば聞こえがいいけど、その大きさにはちょっとがっかりするかもしれません。周りの桜に埋もれてしまっているなと。
この大きさなのは、人間がやらかしちゃったせいってのもあるみたいで（祭り上げるために周りを囲ったり盛り土したり（ウィキペディアによると））、その回復措置を2003年から2006年にかけて行って今に至るみたいです。写真をとってたら前にいたおばちゃんたちが「昔見たのよりだいぶ元気になってる」って話してたので、うまく行ったのでしょう。

この桜がある実相寺境内は桜に力を入れているらしく、各地の名木の子孫を育てて、それら桜を飾るように花が植えられてて、なかなか見事でした。桜が散り始めの時期じゃなくて、満開になりたてぐらいにまた来たいですな。

ということで、これで目的はほぼ終了し、あとはノープラン。せっかくここまで来たので、もうちょっと桜を見て、そしたら夕方近くになったので帰路に着く、そんな感じでした。

神田の大糸桜はちょっとはやかったみたいです。来週ですかね。

今年は開花が平年に比べるとちょっと早いのですかね。平年並みって開花なら、年度末の忙しさを切り抜けた後である今頃に足を運べれば、いい状態の桜たちをこの辺の地域でみれるかもしれませんな。