Posts

長袖なのか半袖なのか、それが問題だ、という季節ですね。毎年毎年困ってます。 半年ぶりくらいにキーボードを設計しましたので、その紹介をしたいと思います。 外観 恒例の外観です。 特徴としては割といつもどおりです。 カラムスタッガード 乾電池駆動 今回は単4×2にしてます。昇圧効率を考えると、ほぼ同容量である単３一本よりも圧倒的に持ちます 大体1ヶ月弱利用してますが、電圧が下がってくる気配がなかなか見えません。power profilerでざっくり計算すると3ヶ月は持つという 完全無線 たまーに色々ラグいとかありますが、一回これに染まってしまうと、なかなか抜け出せないです ガスケットマウント 印刷したケースも真っ黒なのでわかりにくいですが、ほぼ全面にPORONを入れてガスケットマウントにしてあります 16.8mmピッチ with low profile 今回はLofreeのPhantomを利用してます。タクタイルはそんな得意じゃないんですが、タクタイルっぽくないタクタイルなので割と問題なさげです ちなみに前使ってたキーボードでは、初めてキースイッチ自体がだめになる、という経験をしました。5000万回も押してなかったんだけどな 今回のお題 今回のコンセプトは、ずばり Thockyな音にしたい です。前回作ったキーボードは、スイッチプレートをネジ止めするという都合上、かなり音としては高めになっていまして、使ってて割と気になる感じでした。 現場でもキーボード使ってる人は多いんですが、やはり聞こえてくる音でもThockyな音のほうが心地良い感じがします。ただ、これは相当に主観が絡むので、青軸とかでもなければ職場では聞き流すのも肝要ですね。青軸はさすがに苦言を呈していいと思います。 ちなみにThockyとかClackyとかについてはみんな大好き遊舎工房さんを参照するとわかりやすいかと。 https://shop.yushakobo.jp/pages/typing_sound?utm_source=ec&utm_medium=pages&utm_campaign=yomimono Thockyな音にするためには？ すでに先人が色々検討・実験してくださってるので、まずこの辺を読み込みました。 https://piroriblog.hatenablog.com/entry/2024/12/01/124054 https://kgnwsknt-chef.hatenablog.com/entry/2023/02/02/224137 私の理解では、 波長が短い＝音が高い、波長が短い＝音が低い 振幅はエネルギーなので、低音でも振幅が大きい、とかは普通にあります 短波長の波は、 減衰が激しい なので、多孔質のフォームとかを通すと外に出る前に減衰する 長波長の波は、 減衰しづらい よく低音が〜ってのがありますが、反射回数と減衰はニアリーイコールなので、そもそも減衰しづらいです 完全に減衰させると音にならない 考えたら当たり前ですが、音が聞こえるということは振幅が耳に届いている、ということです というところになりました。つまりうまいこと短波長を減衰させつつ、長波長をコントロールする・・・というのが基本になります。なのですが、音は単純に広がるのに加えて、 共振 振動数によってはケースとかも振動する そもそもケース自体も振動する 反響・残響 あまり残りすぎると、今度は余韻としてのこります。これはこれで嫌がられる 干渉 音波なので干渉します。ある音を強めたい場合は干渉で同位相を重ねる・・・といったことも必要になります 干渉するためにもスペースが必要ですね とかの要素も加わってきます。正直ただのソフトウェアエンジニアではこの辺を測るなりなんなりするのは、まー無理ですね。 とりあえず目指した部分 ケースはアルミで・・・みたいな話まで出てくるものでもありますが、それをやらなくてもできるポイントはあるのではないか？ということで、一旦以下を妥協ポイントとしました。 音の調整は ボトムケース内の詰め方 で調整する スイッチプレートと基盤の間にはIXPEフォームを挟む これはやってもやらなくてもあんまり・・・という感じではありましたが。複合しないとなかなか ケースへの振動はガスケットで塞ぐ として、音を調整する変数をできるだけ減らす、という形に落としてます。 ケースについて 今回も3D printerでケース・キーキャップを全部作ってますが、音を閉じ込めようとして全面を塞ごうとした結果、ひじょーに厄介な設計になってしまいました。もっとシンプルでいいのに。 ただ、今回PLA Matteを利用したところ、予想以上にいい手触りでした。Matteおすすめです。 結果と次回にむけて 今回はギミック・機能というよりは音という部分にフォーカスしたものにはなりますが、やってみて色々と発見がありました。 今回の基盤ですが、１枚で４つ含める形にしてます。（緑に緑なんであれですが。どうせ何も見えなくなるので、最速&最安でできる緑にしてます） 基盤を分割する、ということの有用性 今回初めてコネクタを利用して繋いでみましたが、思ったより問題がない上、基盤の自由度が上がるというメリットも享受できました ただ、ケーブルが長すぎたのが反省ポイント TPUの可能性 一個前のキーボードでは、TPUでボトムを埋めましたが、これをPORONと組み合わせることで、より制振と音響を制御できそうな予感がしました あと、TPUは振動の吸収もいい（スマホケースで利用されてます）のと、丁度いい硬さももっているので、これをガスケットとして利用するのはあり 音自体は多少Thocky似できたのですが、隙間の調整だったりなんだり、そういったクリアランスの制御などを見ると、やはり既製のキーボードは強いですし、普通に使うだけならそっちにしたほうが絶対いいです。 ...

