日々適当

次期｢iMac Pro｣は12コアCPUを内蔵した第4のM1チップを搭載か |[気になる、記になる…] 1/24

大型の新型｢iMac｣はM1 Pro/M1 Maxチップを搭載して｢iMac Pro｣として登場か [気になる、記になる…] 1/30

Apple Silicon化の残りはMac Proと性能の高い方のiMacと性能の高い方のMac miniなので、この辺の話が出るのは当然だと思うので特に思うところはないのですけど、MacBook Proよりも発熱や電力に余裕があるであろうiMacなのでMacBook Proより性能が上のものを搭載してほしいものです。12コアCPUに64コアGPUとか来ませんかね。128GBメモリとか。お値段もすごいことになってきそうだけど、噂通りiMac Proって名前なら初代iMac Proは60万円弱スタートの価格帯だったし、そんな構成も望みたいものです。まあ噂されているMac Proは40コアCPUに128コアGPUだから、その足元ぐらいの性能をiMac "Pro"は搭載してくるだろうと期待しましょう、うん。
Mac miniは常識的に考えてMacBook Proと同じような性能だろうけど、Mac mini 2018登場時の価格帯で出てきてくれるならまあいいかなと思います。iMacを買うつもりはないけど、Mac miniはたぶん真剣に検討するんで、検討させてくれる内容とお値段を期待したいものです。

にしてもeGPU対応してくれませんかねぇ、ほんと。AMDがドライバ書いたりそれをAppleが許可したいるするのもハードル高いのかもしれんが…

PhotoCatchってツールで、Montereyが動くMacでのフォトグラメトリが実現するようです。Montereyで用意されたObject Capture APIを利用しているようで。
（iOSアプリの方で素材を撮れば深度情報を付与した状態で処理されるようですけど、モデル生成処理はクラウド上で行われるということもあり、その処理は有償になっているようです（$0.99だから、ゴミモデルが出来上がってくるのでなければ、十分コストパフォーマンスは良いと言えましょうが）。）

ともあれ、Mac版をダウンロードして利用してみましょう。

自転車のサドルに乗っけて、こちらの靴をぐるぐると撮影すること85枚。それらをこのアプリに食わせてみます。

シンプルなUIっすね。書き出しフォーマットはusdz、obj、daeとなる模様。Model Qualityはデフォルトでは一番低い解像度になっているようです。とりあえずPreviewのクオリティで実行してみますと、Mac内部で処理が実行されていきます。なを、eGPUを繋いでいても内部GPUでの処理が始まってしまう模様。（まあこれに気づいて「外部GPUを優先」のオブションをオンにするために一回アプリを強制終了さたあと、マシンを再起動せずに処理を再実行しているので、うまくeGPU優先になってない可能性はあるけど…）
このエントリを書いているのはMac mini 2018上なのだけど、せっかくなので裏でM1 MacBook Airでも動かしてみました。そちらはクオリティをRawにして走らせます。プログレスバーがあっという間にMac mini側を追い抜いていったけど、処理後半でMac miniの方も遅れを取り戻しているし、これぐらいのモデルなら実用的な処理速度なのではないかと推察いたします。

処理が終わるとこんな感じで結果が画面に表示されました。とりあえず下の方に明らかにいらんものがくっついているので、それをCropしてから書き出してみました。usdzでSaveします。
残念ながらusdzはBlenderではそのままでは読めないので、拡張子をzipに変更して伸長します。出来上がるフォルダの中にexport.usdcファイルが入っているので、それをBlender 3.1 beta版でインポートしてみました。（なを、後述するようにテクスチャ素材が要素に分離されて出てくるわけではないので、DCCツールに読み込ませるのなら素直にobjやdaeにしとくのが吉でしょう。）

