2024年になってしまった

この blog もろくに更新しないまま気がついたら2024年になってしまった。
なんか年末に、プリンターやら、こどものおもちゃやら、色々壊れて何なんだって思ってたんだけど、年始もやたら世間的にも色々起きてなんかすごいなぁと思っている。

なんも書かないのも良くない気がするので、2023年がどんな感じだったかってのと、今年2024年をどんな感じにしたいのかを書く。

2023年について

Raspberry PI Pico 上でのプログラミングと、ゲームを主にしていた。
5がつ頃から、世間的にはコロナもそろそろ落ち着いてきたし、お出かけしてもいいんじゃないかという雰囲気になったけど、相変わらず家から離れることがあんまりできなかった。

Raspberry PI Pico 上でのプログラミング

具体的には、The NAYA での LED テープの点灯制御に使うことを主な目的としている宇宙12 Endurance のコードを書いた。
あと、Raspberry PI Picoをゲーム用のコントローラーにする GP2040-CE を使っていて気づいたバグの修正をしていた。
どちらも Raspberry PI Pico をベースにしているものなので、あっちの知識がこっちで使えたりしてよかった。

ゲーム

2022 年に発売された Splatoon 3 を引き続き遊ぶのに加え、2023年に発売された Street Fighter 6 を遊んでいた。

Splatoon 3

2022年に一緒に遊び始めた人が Discord サーバを立ててええ感じに運用してくれたので、そこにいる人と一緒に遊ぶことが多かった。
結構な頻度で一緒に遊んでいるので、人となりが少しずつ分かってくる感じで面白かった。
令和の時代ではこういったものをどう呼ぶのかがよくわからないが、いつも一緒に遊ぶ人とのオフ会もあった。
外出の機会が少ない一年だったけど、Discordで喋りながら一緒に遊んでいることが多く、寂しいと感じることが少なく、本当にsplatoonと、一緒に遊んでくれる友人に支えられた一年であったように思う。

Street Fighter 6

Street Fighter の新作が発売された。
それに合わせて、自作のレバーレスコントローラーを2台作った。
近所というほど近所ではないけど、電車一本で行ける場所でオフライン対戦会をやっていたのでそこにも何度か行ってみた。
ランクもとりあえずmasterまで上がって、それなりにいろんなことを考えて工夫したり、色々考えることができるようになった。
そんな感じで、まだ、面白い感じになってきたところ、という感じがする。

2024年について

目標

2024年は、外出をするようにしたいと思う。
具体的には月に1回、自宅から半径15km以上離れた、自分が納得できる場所に行くことを目標にしたい。

具体的な行き先として、クラブ、Street Fighter 6 のオフライン対戦会を考えている。
なんかおすすめの行き先とかあれば教えてもらえたり誘ってもらえたりするとすごく助かるし、2023年であれば躊躇していたところも、積極的に動いていきたい。

自作レバーレスコントローラーの基板を GP2040 ベースに変えた

2年半前くらいに、自作のレバーレスコントローラーを作った。
そのときには、 pro micro を使って、この上で動くコードはライブラリを利用しつつも主要な部分は自分で書いていた。

2年半時間が経過して、レバーレスコントローラーの自作はかなり一般的になった。
また、Raspberry PI Pico が発売されて、これの上で動くコントローラー用のソフトウェア GP2040 が開発された。
GP2040 は開発体制が変わったのか、オープンソースで開発が続けるコミュニティ版がフォークして、今は、GP2040-CE という名前で開発が続いているように見えた。

自分としてもいつまでも pro micro で動くコードの面倒を見るのはたいへんなので、GP2040-CE に乗り換えることにした。

配線をどうするか

pro micro でレバーレスコントローラーを作っていた頃は、ユニバーサル基板を使って気合いでボタンを配線していた。
でもまぁ、なんかそれも面倒なので、今回は pro micro 用のターミナルブロックを使うことにした。

例えばこういうの。aliexpress で送料も含めて 1000 円以下で買える。

今回は面倒なので、amazon で似たようなものを買った。

GP2040で使うことを想定した PICO Fighting Boardってのもあるみたいで、これも高くはないのだけど、トータルの値段で言えば汎用のターミナルブロックを使うんでいいような気がする。

GP2040-CE への独自機能の移植

pro micro の頃に、ミスタードリラーやテトリスなどのパズルゲームを遊ぶときに、斜め入力が入るのを避けるため、方向キーについて、最後に押したものを優先して入力として扱うような機能を実装して、設定で切り替えられるようにしていた。

GP2040-CE に乗り換えるにあたり、この機能を移植したいと考えた。