気づいたら新入社員がはいって来てました。なんか去年も同じこと書いた気がしますが、気のせいでしょう。 まだまだEmacsを現役で利用していますが、カーソルの移動に対するアプローチを変えつつあります。 もともとの課題感 私はEmacs上では multistate という、modal editingの仕組みだけを提供しているpackageを利用して、modal editingそのものは すべて 自前で定義しています。evilとかmeowとかも使ってたので、そういったもののエッセンスも入ってます。 ちなみにevilを利用しなくなったのは単純で、Qwertyを利用しなくなったのでマッスルメモリーが使えなくなった、というのが最大です。ただ、なんだかんだEmacs上でのエミュレートではあるのと、個人的にはtext objectよりもpuni/treesitterベースでの選択ができればそれでよかったです。 そんな中で、ずっと悩ましかったのがカーソル移動です。上下左右についてはそりゃー定義していますが、 10行下にあるfoo に行きたい、となった場合に、大抵10回キーを押してます。word単位の移動とかならまだいいんですが。一応avyとかも入れていたんですが、よくある文字だと候補が多すぎて・・・っていうのにもなります。 avyを激推しする記事 2021年の記事にはなりますが、すっごい長文の記事があります。めちゃくちゃ長いのですが、Emacsを利用している場合は読んでおくといいと思います。 https://karthinks.com/software/avy-can-do-anything/ この記事の要旨としては、 カーソルの移動というものは換言すると3stepの話でしかない 同じ筆者が書いた、Emacsのウィンドウ管理に対する記事でも、同じような話があります avyがすでにそれを提供している isearchかavyで十分だ というところです。間違ってたらごめんなさい。この記事を何回か読んで、なんとなーく把握できました。 移動の優先度を見直す 私がやるカーソル移動（検索含む）は以下です。上から順に頻度が高いです。 hjkl likeな文字単位移動 word単位移動 consult-xxx consult-lineが最も頻度が高いです isearch 色々見直した感じ、以下のようになるようにしてます。 hjkl likeな文字移動 isearch + avy consult-xxx mode-specificな移動 orgだったらheading単位とか insert modeのままで・・・というのであれば他の選択肢もあると思いますが、いかんせんQwertyじゃないのでキー配置が色々ございまして、移動はnormal mode、と割り切っている次第です。 さて、isearchなんかいらなくて、全部consult-lineでいいじゃん？という方もいるでしょう。そこは自由なので「そうですね」となるのですが。それだと面白くないので、理由を書いてみようかと思います。 isearch vs consult-line Emacsの検索というとisearchがまずデフォルトであるのですが、大抵は consult-line などの利用を勧めているケースが見られます。これがなんでかなーというところを考えると、 スペース区切りだったりで検索できる（ように見える） 結果の一覧が見える のが大きいのだと思います。これについては全く違和感がないのですが、ことカーソル移動を主眼に置くと、以下の点でoverpowerです。 本質は filtining なので、検索はしていない 今見えてる場所を一覧しても何も嬉しくない 逆にminibuffer/bufferへの視線移動を伴う 同一行に複数の結果がある場合に対応できない 特に最後は、consultの本来的な目的を考えると、サポートは難しいというかしないと思います。が、移動となると頻繁にありえます。isearchならなんの問題もなくできますよね？という。 isearchのカスタマイズ 激推しされるavyには、 avy-isearch というもうそのまんまな機能があります。対象のfilterをisearchでやり、selectをavyでやる、という形で１本化することができます。お、これで解決では？ キー数が増えてる、非効率だ！ってのはあると思いますが、単一操作であらゆるケースに対応できるので、記憶容量はむしろ減ると思います。avy/isearchの使い分けを・・・って考える時間のほうがもったいないんじゃ？と参照元も書いてた気がします。 さて、そんなisearchですが、欠点もあります。それは 検索方向を最初に決めないといけない ということです。 isearch-forward と isearch-backward ですね。isearchをカーソル移動として利用しようとしたとき、これが困ることが多いです。 ...