左がPreviewのクオリティ、右がRawです。Rawが35万ポリゴン、Previewが2万3千ポリゴンでした。出力されてくるテクスチャはPreviewが1K、Rawが8Kでした。焼き付けられたテクスチャしか出てこないので、他のソフトに持ち込んで綺麗にレンダリングしようって用途にはちょっと問題が起こる可能性はありますか。Object CaptureのAPI的にはColor, Normal, AOの各マップを出力するようですが、この辺は各アプリケーションの味付けってことですね。

ということでOSのAPIを利用してこのクオリティということで、今後の進化に期待したいです。鏡面やガラスをうまくキャプチャできる未来は来るのかどうなのか…

ちょっと前からキーボードを探してました。でまあAmazonでセールのたびに少し安売りをしているリアルフォースをカートに入れてみたり外してみたりしていたのですけど、さすがにキーボードに3万弱の価格は厳しいかと思っててポチッとするところまでには至らず、そうこうしているうちにロジクールMX Keys（Mac用） [ロジクール]に目がいくようになりました。評判もいいようです。価格もリアルフォースの半額近く（この感覚を得たので、リアルフォースで迷った甲斐があるというものです）。

ということで注文しました。幸いクレジットカードのポイントが貯まっていたので、それでほとんどの金額を賄えましたが、それにしても1.5万円という価格のキーボードを自分で使うのは、Apple純正品以外では初めてとなります。

届いた箱を持ち上げてまず思うのは、意外と重い、ということでございます。キー入力中にキーボードが動くのはよろしくないから、ある程度の重量があるのは必要ということでしょう。カタログスペック的には810gということです。同社の最安値クラスのものが550gですから、それと比べてキーボードの安定感が増すことは期待できましょうか。ちなみにAppleのキーボードはそれよりもさらに軽いです。現在売られているMagic Keyboardのテンキー付きのタイプが369gだそうで。

丁寧に包まれておりまして、その梱包を解くと、

付属品はこんな感じ。充電用のUSB-Cケーブルとレシーバです。このレシーバ、本体に収納できないのなか？と思ったのですけど、それはできなさそう？ 接続は基本的にBluetoothなのでこのレシーバを使う予定がないから、無くしそうです。

ともあれ、接続です。Apple純正のキーボードのようにUSBケーブルで繋いでいる間はUSBキーボードとして動くのかと思っていたけどそんなことは無いようでした。Macとのペアリング前にUSBケーブルで繋いだら認識されないし、Bluetoothでペアリングした後、USBケーブルを繋いだままMacの設定でBluetoothをオフにするとキー入力を認識しないのでそうなのでしょう。

ということで使い始めました。これまでKVMのUSB部分だけを使って2台のMacを操作していたのだけど（モニタがDVI非対応のため使えなくなった）、Bluetoothで接続することにしたのでKVMはお役御免。マウスも切り替える必要があることから、マウスも去年買ってから放置していたMX Anywhere 3 for Macに変更しました。結果、キーボード・マウス・ディスプレイを個別に切り替える必要があり、マシン切り替えの手間は大きくなりました。二台目のMacを画面共有で使う率が高まりますなこれは。同じMXシリーズのキーボード・マウスなのだから一括で切り替えられると便利なのにね。できないのかね？USBレシーバに複数の機器を登録することができるみたいだから、これをUSB切り替え機（KVM）に繋いだ上でキーボードとマウスをレシーバに登録しておけばできるだろうか？…やらんけど。

ということで使い始めました。使い始めて数十分なので、今のところ以前のキーボードとの違和感の方が大きくて、買ってよかったのかどうかはわかりません。まあキータッチは向上しているように感じるので、これでこのキータッチが長持ちするなら良い選択肢だったんだと思える日が来るでしょう。