GP2040-CE は、オープンソースである。
なので、ビルド環境さえ整えてしまえば独自の機能を追加できる。
しかも、ソースコードを眺めていたところ追加機能を作りやすいように、プラグイン用のインタフェースがコード内に用意されていることが確認できた。

なのでさっと作った。

この機能が欲しい人居るんだろうか。いればプルリクエスト送ってもてもいいのかもしれないけど、、

GP2040-CE は、2023年の頭くらいにいくつかの git submodule に分割された。
その影響で、変更が複数のレポジトリにまたがる形となって若干面倒ではあった。

あと、Build 手順のドキュメントが古く、2023年4月1日時点では、書いてある通りにビルドすることはできなかった。
けど、 issue に手順をアップデートする予定があることが記載されているので、そのうち改善されると思う。

10000円以下で買った 24 インチ Full HD 液晶ディスプレイ KOORUI 24N1 の話

Covid-19 の影響で在宅勤務が本格化したタイミングで、家族からの影響を受けづらい場所に仕事環境を構築する必要が生じた。
このときに、27インチの液晶ディスプレイを買ったときに使うのをやめたけどなんだか捨てきれず、部屋の中に居座っていた BENQ G2400W と BENQ G2400WD というおよそ今から 15 年前に発売された UWXGA の TN ディスプレイを仕事環境で再利用することにした。
ただ、15 年前の時点ですら安価であった TN 液晶となると画面もなんだかぼやぼやして見づらく、ボタン類が壊れたり HDMI 端子が壊れたりで、使い続けるのがいい加減困難になってきた。なので、一念発起して仕事環境で使っている液晶ディスプレイを新調することにした。

時代が時代なので 4K ディスプレイを 2 枚、仕事環境にも導入することについても検討したけど、以下の理由で断念した。

  • 仕事で使っているノート PC は 2 枚のディスプレイに 4K 出力できるが、一方は 30Hz までしか出せないという制限がある
  • google 日本語入力は、拡大率が異なるディスプレイが同時に繋がれている時、変換候補の表示を正しい位置に表示できない。ノートPC についている画面は拡大率 100% で使っているが、4K ディスプレイは 175% あたりで使う可能性が高い。

なので、最低限仕事で使えればいいやと思ってとりあえず安価な Full HD ディスプレイを探した。
Amazon を眺めながら、だいたい 1 台あたり 15000円くらいが相場なのかなーと思っていたところ、KOORUI 24N1 という異様に安いディスプレイを見かけた。
なんと 9,299円(税込み) だった。
この値段だったら失敗しても許せるなーと思って、2台買った。値段は結構日によって違う気がするから、気になったひとは安いタイミングで買うのがいいと思う。

で、使い始めて 2 週間位経った。結果から言えば、自分の利用範囲では不満らしい不満がない。
15年前の TN 液晶よりも遥かに画面が見やすくて良い。
利用方法としては下記範囲では問題がなかった。以下は全て端末本体にイヤホン端子がついており、音はここから聞くことができる。

  • 仕事用のノートPCをつないで仕事につかう
  • Nintendo Switch をつないで使う
  • 個人用の Macbook Pro をつないでなんか色々するのに使う

ただ、このディスプレイには、最近の液晶ディスプレイにはほぼ標準でついている、スピーカーやイヤホン端子がない。
なので、例えば Playstation 5 のような、本体にイヤホン端子がなく、音は HDMI 端子経由で出力されたものを聞くといった利用方法が想定されているものではそもそも音を聞く方法がなくなってしまうので気をつけるといいと思う。

40歳になってた

2022年10月3日 に 40 歳になった。
で、その前日の10月2日に、久々に DJ しないかとお声がけいただき、青山蜂で行われた atrip ってパーティーで DJ をさせてもらった。コロナの色々があったり、コロナなんてなくても子育てがあるので、なかなか外出もままならない状況がずーっと続いているなかで、 DJ をして欲しいと頼まれた、なんていうのは自分にとっては絶好の外出の口実だった。
で、 10月2日 23時に、 DJ とパーティーが終わった後、遊びに来ていた友人とそこからさらに一緒に飲み屋に行って日付が変わる40歳になる瞬間を一緒に過ごしてもらった。
全員でスマホに表示した時計を覗き込んで日付が変わったタイミングで祝ってもらった。少し経ってから手に持って、写真をとってもらった。