気づけば卒業式シーズン。いかがお過ごしでしょうか。というかこっちの卒業式って3月の半ばなんですかね？（わかってない） 最近Emacs弄りの熱がまた上がってきたところですが、生成AIにコンセプトを伝えて作らせたものを紹介します。 できたもの https://github.com/derui/projab Project.el + Tab-bar というところで projab としました。一応ググってもそれっぽいのは出てこなかったので大丈夫だとは思います。 余談ですが、生成AIが提案した名前に workroom （後で出てきます）ってのがありましたが、もう全く同じ名前のpackageがありました。事前調査は重要ですね。 Project management系統なので、基本的に画面とかはありませんが、自分が欲しい以下の機能を兼ね備えたpackageがなかったので作成しました。 標準パッケージにだけ依存する Emacsの標準パッケージはすでにかなり充実していますので 特に、visualにかかわらない部分については、大半が汎用性のある形でできてます Bufferのリストだけ保存される 意外と Window layoutも 復元しようとするケースがあるのですが、これは究極に複雑な系統になるのと、だいたいその辺キー一発なので切りたかったんです 自動レストア機能 + Projectを開いたときだけ 復元 大抵、projectを含めて全体を復元・・・ってやるのですが、それをやられると、長時間使ってると、次回起動時にとっても時間がかかるようになります 実際、Nixをdirenvで有効にしているprojectがあったりすると、開くだけでLSPの起動やらなんやら含め、長時間待たされます 私のsetupは、起動速度に重点を置いているので、ちょっと許容できなくなってきたという背景もあります そんなことで、以下のことができるように、というコンセプトで作ってます。 project.el / tab-bar / desktop.el を利用する project外のファイルも復元のリストに入れられる 復元単位はproject = tab Window/frameの復元は不要 とりあえず使える・・・って状態になるまで1,2時間くらいでした。ほぼほぼ利用する関数は自分でも把握していたので、reviewも早いですね。 自分が把握している範囲が広いほど、生成させるときも速い です。 他のpackageを利用しなかった理由 このsession管理というのは、Emacsの歴史上何度となく大きなトピックになってきた（と勝手に思ってます）ものであり、多数のpackageが存在しています。 Tabspaces もともと利用していたもの。project.el + tab-barというのはほぼほぼ同一 ただし、 自動restoreは全体の復元が強制される ことと、Windowやtemporary bufferまで保存しようとすることで、復元するときに結構厄介な状態になったり、ということがあったのが、今回作った主な動機です emacs-workroom ほぼほぼ同じ動機。 project.el + desktop.el ただ、tab-barのintegrationを作者がする気がない様子 perspective-el この分野の有名どころ より複雑な管理（merge/split）を可能としてます。elscreenとか書いてあるくらいなので、非常に歴史があるpackageでもあります これも昔使ってました つまり、個人的には 帯に短し襷に流し を地で行っている状態だった・・・というのが、ド新規でわざわざ作ろうと思った動機です。以前であれば、こうなると妥協して・・・ってのがありましたが、今はこれくらい（400〜500行程度）のElispであれば数分で作成できてしまうため、アイディアなりコンセプトの具現化は非常にやりやすいと思います。 やらないこと、を決める このpackageでは、最初から以下はやらん、と決めていました。多分作らせようと思えばできるのですが、そもそもやる理由がないのと、コンセプトからブレるためです。 ...

