VoicemeeterでBluetoothデバイス接続時の挙動を改善する
Voicemeeter環境で特定のBluetoothイヤホンを接続したときにAudio Engineを自動でRestartさせるまでの備忘録です.
まず前提として,VoicemeeterのHardware Outにデバイスを登録しても再接続時に自動的に利用できるようにはならず(画面的には以下のAirPods Proのように赤文字のまま再接続されない),特に付け外しが多いBluetoothイヤホンの接続時に毎回手動でのRestartが必要で不便でした.一応,VoicemeeterにはA1もしくは任意のデバイス接続時にAudio EngineをRestartさせるオプション (Auto Restart Audio Engine (A1 Device)
, Auto Restart Audio Engine (All Devices)
) がありますが,これらは対象のデバイスが接続されていないと定期的にRestartをかけてしまうため,未接続時には音声が飛びまくって使い物になりません.
方針
Bluetoothイヤホン接続イベント発生時にVoicemeeterのRestartをkickする.
環境
- Windows11 10.0.22000 Build 22000
- Voicemeeter Potato 3.0.2.2
詳細
- VoicemeeterをCLIから操作するためのツールをインストール
- 公式にVoicemeeter操作API が提供されているがCLIはないため適当なものとしてvmcliを選択
- インストール先は任意
- vmcliのバックグラウンド実行用VBスクリプトを作成
- vmcliを直接叩くとその度にコマンドプロンプト画面が出てしまうのを防ぐため
Set ws = CreateObject("Wscript.Shell") ws.run "cmd /c 【vmcliのパス】 Command.Restart=1", vbhide
- インストール先は任意
- Bluetooth接続イベントログを有効化
- Event Viewerを開き,
Applications and Services Logs > Microsoft > Windows > Bluetooth-Policy > Operational
のコンテキストメニューからEnable Log
を選択- デフォルトでは無効になっているはず
- Event Viewerを開き,
- 対象のBluetoothデバイスのアドレスを確認
- Bluetooth接続イベントログを有効化した状態で実際に接続すると
Event ID=9
としてログが吐かれるので,Event Properties > Details
のEventData > bthAddr
をメモ- 多分15桁の数値
- Bluetooth接続イベントログを有効化した状態で実際に接続すると
- Task Schedulerの設定
- Task Schedulerを開き,てきとうなディレクトリで
Create Task
- お作法をよくわかっていないが,
Task Scheduler Library/Users
を作っておいた
- お作法をよくわかっていないが,
- 以下を設定
General > Name
: てきとうTrigger > New
:Begin the task=On an event
Settings > Custom > New Event Filter
でXMLタブからEdit query manually
を有効化して以下を入力- 対象のBluetoothデバイスのbthAddrはイベントログからメモったもの
<QueryList> <Query Id="0" Path="Microsoft-Windows-Bluetooth-Policy/Operational"> <Select Path="Microsoft-Windows-Bluetooth-Policy/Operational"> *[System[Provider[@Name='Microsoft-Windows-Bluetooth-Policy'] and EventID=9]] and *[EventData[Data=【対象のBluetoothデバイスのbthAddr】]] </Select> </Query> </QueryList>
Actions > New
:Action=Start a program
Program/script=【作成したVBスクリプトのパス】
- その他の設定はデフォルトでok
- Task Schedulerを開き,てきとうなディレクトリで
これで指定のBluetoothデバイスが接続されたタイミングで自動的にVoicemeeterがRestartされすぐに使えるようになりました.ちなみに,VBスクリプトの部分をいじれば「Bluetoothイヤホン接続時にはスピーカーをMuteする (ws.run "cmd /c 【vmcliのパス】 Bus[1].Mute=1", vbhide
を追加)」みたいなこともできますね.便利.
本当はUSBデバイスでも同様のことがしたかったのですが,うまいことイベントを拾えないケースがありとりあえずBluetoothのみになりました.
【VGC2020】INC Apr. 最高/最終レート1841構築【エルジュラ雨 (Whimsicott&Duraludon Rain Team)】
はじめに
普段技術的な内容を扱っているブログですが突然のポケモンです。HGSSぶりにまともな対戦を再開したので、これからもたまにポケモン記事が増えるかもしれません。一応 (?) ポケモンだいすきクラブ・オーキ堂 のOBだったりします (所属していた期間はほとんど対戦してなかったんですが…)。
ポケモンは↓のTwitterアカウントで活動してます。ルビサファ時代からずっとカイオーガ推しです。 https://twitter.com/amaya383
An English version appears after the Japanese section.
INC Apr. お疲れさまでした。「思い切り上振れして最終2桁入ってみたい!」という目標だったのですが、33-9で最高/最終レート1841 最終21位を記録できたので構築 メモ を残そうと思います。WCS中止・JCSも開催困難そうというご時世ですが、(恐らく) ボーダーを超える結果を残せて嬉しいです!!!あくまで構築時の自分用メモに加筆調整しただけなので読みづらさはご了承を。
エルジュラ軸としてはかなりいい感じの構築に仕上がったと思うので環境が変わってしまう前に供養しようと思います。レンタルパも公開してますので興味がある方は使ってみてください。
WSL2のshellがどうにも重かったのが解決できた話
何が重かったか
tmux+zshな環境を利用しているのですが、zshでコマンドなしでEnterを連続で押したときやtmux環境を保存・復元するtmux-resurrectが激重でした。特に後者は保存・復元にそれぞれ1分程度かかっていました (同程度のマシンで普通のlinuxであれば5秒とかからない処理です)。
ちなみに、shellから呼び出したプログラムの速度は特段遅く感じることはありませんでした。
原因と解決策
デフォルトでWSL2のshellにWindowsのPATHが含まれているのですが、これが原因だったようです。 ので、これをしない設定にしました。
以下の内容を /etc/wsl.conf
に追記して再起動するだけです。
[interop] appendWindowsPath = false
ちなみにこの設定は Build 17713 以降でのみ使えるようです。
(追記) 副作用
WSL2のPATHからWindows由来のものを消すと、当然ながらWSL2からWindows側のコマンドを直接叩くことができなくなります。たまに手動で利用する場合であればフルパス指定すればよいですが、頻繁に利用するプログラムが存在する場合や外部のプログラムからPATHを前提としたコマンド呼び出しがある場合は困ったことになります。 応急処置として、PATHが通った場所にシンボリックリンクを張ることで解決できます。
例1: VSCode
WSL2からWindowsにインストールされたVSCodeを直接開くには専用のシェルスクリプトを経由する必要がある
sudo ln -s '/mnt/c/Users/<user name>/AppData/Local/Programs/Microsoft VS Code/bin/code' /usr/local/bin/code
例2: Docker for Windows (w/ VSCode remote container)
VSCode remote containerはその起動時に docker-credential-desktop.exe
がPATHにあることを前提としたスクリプトが実行される (最近のバージョンでは不要になったかも?)
sudo ln -s '/mnt/c/Program Files/Docker/Docker/resources/bin/docker-credential-desktop.exe' /usr/local/bin/docker-credential-desktop.exe
参考
WSL、Windows の PATH も一緒に持ってきてしまうらしく、UNIX 側に必要ない PATH を削るとそこそこ速くなるという知見を得た。
— mattn (@mattn_jp) December 26, 2019
GitOpsで絶対に避けて通れないブランチ戦略
Kubernetes Advent Calendar 2019 その3 の 2日目です。
WeaveworksによってGitOpsが提案されてから2年ほどが経ち、僅かですが本番導入事例も耳にするようになりました。とはいえ案外まとまったドキュメントは作られていません。特にGitOpsで複数の環境 (e.g., 開発環境、本番環境、etc.) をハンドリングするためには欠かせないブランチ戦略については殆ど語られていないようです。これではたとえGitOpsの概要 (Single Source of Truthの概念等) を知っていても本番導入には大きなハードルが残ったままで、本番導入事例がまだまだ少ないことにも納得できてしまいます。そこでこの記事ではブランチ戦略に焦点を当て、サンプルプロジェクトを交えながら紹介していこうと思います。k8s/GitOps中級者向けです、多分。
以前GitOpsについて発表した際に端折ってしまった分 の補完にもなっています。
- 前提
- 概要
- 用語
- サンプルプロジェクト
- Gitリポジトリ
- manifests
- system-manifests
- cd-manifests
- app-a
- app-b
- ブランチ
- manifests
- system-manifests
- cd-manifests
- app-a
- app-b
- Gitリポジトリ
- 詳細
- まとめ