もうここ数年、自分の誕生日であっても、子供から見て親の誕生日がどうあるべきかみたいなことをずーっと考えてしまってそればっかりになってしまっていた。なので、そういうのなしに単純に祝ってもらえる事と、祝ってくれる人がいるということがとてもありがたかった。
23時に渋谷駅近くでのパーティーが終わった後、更に飲みに行って戸塚の家に帰れるわけもなく、その日はまだ新婚ほやほやの友人宅に転がり込ませてもらった。友人宅の生活は、自分という普段は居ない人間がいるわけだから、もちろんいつも通りというわけではないだろうけど、その生活の一端を見られたのが面白かった。

自宅のTV録画サーバ兼NASを新調した

自宅のTV録画サーバ兼NASを新調した。
録画サーバとNASを前に作ったのは 8 年前で、ほぼ8年間稼働しっぱなしだったので、さすがに古くなってきたと思って新調した。
今年始めにメインのデスクトップPCを組んだので、今年に入ってから2台目の自作PCとなった。まぁ、そういうこともある。

ハードウェア構成

ハードウェア構成はこんな感じ。ケースとケースファンは流用。

項目型番とか大体の値段
マザーボードASRock H610M-HDV/M.2\11000 くらい
CPUintel Celeron G6900(Alder Lake)\7000 くらい
メモリADATA AX4U320088G16A-DCBK20 8GBの2枚セット\7300 くらい
システム用 m.2 SSDWestern Digital WDS480G2G0C 480GB\6300 くらい
電源Scythe CORE-TFX275\3300 くらい
データ保存用 HDDSeagate ST8000DM004 8TB\15000 くらいを2台
合計\65000 くらい

データ保存用のHDD を除くと \35000 くらいで、既製品の NAS の箱と同じくらいの値段になったりするのだけど、メモリを16GB積めていてこれがキャッシュとしてきいてくれていい感じであってくれ、という気持ち。
でも家のネットワークが未だに 1GBit Ethernet なので結局こっちがネックになる感じはある。

CPU はAlder Lake世代で一番性能が低いものだけど、用途を考えれば十分だと思う。というか、シングル性能は i9-10900 と変わらないということらしくなんか未だに CPU は進化を続けているのだなぁと思う。
いろいろなことをしたくなって性能に不足を感じるようになってきても、多分 i3 くらいまでは載せ替えても電源の面でも熱の面でも問題は起きないと思う。

録画機能の選定

8年前は、chinachu というTV録画用のwebサービスを使って、環境を構築した。
今回も chinachu を使おうと考えていたのだけど、この8年の間に chinachu のテレビ録画ボードを操作するAPIを提供することを目的とした部分が Mirakurun として切り出され、 chinachu 自体にはこの API を操作するための Web UI が残されるという機能分割が行われたようだった。
で、その Web UI の方についても obsolete になるらしく、じゃあどうやって使えばいいのかと思ったんだけど、 Web UI の部分を置き換えるいくつかの代替品があるらしく、それと組み合わせて使うといった形になったらしい。

今回は、Web UI としては EPGStation というものを使うことにした。
EPGStation と chinachu はともに Docker 内で動くようになっており、両方をまとめて起動できる docker-compose 用のファイルも配布されていたので、これを使うことにした。

心残り

標準の状態では Quick Sync Video を使わずに、完全にソフトウェアでトランスコードするので、トランスコード時の CPU の負荷が高い。
Dockerfile 内で FFMpeg をコンパイルしているので、ここで必要なライブラリやコンパイルオプションの追加をすれば、 QSV を利用可能になる。でも、とりあえずソフトウェアエンコーディングでも性能が足りているようなので、後回しにすると決めた。

OS の選定

録画機能がDocker コンテナの中で動くということで、物理マシンに直接インストールする OS についての制限はなさそうだったので、長期的にちゃんとアップデートを行っていくことを念頭に置き、 arch linux をホストの OS として用いることにした。

NAS 機能

録画機能が docker-compose で管理されているので、NAS機能の方も docker-compose で管理することにした。
debian のベースに samba をインストールした Dockerfile を書いて、それを使った。
NAS 用のディスクは btrfs の RAID 1 でフォーマットした。1台壊れても大丈夫だし、容量足りなくなったら大きめのディスクを足せば良いだけのはず。

心残り

samba に対する書き込みを行っている際に、 docker-proxy というプロセスがそこそこ CPU を使っていることに気づいた。
このプロセスはコンテナの中と外の通信を仲介する役割であり、–userland-proxy=false オプションを docker daemon に与えるとこれを使わずに、iptables で代替の処理を処理を行うようになるようだ。多分、iptables でやったほうが軽くなるだろうとは思うのだけど、とりあえず性能面で今すぐ困る感じにはならなかったので、標準の状態でいいやと言うことにした。
今後、コンテナで大量の通信を行うような利用法を考えるときにはこのオプションについて真面目に検討しようと思う。