<追記>キーのピッチがApple純正品より大きいのかな？ ショートカットとしてCommand + Bをよく使うのですけど、親指でCoomandキーを押して人差し指でBを押すとき、Apple純正では特に問題なく使っていたのだけど、このキーボードにしたら指がちょっと辛い。ために薬指でCommandキーを押しての人差し指でBとなりそうです。
マウスについて機能を知らないために誤解していたことがありました。MX Anyware 3はホイールによる高速スクロールが売りなのですけど、裏返すと、ものすごくスルスル回ってくれます。結果、中ボタンクリック時にホイールが回っちゃったり、ちょっとホイールに触れると表示しているページが少し上下に動いたりして、微妙に使いにくいなって思っており、それゆえに一年前に買ってから放置していたのですけど、大きな誤解でした。ホイールに抵抗感があるモードとないモードをホイールの後ろについているボタンで切り替えることができた。抵抗感がある状態にすると、カリカリと段階を持ってゆっくりとスクロールさせられ、不満がなくなりました。1年もったいないことしましたな。</追記>

<追記＞使用を開始して一週間。マウスのホイールでのスクロールが効かなくなりました。結論としては、アクセスビリティでロジクールのツールが許可されていないことが原因でしたが、これはもともとオンにしていなかったのか何故か昨晩その症状が顕在化したのか。

ともあれ、この両方のLogiとついたツールの制御を許可してあげるとホイールが動きました（正しくは Logi Options Deamonはオンになってたけど、Logi Optionsはオフになってた）。</追記>

早いですねぇ。もう3%も2022年が過ぎてしまった。

今年の頭の気温が冷え込んだ関係で、これは期待できるかもと袋田の滝に行ったりしました。関東で大雪警報が出た前日です。

2020年2月に行った時に比べると遥かによく凍ってましたが、大雪警報が出た翌日（8日）に訪ねたなら8割あたりまで凍結したそうです。（参考：氷瀑速報 袋田の滝の凍結情報 [大子町観光協会]）

という事で、この大雪警報はうち近辺にも影響を及ぼしまして、8日から11日の三連休、車に乗ってちょっと遠出しようかなって思っていたのに動けませんでした。8日は冷え込み寒さが緩んだ9日になっても溶けきらず、10日になってようやく全部解けたって感じですね。納車されたのが先月12日なので乗り始めて一ヶ月となったわけですけど、冬ってことと三連休走れなかったことで、700km強まだ走っただけです。

とはいえ、乗ってみてこれはあったほうがいいだろうと思った装備を買ってみました。コンソールボックスが開けたら深い穴が空いているだけでちょっと不便なので、コンソールボックストレイを仕入れてみた次第。しかも980円w。チープなお値段で質感もそれなりだけど、十分です。カローラっていう数が出ている車だけあって、専用パーツが安く出回っているのはまあまあメリットですな。

高速道路を走って感じたのは、エンジンが活躍する機会が多いとやはり燃費が悪化するなってことです。高速に乗る前より空いた高速を走った後の方が大幅に数字が悪化しているという。1ヶ月乗った昨日初めて給油しましたが、給油から給油の間の区間燃費は23.6km/lでございました。普通に生活に使っていく場合はこんな数字なんだろうなと考えておきます。
なを、給油後、信号が少なめ交通量も少なめな方向に100km程走ったら

給油後の区間燃費はここまで伸びました。が、自宅近辺に戻ってきて少し走るとぐんぐん悪化していきました。

まあ燃費ばかり気にしてても楽しくないですし、そこはほどほどにして楽しく乗って行きましょう。

という事で、今年は何を買えますかな。とりあえず使い勝手のいい望遠のズームレンズが欲しい今日この頃です。買って3月で10年目に突入するsmc PENTAX-DA 18-270mmF3.5-6.3ED SDMがどうもピントが合うのが遅く（K-3 Mk.IIIで悪化したように感じる）、smc PENTAX-DA★60-250mmF4ED[IF] SDM かHD PENTAX-D FA★70-200mmF2.8ED DC AW かHD PENTAX-D FA 70-210mmF4ED SDM WR あたりを手に入れたい…。ヨドバシ価格で10万、17万、11万とみんな10万超え。現実的にはFA 70-210mmかなーと思いつつ、買えるように仕事もそこそこ頑張りませんとねー。