まだEmacs使ってるの？って空気を感じる中、変わらず触っています。最近ちょっと一念発起して、header lineをカスタマイズしてみたので、ちょっと紹介します。 問題意識 Emacsのsession managementについては、色々試した結果、紆余曲折ありつつもtabspaceを利用しています。このpackageは、名前の通りEmacs標準のtab-barをprojectの単位として利用することで、spaceの切り替えを明示的にすることができるようになっています。 そんなtab-barですが、デフォルトだとこんな感じの表示です。 簡素ですがまー用は足ります。なんですが、最近の流行りに合わせてbreadcrumbを利用してheader lineも利用していると、以下のような課題が出てきます。 そもそもの領域が削れてしまう header-line + tab-bar + mode-line + echo area、という固定領域が発生してしまいます 切り替えたときに、別のprojectが見えてる意味が薄い そもそもなのですが、一回切り替えると、大体はそのprojectに関連したものに統一されるわけで・・・ 常に見えてる必要もないね？ tabspaceのecho areaに表示するoptionも試してみたが、これはこれでなかなか厳しい 多分相当にいじれば問題はなさそうなんですが、上記にあるとおり、 そもそも常時見えている必要とは 🤔 と。 実際はもうちょっとカスタマイズしていたので、さらに高さがありました。 ヘッダーラインとモードライン さて、ヘッダーラインとモードラインですが、それぞれ色々と用途はあります。ただ、現状はヘッダーラインがほぼほぼbreadcrumbの領域しかないことと、大体projectの内容も含まれていることから、ヘッダーラインを追加することにします。 (defun my/header-line-project-name () "Get the current project name (tab name) for header line" (alist-get 'name (tab-bar--current-tab))) (defvar my/header-line-separator nil "Cached separator string for header line, rebuilt on theme changes") (defun my/header-line-update-separator (&rest _) "Rebuild the cached separator string" (setq my/header-line-separator (concat (propertize "|" 'face 'shadow) " "))) (add-hook 'enable-theme-functions #'my/header-line-update-separator) (defvar-local my/header-line-element-project-name '(:eval (concat "[" (my/header-line-project-name) "] " (or my/header-line-separator (my/header-line-update-separator) my/header-line-separator))) "An elenemt of header line to display project name") ;; set local variable for header line (put 'my/header-line-element-project-name 'risky-local-variable t) (defun my/setup-header-line () "Setup `header-line-format' for my purpose" (setq-default header-line-format '("%e" my/header-line-element-project-name (:eval (breadcrumb--header-line))))) (with-low-priority-startup (my/setup-header-line)) こんな感じの設定になりました。ミソとしては breadcrumb--header-line です。これはbreadcrumbの内部処理なのですが、breadcrumbが提供するheader lineがちょうどいい感じなので、これを利用しています。また、注意としては breadcrumb-modeを有効化してはならない ってのがあります。これはbreadcrumb-modeは有効化した瞬間にheader lineを強制的に変更してしまうため、こっちが想定した形にならなくなります。 ...

あれ、１月ってありましたっけ？という勢いで１月が終わりました。あれを何月くらいにやろうかな、とか考えてるとすぐに終わっちゃいますね。 今回はちょっと最小限で欲しいEmacs lispのpackageを作って・・・というか作らせてみました。 できたもの とりあえず画像を見るのが一番早いので貼っときます。 こんな感じに、 置換対象のものだけを、置換後とside by sideで見える ってものです。とってもシンプルで単機能です。 モチベーション できたものは、概ね行数としても150行とかなのです。もともとは単純に 置換前後をみたい というものなのですが、これが地味に対応するものがない・・・というところなので、探してました。 より高機能なものとして visual-replace やanzu.elなどがあるのですが、こちらは 検索処理そのものを置換している という課題があります。なんだかんだ、interactiveな検索・置換というのは恐ろしく複雑な行為なので、自作はしたくない・・・。また、標準へのalignが最近のトレンドと考えると、既存の継続的にメンテナンスが行われているlibraryを利用しない、というのもなかなかもったいないことだなーと。 発見と作成 ふとした発見は、 replace-update-post-hook というhookを見つけたことです。これは置換を行う直前くらいで呼び出されるhookで、今回やりたいやつにぴったりでした。 ちょうどよかったので、完全にLLMでやっていい規模だったので、全面的に生成させてます。 全体のデフォルト構成はCopilot Agentに初期生成 実際の実装はClaude Codeでplanさせてから実装 テストの生成/documentもClaude Code 動作確認は自分 という感じで、大体はClaude Codeに生成させたものになります。やっぱり一発では無理で、存在しないlexical変数を使おうとしたり、エラーハンドリングが足りずに C-g でキャンセル・・・とか気の利いた感じにはやはりなりませんでした。 とはいえ、overlayの作成やdefvarの作成といった、Emacs Lispお決まりの管理などを含めると、実際のロジックはほんの2,30行程度、というのが実態でした。やはり色々言われている、 大体定型的な処理になるもの とかは、生成させるのに向いていますね。 Emacs Lispとの向き合い方 Emacs Lispは、Emacsを触るうえで絶対に避けられないものですし、色々な概念が絡み合って、大変に複雑です。しかし、シンプルなpackageを作るとかは、今だと1時間とかあったら、 ボイラープレート的にやるもの を含め、だいぶ楽に作れます。 作れるからといって何でも作る と、それはそれでメンテナンスが不可能になっていくのですが、Unix wayのように、単機能のものをいじったり作ったりする分には、問題はそこまで露出しないかな〜、とも思っています。 Emacsを触ってみるいいチャンスとして、一個気に食わない部分をpackageにしてみる、とかいかがでしょう？

気が付いたら2025年が終わってました。今年の抱負とか考える前に仕事が始まったので、今年もいきあたりばったりに行きていければと思います。 最近Rustで細々と格闘しているんですが、ちょっとやってみたいことがあってやってみたらできたので、小ネタとして残しておこうかと思います。 やりたいこと 諸事情で、代数式をstructとして管理することをしています。毎度ですが、なんでそういうことをしようとしているのか？は聞いてはなりません。 // こんなtraitを定義しておく trait Equation { // envは変数のhashmap fn evaluate(&self, env: &HashMap<String, f32>) -> f32; } こんなtraitを実装したものを考えたいです。なお実装は自明なので省きます。で、これを普通に実装すると、ちょっと複雑になっただけで大変なことになります。 // 3.2 + 3.4 let e = ArithmeticEquation::new(Add, ConstantEquation::new(3.2), ConstantEquation::new(3.4)) // 掛け算とかがnestすると大変なことになる これをなんとかある程度楽にしたい、というのがモチベーションです。 方法の検討 Rustだと、大きく3通りのやり方があると思います。 procedural macroを実装する lexer/parserを利用してparseを実装する operator overloadとstructを駆使して頑張る macroとoperator overloadはcompile時に、lexer/parserは動的になる感じです。最終的にはlexer/parserが必要になりそうなんですが、一旦は静的にできれば（テストを書いたりするときに）便利です。となると、macroかoperator overloadが選択肢になる感じですね。 lexer/parser自体を生成するmacroとかはあるようですが、そもそもparseするという行為自体が、compileした後の話になるので。 Operator overloadを検討してみる RustのOperator overloadは大変に強力である意味シンプルなのですが、 Scopingが困難 です。 KotlinとかのOperator overloadでは、interfaceの実装元とかで切り分けられたり、scoped functionを利用することで、DSL/operator overloadの利用範囲をscopingすることがるできます。 object Ops { operator fun invoke(f: Ops.() -> Unit) { f() } infix fun String.test(rhs: String): boolean {...} } // こんな感じで使える Ops { "hoge" test "foo" } // 外だと明示的なimportが必要。 翻ってRustのOperator overloadは、標準にある Add や Sub といったTraitを型に対して実装する・・・という形です。 ...

気が付いたら11月も終わって師走になりそうですね？一年が年々早くなっていきますな。 この二ヶ月くらい格闘していたものができました。なんかこないだもこの書き出しをした気がしますが気にしてはいけない。 まずは写真 最近は一体型にしてましたが、roBaとかroRaとか人気ですんで、分割型に戻ってきました。やっぱ楽ですね。 スペックはこんなんです。 いつもの40%/42キー 30%はあんまり興味ないので 16.6mmピッチ Choc v2専用 PMW3610センサーを利用したトラックボール 完全無線 単三電池駆動 エンコーダー対応 ケース、キーキャップ、エンコーダー、トラボケース、スイッチプレートまで全部3Dプリンター製 今回発注したのは基盤類だけです それなりの薄さ キートップまで2.2cmです 名前は、それなりに薄さを追求してみよう、ということで ThingnusBall です。いつもどおりケースやらなんやらは以下のリポジトリで公開してます。 https://github.com/derui/ThingnusBall 今回の物理配列 今回ですが、前作った Orbit One を分割型に持っていったような感じにしてます。やっぱ自分の手をそれなりに測って作っただけあって、しっくりきていたのは強いですね。 挟ピッチにしているのは、もはや一回慣れてしまうと、MacBook（仕事用）ですら広く感じてしまいます。キーキャップも自炊（なにか違う気がする）できるようになったということもあり、自由度が上がっています。 キーキャップ 前回は初めて印刷しましたが、今回もうちょっと頑張ってコンベックスとスフェリカルのキーを印刷しました。こんな感じ。 物理になると分かりづらいんですが、コンベックスはちゃんとコンベックスしてます。なお、前回印刷したスフェリカルは指を置く面がちと狭かったので、全面に広げています。なお、色々めんどうなので、 印刷時にはサポートがいらないように 印刷してます。側面を立てる感じにして印刷しているので、どうしてもこういう形だと、底面になる面の角がヌルくなりますね。とはいえ、これが嫌だとすると、 光造形 か 焼結方式 、または射出形成が必要になってくるんではないかと。FDMで軸を下にしてサポートを追加するのはだいぶリスキーです。 DMM.makeで販売されているキーキャップは、大半が焼結方式・・・のはずです。私もちょっとだけ持ってますが、手触りとかいいですよね。高いんですが。 もしかしたらMXキーであれば余裕が出るのかもしれないですが :thinking: 今回は厚さをメインテーマにしたので、そもそもMXは選択肢に入っていませんでしたね。とはいえ、実際に指を置く面はかなり滑らかで、手元にあるNuphyのキーと比較してもひけをとりません（当社比）。 厚さ 前回がトータル4cmくらいの大作になってしまって、尊師スタイルをやろうとしたら 分厚すぎてほぼできなかった :cry: という悲しい現実がありました。 https://salicylic-acid3.hatenablog.com/entry/sonshi-introduction 尊師スタイルはこちらなどを参考に。尊師＝RMSです。色々批判もある方ですが。 前々回も結構分厚かったので、今回は トラックボールのブレイクアウトボード含めて（できるだけ）薄くしよう！ というのを唯一のデザイン目標にしました。 最小の厚さとは？ さて、一般的なキーボード（ロープロ）で実現できる最小の厚みとはどれくらいなのでしょう？一旦以下の条件を前提にして計算してみましょう。 ホットスワップする スイッチプレートを使う choc v2 構成物 厚さ(mm) ソケット 2 基盤 1.6 スイッチプレート 1.5 choc v2 6.4 キーキャップ 3 合計 14.5 (choc v2は軸の頂点まで、キーキャップはキーの軸の頂点から天面まで、です) ...

たまには超小ネタです。 Bevy触ってます ちょいちょい中断しつつですが、bevyというゲームエンジンを触っています。なんというか現代的なゲームエンジンを触るのは実は初めてなんですが、Direct3Dで・・・みたいな時代とは隔世の感がありますね。そもそも古すぎか。 やりたいことのためにWASMで動作するように作っているのですが、 glTF ファイルを読み込ませようとしたら、 .gltf.meta という謎のファイルが要求されてエラーになって困ったことになりました。ちなみにglTFファイルとは、WebGLの標準フォーマットとのことです。 https://knowledge.shade3d.jp/knowledgebase/gltf%E3%81%A8%E3%81%AF 解決 https://github.com/bevyengine/bevy/issues/10157 困ったときは公式のissue、ということで探したらありました。どうもbevy_assetsの機能で、metadataを確認することでより適した処理にできる、とかそういうもののようです。ちなみに生成するためには 一回起動したらいいよ 、とのことですが、WASMの場合そもそも書き込むっつってもどこに？となってしまいます。 app.add_plugins(( DefaultPlugins .set(AssetPlugin { // これを追加する meta_check: AssetMetaCheck::Never, ..default() }), )) issueにあったやり方とは違いますが、meta_checkを無効化するとOKです。私がやりたい範囲ではglTFはほぼ使わないので、これで特に問題なさそうでした。

前々から書こう書こうって思ってましたが、やっと重い腰を上げました。 結構前からやっていたものの、そもそもglidepointが使えなかったので日の目を見なかったやつです。 html: <!–more–> 元々のfirmware cirque pinnacleについては、元々zmkfirmwareの主要開発者が作成しているものがあります。 https://github.com/petejohanson/cirque-input-module 最初はこれを利用していたのですが、色々と機能を追加したくなってきたため、forkしています。 https://github.com/derui/cirque-input-module 改造したこと まず、absolute modeを有効にしたかったので、このPRを取り込みました。なぜabsolute modeがやりたかったのか・・・？というところなのですが、Glidepointは円形のpadをしているなかで、「どういうふうにスクロールさせたら丁度いいのか」と考えたところ、大きく２つの案が出ました。 トラックパッドよろしく二本指でスクロールする Windowsとかのトラックパッドにある、エッジ部分のスライドでスクロールする この内、前者については、glidepointの基本モードである relative mode において対応できるのですが、二番目をやろうとすると、edge検出が必要なので、絶対座標が必要になります。で、今回はせっかくなのでedgeで指をくるくる回したらスクロールするようにしてみたかったのです。 エッジスクロールの実装 実装としては以下のPRになります。 https://github.com/derui/cirque-input-module/pull/1 いくつか使いづらい点などもあったので、追加で改造していますが、基本的には以下のように動作します。 所定の位置が最初のtouchであるかを確認する touchされているが、所定の位置でない場合は、次にtouchされるまで何もしない 所定の位置である場合、初期化 次にカーソルを動かしたら、 一つ前の位置との角度を取る 該当の角度（ラジアン）に対応する方向にスクロールのイベントを発行 と、結構シンプルな作りにしています。 加速度をベースにしたカーソル移動 Macbook/Appleのトラックパッドなど、現代のトラックパッドは基本的に加速度ベースでカーソルを移動しています。ゆーっくり指を動かしてトラックパッドを横断したときと、シュッと横断したときでは移動量が違うのがわかるかと思います。 オリジナルの実装では、シンプルに移動量がそのままわたっている形になっていましたが、ゆっくり動かそうとしても機敏すぎてつかいづらい・・・というのがありました。 加速度については、relative modeでもわかるのですが、改めて実装しています。なお、実装方針などはClaude Codeで確認しながら実装しました。こういう数式のパターンにハマりやすいのは、調べるより早いですね。 ただ、加速度ベースの移動は、いい塩梅を探すのが大変難しい・・・という難題があります。これについては継続して確認しているところではあります。Xiaoのリセット難易度が大変高いの、なんとかなりまへんかね 🤔 firmwareは怖くない（間違うと怖いけど） 最近のC言語は、古とは違って制約も少なくなり、だいぶ書きやすくなってます。zmkの場合は、複雑になりがちなポインタのポインタ・・・といったものがAPI上に登場することも少なく、だいぶ素直だと思います。zephyrから来ているマクロを把握するほうがよほど大変という・・・。 ちょっとここが・・・というのがあれば、当然オリジナルへの還元も視野に入れつつ、自分でいじってみるのも一興ではないでしょうか。

残暑が残暑というか「普通に夏だね？」って感じですね。もう暑いのはいいです。 この２ヶ月くらい格闘してたものができましたので、それについて書こうかと思います。 ...