Atsushi Eno @atsushieno@fedibird.com

む、JammyにKernel 6.5が標準で入ってくるようになるとMIDI 2.0を使える環境が広がってくるな。 https://9to5linux.com/ubuntu-22-04-lts-is-now-powered-by-linux-kernel-6-5-from-ubuntu-23-10

今日はフレンチの店で新年会やってて、あたためられた柔らかいパンをちぎって地鶏蒸しのレモンソテーのソースに浸していて「これ昨日見た拷問のやつだ…」ってなった

そろそろ深夜まで開いている茶店が戻ってきてほしいなあ

今日もだいぶがんばってMIDI-CI実装を進めていて、だいぶfeature completeに近づいてきた感覚がある。売り物にできなくもないな…（ソースは全部公開している）

antlr-kotlin、ついに正式にANTLRの一部ってことになりそう（というお知らせというかライセンス変更依頼が来た） https://github.com/Strumenta/antlr-kotlin/issues/144
wasmサポートがあるから公式にしたい、とはまた公式もゲンキンだなw（嫌いじゃない）

RoomもMultiplatformで使えるようになるとコードの再利用性が高まるな（Lifecycle/ViewModelと同じで、Android専用すぎて全く使う気になれなかったやつ） https://medium.com/@callmeryan/kotlin-multiplatform-when-will-the-android-room-database-join-the-club-949005ba0d58

Apache commons-compressを全部J2Kしようとしたこともあったけど追加の変換作業が大量に発生することになってサクッと断念した。たぶんCで書かれたzlibを移植したほうがまだ楽…

Kotlin Multiplatformで使えるライブラリの選択、wasmJsターゲットをサポートしようと思うとなかなか厳しくなってくる。ktorが使えないなら他に…ってなっても、そっちもwasmJsまではカバーしていないことが多い。
今はDeflate (Zip) の実装が無い〜ってなってる。

もしかして三角コーンの人の名前って八代亜紀をもじってつけたのだろうか

MMAもMIDI 2.0 Workbenchっていうツールをgithubで公開していて、実装のチェック項目を確認するには有用そうなんだけど、CapabilityInquiryDemoと比べると全然機能に乏しくて相互運用性確認には使えなさそうなんだよな…

きょう1日でinitiator property subscription, profile details, process inquiry, property body chunkingをあらかた片付けたのでMIDI-CI実装がだいぶ進んだ気がする。あとzlib+Mcoded7とRFC6901のpartial updatesとMIDI Messaging Reportを実装すれば一応feature completeってことになるかな。
さすがにこっちばかりやっていられないので早めに片付けてAndroidプラグインに戻りたい…実装した以上は何かしらのメタデータのやり取りに応用しようとは思うけど（未定）

MIDI-CI実装、昨日はResponderサイドをやっつけて、今日はInitiatorサイドをやっつけてた。
JUCE CapabilityInquiryDemoがSubscriptionでプロパティの更新通知を送り付けてくるので、それにReply to Subscriptionで返事しつつ、更新されたデータを取得するリクエストを送るのだけど、このReply to SubscriptionをどうやらJUCEが想定していないというバグも発見してしまった https://github.com/juce-framework/JUCE/issues/1329
なんかこういう「仕様に忠実に実装されていない」みたいなやつ、昔XML Schemaの実装をやってたときに.NETで大量に記録していたな…
JUCEのMIDI-CI実装は実のところかなりよくできてると思う。自分のMIDI-CI実装もあらかたできていて、ここまでやってまだ2件しか相互運用性問題が出てきていない。（まあプロパティ更新通知が"notify"しかない、みたいな手抜き部分ももちろんまだあるけど。）

今日はMIDI-CIのProperty Subscriptionを実装していたのだけど、これCommon Rules for PEに忠実に実装すると、subscribeを受け取ったresponderはそのリクエストごとにsubscribeIdを発行して、以降property updatesが生じるたびにSubscribe to Propertyメッセージを発行することになるのだけど、そのヘッダーにはsubscribeIdが含まれる…ということは、subscriberごとにupdatesを送ることになるのだけど、正気か…?ってなってる。destination MUIDは仕様上7F7F7F7Fなんだから、全員向けに一度通知を送ってしまえば済む話だと思うのだが…?

んんん、明日って祝日なんだっけ（未だに成人の日が1/15だと思ってるマン）

プロプライエタリソフトに支払った金額のn%をフリーソフトウェアコミュニティだかクリエイティブ・コモンズだかに寄付してほしい、みたいなのは昔あったな

学生の頃に授業でPascalを勉強しただろうか…（うろ覚え）
1年生の後期に理系向けの教養科目としてやっていて、確かそっちに紛れて入っていたので、習ったような気がする。文系はHTMLやってた。
後期は夜学向けの情報系の科目でC言語やってたのは覚えてる。マンツーマンだったので「ポインタはわかりますか?」「わかります」「では省略します」みたいな雑な授業だった。

いくら建基法の新基準の要件を満たしていても、近所の超高層マンションとかが倒壊して真上に倒れてきたらひとたまりもないだろうなあ

うーん…こいつの非英語話者差別発言放置するのもよくないし、とりあえず政治的正しさで串刺しにしとくか…みたいな案件が発生した

去年になって妙に活発になったように見えていたけど死期を悟って書き物を残していったということだったのか https://media.rakuten-sec.net/articles/-/43818