古くからのMacユーザは Command + Space での入力ソースの切り替えをおこなっているわけですが、近頃のmacOSではデフォルトではそれがControl + Space に変わってます。けど、それは不便とCommand + Spaceに切り替えて使っていたわけですけど、在宅勤務中に利用するツールSplashtop Businessがリモート先の入力ソースの日本語⇄英語切り替えでのCommand + Spaceが機能しないため、微妙にストレスが溜まるわけです。

リモート以外では慣れ親しんだCommand + Spaceがいいのはいうまでも無いのだけど、OS標準ということもあり、ここいらでControl + Spaceへの移行をした方がいいのでは無いかと思った次第。

そんなふうに考えてリモート元と先の設定を変更してみたのですけど、あれれ？、やっぱりうまく動かない（リモート先はBigSur、リモート元はMonterey）。Control + Spaceするとリモート元の入力ソースが変わるだけで、リモート先に影響を及ぼすことができません。

Splashtop Businessを最前面のアプリにしているときにリモート元の入力ソースの切り替えのショートカットをオフにすればいいのか？と思ってやってみたら、Control + Spaceがリモート先で動作し、試しにCommand + Spaceに設定を戻してみたら、同様に動作するではありませんか。

つまりうまく動かないのはこのショートカット実行ではリモート元への影響が優先されてしまうためで、Command だとかControlだとかは関係なかったということです。ってことで、Control + Spaceの設定にすることは撤回し、Command + Spaceに戻します。

問題を改善するための手段としては、ある特定のアプリを最前面にしているとき、入力ソースの切り替えのショートカットをオフにし、最前面から外れたらそのショートカットをオンにすることを実現する方法となりますが、何かないですかね？

この設定自体はcom.apple.symbolichotkeysに書かれているらしいです。それでここを直接書き換えることも defaults write コマンドを使うことで可能らしい。

参考：システム環境設定をターミナル（defaultsコマンド）から設定する方法（Mission Control） [OTTANXYZ]

このページによると、システム環境設定のキーボードショートカット「前の入力ソースを選択」をオンにするコマンドは

defaults write com.apple.symbolichotkeys AppleSymbolicHotKeys -dict-add 60 "<dict><key>enabled</key><true/><key>value</key><dict><key>parameters</key><array><integer>32</integer><integer>49</integer><integer>1048576</integer></array><key>type</key><string>standard</string></dict></dict>"

ということです。ちなみに、parametersに書かれた三つの値の最後の1048576の部分は修飾キーにあたり、1048576がCommandキーに相当し、Optionキーが524288になるそうです。だから、Command + Option はその二つの数字を足して1572864となるそうです。
でenabledのtrue部分をfalseにするとオフになるはずです。

defaults read com.apple.symbolichotkeys AppleSymbolicHotKeys

これでcom.apple.symbolichotkeysに書かれたパラーメタを見ることができるけど、確かにオフにするコマンドを発行すると、該当ファイルにはオフだよって情報が書き込まれたらしいことが確認できます。けど、それが反映されない。

defaults writeコマンドで書き換えたら、その設定を再読み込みさせる必要があるのですね。で、何に対してそれをしてあげればいいんでしょ？　と思ってググるとこちらの掲示板に

/System/Library/PrivateFrameworks/SystemAdministration.framework/Resources/activateSettings -u

を実行するとよさそうだよ、って書いてありました。
確かに、falseになるdefaultsコマンドを投げてて上記コマンドを実行すると Command + Space は動かなくなり、trueになるdefaultコマンド後に上記コマンドを実行すると Command + Space は動作します。

ということで、これを組み合わせてAppleScriptで最前面のアプリが何かを監視してあげれば目的の事ができるようになりましょうか？