/RSS2025-03-03 (Mon) [長年日記]
_ [mac] Karabiner-Elements でトラックボールも便利に
Karabiner-Elements で button5 を
- クリックは button1 クリック
- 長押しはシフト長押し
にする設定はこんな感じになりそう
{
"description": "button5 to button1 or shift",
"manipulators": [
{
"from": {
"modifiers": { "optional": ["any"] },
"pointing_button": "button5"
},
"parameters": {
"basic.to_delayed_action_delay_milliseconds": 100,
"basic.to_if_held_down_threshold_milliseconds": 100
},
"to": { "key_code": "right_shift" },
"to_after_key_up": [
{ "sticky_modifier": { "right_shift": "off" } },
{
"set_variable": {
"name": "shift",
"value": false
}
}
],
"to_delayed_action": {
"to_if_canceled": {
"conditions": [
{
"name": "shift",
"type": "variable_unless",
"value": true
}
],
"pointing_button": "button1"
},
"to_if_invoked": {
"conditions": [
{
"name": "shift",
"type": "variable_unless",
"value": true
}
],
"pointing_button": "button1"
}
},
"to_if_held_down": [
{ "sticky_modifier": { "right_shift": "on" } },
{
"set_variable": {
"name": "shift",
"value": true
}
}
],
"type": "basic"
}
]
}
ダブルクリックをしない人は to_if_canceled が不要
Karabiner 自体にも mouse_motion_to_scroll というのがあるけど、動作がモッサリ? カクカク? しているので私は DragScroll という別のアプリを使っている
2025-01-13 (Mon) [長年日記]
_ [srv] ささやいてました
- Apple Silicon を入手して whisper.cpp の examples/stream で色々やっていた
- どの程度の性能が必要なのか心配していたが……
- Mac mini M4 16GB なら余裕すぎ
- whisper を動かしていてもいなくても非常に省電力なので、他の用途でも、つけっぱなしで動かすときには結局 N100 とかを買うより電力や静音の面で良いという場合も多そう
- Macbook Air M2 8GB でも、一番重いはずの v3 (非 turbo) で 10秒の音声を 1秒ぐらいで扱えるから stream でガンガンまわすことができる
- Mac mini M4 16GB なら余裕すぎ
- Mac mini を家に置いたまま WebSocket でブラウザの getUserMedia から音声を受け取 (って ffmpeg で Float32 の PCM に変換す) るサーバを Deno で書いてたら、Deno のバグ に引っかかったぽくて、静かに止まってしまうので、Python で書いた
- シェルでは nc | ffmpeg | stream ってパイプでつなぐだけって感じだけど、Python 等でやると少しコツが必要だと感じた
- きっともっとシンプルにできるんだろうなぁ
- whisper は sample rate が 16000 だけど、ブラウザの音質はそれに合わせるより、まず 48000 とかで取得して流すほうが良いみたい
- 16000 だと認識精度が落ちるほどになった
- シェルでは nc | ffmpeg | stream ってパイプでつなぐだけって感じだけど、Python 等でやると少しコツが必要だと感じた
- whisper はリトルエンディアンの Float32 (4 バイト) PCM が必要なんだけど、ネットワーク越しとかパイプ越しでやっているうちに 1〜3 バイトずれることがあっても whisper は認識してくれているような気がする
- tee したデータファイルを見てみると接続のたびにズレてるけど、whisper は普通に日本語の結果を出してくれてる (もしかすると一瞬戸惑ってからだったかもしれない)
- だから 4 の倍数にすることをそれほど気にしなくてもいいのかも
- どの程度の性能が必要なのか心配していたが……
今回は Windows PC が相次いで故障したので失敗したくなくて、 安く確実に whisper を使えるだろうということで M4 Mac mini にしたけど、 Ryzen とかでも VRAM を設定して普通に使えたりするんだろうか
- whisper は音量にはとても寛容
- 音割れしても小声でも認識精度はそれほど落ちない
- だから無音の区間でも幻聴で「おやすみ」とか「ご静聴ありがとう」とか言い出す
- そこをどうするかについて決定打はないみたい
- VAD を使って、いい感じの区間だけ取り出すのがひとまずの最善と考えられているんだろうとは思う
_ [srv] 認識結果を手作業で直しつつ難聴の人に見せたいと思った
- クラウドに出したくない会話内容とかネット環境の悪い場所とかのために HedgeDoc も検討したけど、パッチを当てるのが難しいのでやめて Rustpad にした
- Rustpad のクライアントは手抜きで書いたのでそれほど複雑にならなかったけど、(WebSocket で現在の文書の内容や長さを一発確認する API がないみたいだから) 毎回普通の http で GET するとかいうダサいことをしていて人に見せたくない
- History の operations で変更をぜんぶ追えばいいんだろうけど、それも面倒だし……
- Google Docs は JSON でドバーッと返してくれるのはいいけど、テキストを取るだけでもダルい
doc = google.service.documents().get(documentId=DOCUMENT_ID).execute()
bodyContent = doc["body"]["content"]
return reduce(
lambda a, b: a + (b["textRun"]["content"] if "textRun" in b else ""),
bodyContent[index]["paragraph"]["elements"],
"",
)
🙄段落ひとつ取り出すだけでも content の paragraph の element の textRun の content を連結しなきゃいけないの?
2024-05-28 (Tue) [長年日記]
_ バンポ電話対応
スマホ買いかえ等の関係で自宅のネットも固定電話も会社を変えてみた。
ネットのほうはフレッツからドコモ光にしたけど、いつ変わったか分からない感じ。ホームゲートウェイを接続しておけばいい。(朝9時までにHGWを用意しておくよう言われていたが、その前から新しいISPにはPPPOEで接続できていたようだ)
固定電話のほうは、ひかり電話の番号へ午前中に電話してくれと言われていたので、ネットのほうの工事がおそらく終わったのだろうと思える時間 (朝10時すぎ) になってから電話をかけた。
それまでのドコモ関係の電話はまさにプロの電話受付といった感じで丁寧で分かりやすかったので今回もそうだろうと思っていたところ、度肝を抜かれた。
「あー、どしたの？」
「番号は？」
「これね、バンポだから開通したあとまた電話してね」
いかにも現場のおじさんといった感じの人が、ぶっきらぼうに業界用語を使いまくるのだ。こちらは
「バンポって何ですか」
「番号が下りてくるってどういう意味ですか」
と、ぜんぶ聞き返さなくてはいけない。
けっきょく、一回目の電話でホームゲートウェイに「ひかり電話」を開通してもらって、(HGW の「ひかり電話」LED が光ってから) その後もう一度電話して電話番号を移してもらうということのようだった。
今はスマホもあるから何かを間違えて電話が不通になってしまっても別経路で対応できるわけだけど、要らない書類をたくさん送ってくる割に最後の大切な段階について説明が雑だったのはちょっとこわかった。
2024-03-12 (Tue) [長年日記]
_ [ahk]Windows の不思議セキュリティ、あるいは頑固な UWP のなだめ方
TL;DR 本当に always-on-top にしたければ その実行ファイルは UIAccess の諸条件をクリアしなければいけない
AutoHotkey で Always-on-top に設定した Gui を作って表示したところ、 一部のウィンドウの上には表示されず、隠れてしまうという現象が起こった。 (その「一部」が UWP アプリであることは後から分かった。)
再現条件が複雑で、
- AHK スクリプトとして実行するなら再現しない (問題の UWP アプリの上に表示できる)
- Ahk2Exe でコンパイルすると再現する (UWP の上に表示できない)
- いや、スクリプトでも再現するマシンと再現しないマシンがある
と、かなり迷走した。
AHK に関係のない他のウィンドウで試してみると、
- タスクマネージャーは再現しない (件の UWP アプリ上に表示できる)
- LibreOffice とか Firefox とかでは再現する (UWP の上に表示できない)
ということが分かった。
そんなことないと思う人は試してみてほしい。 複数モニタがあれば、一つに Windows 標準の「映画 & テレビ」で何かの動画をフルスクリーン再生して (一時停止しておいてもいい)、そこに別のモニタからのウィンドウを移動していくとどうなるか。
タスクマネージャーを移動していくと何事もなく重なるのに、 普通のウィンドウを重ねようとすると、途中までは下に潜りこむような感じで隠れていて、ある程度まで来ると「映画 & テレビ」の方が消えてしまうのだ。
タスクマネージャーはすごく変なアプリだから特別なのかもしれないと思ったが、AutoHotkey 付属の Window Spy もタスクマネージャーと同じ結果になった。というか AutoHotkey が C:\Program Files にインストールされているマシンでは AHK スクリプトから UWP の上に表示できるみたいだ。同じ AHK スクリプトを実行して UWP に隠れてしまう方のマシンには AutoHotkey をインストールしておらず、zip を展開した状態で使っていた。
ここに来てやっと分かった。Ahk2Exe してあるかどうかというより、UIAccess 権限があるかどうかが問題だったのだ。
それまで権限の問題と思えなかった理由は、「管理者として実行」をしても現象が変わらなかったからだ。AutoHotkey のドキュメントでも、UAC の問題は UIAccess と管理者権限のどちらでも解消できると書いてある。https://www.autohotkey.com/docs/v2/FAQ.htm#uac これは少し誤解を招く文かもしれない。
というわけで結論として、UWP の中でもさらに特殊な条件を含めた really-always-on-top を実現するためには、UIAccess が必要である。WinSetAlwaysOnTop の remarks にも書いておいてほしい気がする。
UIAccess のための条件
- AHK スクリプトのまま使う場合は、AutoHotkey を C:\Program Files にインストールすればいい
- Ahk2Exe する場合は、以下のすべてが必要
もっと良い方法もあるのか？
UIAccess should not be used: By applications that are not assistive technologies. By assistive technology applications that display information or UI that is not relevant to the accessibility scenario they target. By applications that just want to appear above other applications in the new Windows UI.
と書いてある。まさに今回のことを言っているようだ。こんな場合は UIAccess を使うべきではない！ とだけ書かれても、どうすればいいのか分からない。
最近のツッコミ: