自作自称Lilithキーボードの現在状態、プレートが来ました、基板設計中 [自キ沼#7]

8月が終わる前に、試作キーボードの現在の状態です。

FR-4のトッププレート（キープレート）が来たので、試作Lilithをバラして、スイッチをはめ込みました（はじめてのPCB発注の経緯は以前の書き込み、Lilithの構想はそれ以前の書き込み）。

• キースイッチの穴は少し緩めですが、chocスイッチの爪がきちんと引っかかって安定しました。プレートの効果大です。FR-4の厚みはchocスイッチの寸法通り1.2mmを選びました。次回はきっちりした穴のサイズにしたいと思います。
• ジョイスティックの穴は少し狭かったのでやすりで削りました。金具が付いている部分がネットで見つけた図面よりも少しずつはみ出しているためです。これも要改善。
  
• SU-120の試作基板の時からキー配置を変えたので、SU-120で作成していた物理構造を一部バラしてプレートにはめ込みました。プレートがあるので、SU-120自体は固定していなくても構造が安定しています。ソケットでキースイッチをホットスワップにする場合は、プレートは大事ですね。
  
• 実はSU-120はケアレスミスで白を選んでしまったのですが、今となっては、試作中はかえって映えて良かったかも、と思っています。
• 配線についても届かなくなった部分はバラしました。再度の配線はまだしていないので、いまは動作しない状態です。
• キー配置を変えたのは、右手Backspace/Delの部分を削減して双方8x4にすることで左右の全体サイズを揃えたかったのと、基板をリバーシブルにして節約したかったためです。
• オーソリニアや純粋なカラムスタッガードは左右対称ですが、Lilithは行方向にズレているAlice配置です。どうやってリバーシブル基板にするかと言うと、こうです。
• 数字行と0.5uズレのQ行はリバーシブルで左右共通、A行とZ行それと親指キーを合わせたブロックは前者とは別のリバーシブルの左右共通と考えました。ジョイスティックがあって配線が複雑な右手側は一体の基板にし、左手側は上2行のブロックと、下2行と親指キーを合わせたブロックを分割し、ズラして配置することで左手側の基板になるように考えました。左手側は基盤をカットしてしまうので、上と下のブロックの間は配線あるいはコネクタ接続になります。何日もキー配置を眺めているうちにこのアイデアが浮かんできました。大きくカスタマイズしたSU-120といった感じですね。
  
• 上と下のブロックの間（Q行とA行の間の）ズレ量は、左手側は0.25u、右手側は右手ホームポジションで逆T矢印と数字が押しやすいように0uとします。なお、下ブロック内のA行とZ行のズレは標準キーボードでは0.5uですが、わたしの場合は、Cキーを人差し指でもっと押しやすくするように0.75uとします。右手側はオーソリニアに少し近い形になります。
• ジョイスティックは右手のいわゆるBキーの位置に変更した（試作の実機での気付き）ので、ホームポジションからアクセスしやすいです。
• このジョイスティックは、左手のBキーと共通の位置です。右手側は基板を切り取ってジョイスティックを埋め込めるようにします。高さもchocスイッチといい感じで釣り合います。
• ジョイスティックの見えている部分は1uに綺麗に収まるのですが、ネジ止めのベロが少し外にはみ出している（隣のキーの隙間に収まる範囲なので配置的にはセーフ）のと、接続ケーブルがあるので、どうしても1uに収まるユニットにならないのが残念です。独立ユニット基板として、1.5uサイズくらいにならできる可能性があるかもしれません。Cherry MX用として考えると、高さ方向に基板を積み上げても良いかもしれません。
  
• ミドルプレートと、簡易的なケースとしてのフレーム枠も、FR-4で作成するつもりです。キーボード全体ですき間のないソリッドにします（わたしは未体験のサンドイッチマウントとは対極だと思います）。なお、今回のキープレートはボトムプレートとしても共通化できるように考えて作ったつもりです。
  
• 基板は、ジョイスティックの0.5mmピッチのFPCコネクタと、高さを稼ぐための1mmの表面実装ダイオードをはんだ付けする自信が到底ないので、JLCPCBのPCB Assembly発注に挑戦したいと考えています。
  

現在、KiCADで基板と格闘しています。
キーキャップについては、またまた欲が出てきたので、改めて投稿したいと思います。

この投稿は、Sparrow62 v2＋片側だけLDSAロープロファイルキーキャップ を使って書きました。

一年の時を経て、ペンタゴナワールドの物語が再開 「重戦機エルガイム」のYouTube配信が2022年8月25日から

去年、13話まで公開された「重戦機エルガイム」（去年のわたしの投稿です）の続きが、YouTubeのサンライズチャンネルで来週からプレミア公開されるそうです（まんたんウェブの記事にて）。
今年はエルガイムは木曜日20時なので8月25日からですね（予告の詳細に告知あり）。

エルガイムは今の時代では考えられない1年物の全54話なので、たぶん今回の公開も1クール分になるのかと想像しています。
MkIIの登場まで見れるかどうかですね（Wikipedia各話リスト）。

いずれにしてもシー・ユー・アゲインが叶いました。

JLCPCBへPCB作成とキーキャップの3Dプリントを発注してみた [自キ沼#6]

(8月18日、末尾に追記しました)

SU120での試作キーボード作成は、完璧に動作させることまでが可能ですが、キースイッチを固定するトッププレート（または単にプレート）がないために、どうしてもフニャフニャしてしまい本格利用には無理があります。
プレートの素材としてアクリルは適度な柔軟性があって良いようですが、最低の厚みが2mmまでしかなくて、Kailh chocのプレート仕様の1.2mmに合いません。
PCB基板の素材であるFR-4であれば、厚みの選択肢が多く、複雑な形状の加工も作成発注できます。

PCBの作成サービスは有名どころが何社かありますが、その中で比較的低価格を売りにしているJLCPCBについて調べ始めました。
PCB素材もFR-4以外にアルミも選べて、さらに表面実装部品の工場組み立てサービスもあるようです。
ちっちゃいダイオードやアナログジョイスティックの0.5mmピッチコネクタのハンダ付けは、自分では成功する気がしていなかったのでこれはぜひ試してみたいです。
（さらにPro MicroのArduinoチップ(いまは高価)やRaspberry PI PicoのRP2040チップも選べるようです；コントローラ部分の厚みは確実に稼げますが、キースイッチの位置にはおそらく配置できないので底面積はほとんど稼げず、メリットがあるかどうかは今後の検証が必要です。）

さらに3Dプリントサービスもあり、手作業の手作りではどうにもならない、キーキャップやケースの作成も依頼できることに気づきました。
チャット問い合わせもできて対応が早いのですが、唯一かつ最大の難点が英語のみという点でしょうか。

前回の投稿でも書いたように、ちょうどKailh choc用の独自LDSAプロファイルのキーキャップの3Dデータが公開されているのを見つけました。

• 公開されているデータはcorne用(corneの派生corne-ish ZEN用)なので、1u通常キー、1uホーミング、それとMBKにはない1u親指（手前の高さが下がっているコンベックス）と、縦長の1.5u親指キーの構成です。
• どうしても欲しかった、横長の1.5u親指キーは、1u親指キーを切り貼りして作成しました。3D CADなので、切り貼りは切り取り線じゃなくて切り取り面を指定して元データを分割、キートップ部分を横に伸ばして元の配置で合体させました。Autodesk Fusion360の基本操作はしばらく触っているうちに分かりました（FreeCADも触ってみましたがわたしにとってはとっつきが悪く勉強が必要そうでした。なおパソコンはM1 MacBook Airを使っています。KiCADも含めてRosetta 2で問題なく動いています）。
• 3Dプリントに限らずJLCPCBでの発注は一品ごとに最低料金と場合によっては技術料がかかるので、キー10個で一つのデータにして品数を減らすようにしました（小部品の連結の上限10個はデータルールにあり）。プラモデルのランナー（枝）のように、外から見える表面に切り取り箇所が露出しないように、太さ1.5ｍｍ長さ5mmのコの字型の円筒をキーキャップの下面に連結しました。1u通常キーx10のパーツは1品で最低料金の$1に収まったようです。
  
• これでSTLファイルを作ってJLCPCBにアップロードし、黒色レジンを指定して発注したのが日曜日。データのレビューはなぜか一発で通って火曜日に製造完了しました。今は香港の近くの深センに物があって海外便の輸送を待つのみ。クーポンを使って金額は70キーで￥1,300。まだ手元になくて、どんな出来栄えになっているのか楽しみです。

次に発注したプレートの方はいろいろ欲張って盛りすぎたためか、配線がない単純な板なのに、キーキャップよりも苦労しました。

• Keyboard Layout EditorでわたしのLilithのキー配置を入力し、DXFファイルを生成。これをKiCADのPCBエディタに読み込んで、グリッド原点を合わせながら、キースイッチ穴のフットプリントを配置しました。小指キーの斜めになっているところは、フットプリントに13°の角度だけを数値指定して拡大しながら目分量で配置しました（一度配置した場所は基準と決めて後工程ではもう動かさない）。さらにキーボードの外形をEdge.Cutsレイヤにお絵描きして、基本形は完成。
• デザイン性も考え、左右ブロックの外形面積を同じにしたくて、右手端で出っ張っているバックスラッシュキーだけは別の場所へ移動することにしました。これで右手側は6〜0と- = Backspaceの8列。左手側は、Escとバッククォートと1〜5、さらに中央にDelなどの追加キー列1列も設けて、左右ともに8x4に共通化できました。
• わたしのLilithはキー配置が左右非対称なのでプレートはリバーシブルにできません。せめて、キースイッチをはめるプレートとボトムプレートをなんとか共有して、PCB費用を節約できればと考えました。そのためにコントローラやTRRSジャック部分を選択切り取り式にしました。
• 初心者のわたしが苦労したのがこの切り取り線です。1回目は2mm幅のスロットを40mm程の長さでくり抜いて(始点終点は四角ではなくて半円)、1mmの間隔を開けて配置したのですが、残す部分が小さ過ぎて製造過程で折れてしまうとの指摘でリジェクト。2回目は同じスロットで、間隔を2ｍｍに、間に2ｍｍの丸穴を配置して一点鎖線にして多少補強してみましたが同じくリジェクト。2mmの丸穴部分は最初はEdge.Cutsに単純に円形を描いていたのですがこの切り取り工程に無理があると思い、直径2ｍｍドリル穴に変更し製造しやすくしてやることで、ようやくレビューが通りました。
• ドリル穴の作成は、例えばキースイッチの足部分のフットプリントではパッドの属性でNPTH(non-plated through hole; 電気的に導通させないスルーホール穴)を指定したものが使用されていますが、PCBエディタの中ではなぜかパッドを作れません。代わりにピア(via; 多層基板のレイヤ間を接続するメッキ穴)で穴の径を指定してドリル穴を作成しました。
• さらに、右手用と左手用の斜め部分をうまく組み合わせて(片方を反転)、全体の材料面積を少しでも節約してみました。
• このプレートの方は、5回のレビューに4日かかり、今日月曜日の時点でやっと製造ラインへの投入待ちです。クーポンを使って金額は最少5枚で￥4,800になりました。100mm x 100mmを超えると材料代金が掛かるのと、追加技術料￥1,000（日曜だったのでチャット窓口が開いておらず後日問い合わせます）、送料も最安￥600のOCS NEPが選べない上に重量料金になります。材料のボードサイズは360mm x 120mmでした。
  

キーキャップ、プレートとも、実際どんな物が来るのか、到着が待ち遠しすぎます。

この投稿はLilithプロトを使って書きました。

[2022-08-17] PCB製造の追加料金の￥1,000は、切り抜き・くり抜き(Routing)が多いためと回答がありました。
確かにキースイッチの部分含めて90箇所くらい穴を開けている（ドリル穴は除く）ので、多いんでしょうね。
右手と左手を一緒にして節約と考えたのですが、かえって高くなってしまった可能性があります。
キー数が多い（ゆずれない要件ではありますが）のも、こういう面でコストに影響ありますね。

プレートでしっかりスイッチを保持できるようなら、基板回路は100mm x 100mm以下にバラバラにしてしてしまってもいいのかも、と真剣に考え始めています。
SU120を超カスタム化する感覚です。

PCBの進捗経過は、月曜日にレビュー通過＆正式発注、火曜日に製造完了＆出荷待ち、です。
キーキャップの3Dプリントの進捗経過は、先週月曜日にレビュー通過＆正式発注、火曜日に製造完了、（少し手違いで遅延があって）金曜日出荷、翌水曜日の今日 関空到着です。

[2022-08-18] 翌木曜日午前、キーキャップ到着しました。
第一印象悪くないです。
気のせいかもしれませんが、肌触りが粉っぽいというか、指に何かが付着する印象なので、いちど極薄の洗剤で洗ってみます。

Kailh choc用のキーキャップの新しい選択肢LDSA [自キ沼#5]

自作キーボードのキースイッチはロープロファイルのKailh chocがお気に入り、と言うか自分の中ではロープロファイル縛りを設けています。
キーキャップの方は、素材としては、ABSプラスチックは昔から肌触りが好きじゃない印象があって初めからスキップ、PBTのMBKが結構良い感じだと思っています（游舎工房ではカラフルな品揃え）。
Cherry MXの世界では、キーキャップだけも数多あって一つの大きな沼になっているようです。
キーキャップによって、打鍵音や、入力のし易さも変わるそうです。

Kailh choc用にMBK以外の選択肢がないもだろうか、といろいろ漁っていて見つけたのが、写真のLDSA profile keycapです（Low profile DSAだそうです）。
通常のキーはくぼみが大きいグラマラスな形、親指キー用に角が取れた形（コンベックス）と、ホームポジション用（ホーミング）もあります。
是非とも触ってみたいのですが、今のタイミングでは販売されていません。
仮に発注できるタイミングに出会えていたとしても海外発送なので送料がバカバカしいことになっていた恐れがあります。

このLDSAですが、うれしいことにCreative Commons, non-commercial licenseで3Dデータが公開されていて（自作キーボード界の良いところですよね）、自分で印刷することもできそうです。
でもどれくらいの費用が掛かるのか見当もつきません。
ある程度の経済性（カスタムキーボードのように高すぎない）も自分の中での必須条件のひとつです。
3D CADもちょっと勉強して、自分の中の3Dプリントの最初の課題として、このキーキャップにも取り組み始めたいと思います。

[2022-08-07] なんと、KiCADよりも先にFusion 360をいじくり始めています。
プラモデルの元を作る要領でしょうか。
レジンのキーキャップはどんな感触なのかも未知数ですね。

自作キーボード沼へ、その4：6x3コンパクトキーボードのキー配置をOLEDで動的に表示できたら

自作キーボードの設計で、あれもこれもと欲張ってキー数を増やしてしまうと、手間も時間も、何よりパーツの費用が余分に必要になります。
無理にキー数を減らしてかえって使いにくくなったら本末転倒なのは当然ですが、かっこよさからもやはり少ないキー数は一つの目指すところだと思います。
カラムスタッガードやオーソリニアで左右の配列を対称にしておけば、基板をリバーシブルにしてさら節約できます（PCBの発注は最低5枚から）。
6x3配列は、ホームポジションを完璧にすっと守って入力できるメリットもあります。
そんな中にあって、foostanさんの6x3＋親指3キーのcorne (crkbd) は世界中で使われているもっとも有名な自作キーボードと言って間違いないでしょう。

以下、わたしがcrkbd等の6x3キーボードに踏み切れていない理由です。

• 標準キーボードでも英字キーはブラインドタッチできますが、記号はどうしてもキー刻印頼ってしまいます（Shift+6 が ^ は記憶があやしい）。標準配列じゃないとなおさら大変そうです。
• crkbdのようにキー数が少ないと、足りない記号キーは、レイヤを複数使ってキーマップに押し込んでやる必要があります。
• キートップにシールなどで刻印して、目で見てすぐに探せるようにするのが記憶の負担を下げるのに一番効果的だと考えています。標準キーボードであっても刻印がある方がとっさの時に安心で結局は早く入力できます（意外とキー刻印に頼っていると思います）。
• しかしながら、自作キーボードではキーマップを日々カスタマイズするのが常です。シールを頻繁に張り替えることもできません。また、既成のキーキャップだと記号などが自分のキーマップに合いません。結局、無刻印キーキャプで記憶に頼って使っているのが現状だと思います。

これはもうなんともならず、自分にはcrkbdにご縁が無いと諦めかけていたのですが、今週、パッとアイデアがひらめきました。
それは何かと言うと、crkbdにも付いているOLED（有機ELディスプレイ）の活用です。
スマホのソフトウェアキーボードは、フリップ入力のテンキースタイルであれ、フルキースタイルであれ、キー数は少ないです。
動的にキー表示を行うことで、ユーザの文字入力を助けくれていて、実際、日常利用に耐えられる形になっています。
これに似たようなことが6x3のような自作キーボードでもできれば、と考えました

• まず、crkbdのOLEDは縦長なのでキーマップの表示のためには使いにくいのですが、そこは自作キーボードの利点を生かし、PCBまでカスタマイズしてしまえばよくて、OLEDを横長(ランドスケープ)に配置してやることもできるはずです。
• 6x3のキーマップを、レイヤ毎に切替えて動的に表示してやれば、物理キーボードのキートップに文字を刻印や、ソフトウェアキーボードに、近いメリット、すなわち目で見てどこにどの文字があるかが分かり、たまにしか入力しないうろ覚えの文字でも入力できるようになります。
• OLEDのピクセル数は32x128です。6x3配列の3行の文字を表示してやろうとすると文字の高さは10pixelになり、これは試してみないと良いか悪いか分かりません。

そこで、10pixelの文字がどんな感じになるか、視認性はどうか、を検証してみたくて、ビットマップ職人の真似事をしてみました。
32x128 pixelのエリアに6x3で文字を配置したのが今回の図です。
行間が1pixelしか取れなくてそのままだと縦方向がゴチャッとしてしまうので、少しずらしてロースタッガードの表示しています。
もしかすると、文字の高さは11 pixelにしたほうが良かったかもしれません。

わたしの手元にOLEDの現物がないので、このアイデアをすぐに実機に表示してみることができなくて残念なのですが、それほど悪くないのではないでしょうか。

今後のチャレンジは、次のような順になると思っています。

• OLEDの実機で表示具合を試してみる。まずはSU120でやってみる。
• 定義したキーマップを動的に反映してOLEDに表示する仕組みを考える。VIAの定義を取得したり、ビットマップフォントをOLEDに配置したり、の処理になると思っています。
  これはできなくても、キーマップ定義を変えたらOLEDの表示用ビットマップをお絵描きツールで書き換えればいいんですがね。
• crkbdのPCBをカスタマイズして、OLEDを横配置にする。
  

いかがでしょう、crkbdのコンパクトさを活かしつつ、使い勝手をかなり高めるのではと思っています。

この投稿はSparrow62 v2＋[Kailh choc Pink＋Brown spring] を使って書きました。

 

[2022-08-01] 過去にも（当然ながら） 同じような事を考えて実行している方がいらっしゃいました。
retkekさんが一体型のAtreusキーボードに64x128のOLEDを付けてキーマップを表示しています（ブログ記事 https://www.kmr.me/posts/atreus_oled/、ちなみにこの方はAtreusキーボードを最初に2018年2月に組み立てて、2020年9月にOLEDを取り付けたようです、相当使い込まれていらっしゃいますね）。
（Atreus自体も、すごく歴史がありますね、2020年にKeyboardioが製品化、そこの2014年のブログにはTechnomancyのオリジナルがもう登場しています。
游舎工房と、数字行と小指列を追加して6x4にしたAtreus64がTALP Keyboardで販売されていますね。）

実際に公開されている表示画像を32x128に合うように再編集したのが右の画像です。
OLEDは両手側に付けてそれぞれで表示しないと入りきらないだろうと思っていたのですが、crkbdくらいのキー数であれば、OLED 1枚だけで全キーを一括で表示できそうですね。
これ、良いんじゃないでしょうか。

それと、表示フォントに関して、QMK Firmware内蔵のものでも良いのですが、Arduino向けのライブラリの中でいろいろ提供されています（実際の画像付き一覧 https://github.com/olikraus/u8g2/wiki/fntgrp）。
10pixelとか11pixelのフォントはなかなかないのですが、ざっと見てみたところ UW-ttyp0 の中の、ボールドの t0_11b_tf かレギュラーの t0_11_tf が見やすそうです。

自作キーボード沼へ、その3：Kailh chocスイッチのスプリング交換

自作キーボード沼の一つ、キースイッチ選び、更にはスイッチカスタマイズに足を踏み入れてしまいました。

わたしの最初の自作メカニカルキーボードSparrow62 v2では、タクタイルが良いと思いKailh choc Brown（茶軸）を選びました。
2番目のプロトタイプキーボードでは、もっと軽く、いっそ3倍軽いものと思い、Pink（ピンク軸）を選びました。

• 茶軸：タクタイル、押下圧45gf、タクタイル動作圧60gf
• ピンク軸：リニア、押下圧20gf

茶軸はちょうど良くて満足と思っていましたが、1ヶ月間使っていくうちに、決定的に悪いわけではないけれども、なんとなく重く、指が疲れているのではと思うようになってきました。

そこで新しいキーボードでは別のスイッチをと思い、選んだのが一番軽いピンク軸です。
手に入れて、スイッチ単体では茶軸とそれほど違いがないかもとも思いましたが、実際にキーボードに付けてみると、力を入れずに指を少し下げただけで動作してしまうほどの軽さです。
乗用も不可能ではないですが、押そうと思っていないキーに触れただけで入力されてしまうことがあり、それがゆえに不用意にキーを押し下げないように意識して疲れるような感じが、3日間使ったピンク軸の感覚です。
3倍軽いのは（赤い色ではないですが）やはりやり過ぎで、とてもピーキーな感じです。

どうにかならないかと、一度両方のキースイッチを分解押して内部を見てみることにしました。
Kailh chocのケースの上下を止めている爪はそれほど固くはなく、ピンセットで少し押し広げてやるとすぐに外れました（スプリングがどこかに飛んで行かないように注意は必要）。
発売時期がピンク軸の方が新しいので、茶軸にはあるスタビライザ無しで軸を安定させるガイドの突起があるなど、形状が微妙に違います。
どちらも、軸と接点操作パーツのすれあう溝にはグリスがしてありました（ファクトリ・ルブと言うのでしょうか）。
その中で、スプリングは、明らかに素材の太さが違いますが、サイズ（太さと長さ）は同じように見えました。
これは入れ替えられるんじゃない、と思い、テスト的に1つやってみたところ動作には問題なさそうです。
軽すぎるピンク軸のバネに、茶軸のタクタイルの抵抗感が合わさってちょうど良い塩梅になりそうな予感がしました。

これはやってみるしかないと、手持ちそれぞれ70個のスイッチのスプリングの入れ替えを敢行しました。
入れ替え作業にはおおよそ3時間を費やしました。

改造ピンク軸の方はスムーズな入力感覚でいい感じですが、茶軸の方は改善はされましたがまだ少し軽すぎる感じが残っています。

• 茶軸＋ピンク軸スプリング：タクタイル、押下圧20gf、タクタイル動作圧は感覚的に25gfくらい、ピンク軸スプリングのピーキーさのある程度の軽減に成功しました
• ピンク軸＋茶軸スプリング：リニア、押下圧45gf、おそらく人気のRed Pro軸(35gf)やCrystal Silver軸(40gf)相当でしょうか、しっとりしたいい感じです

茶軸は元々タクタイル感が少なすぎると言われているので、今回のような小手先のやり方ではこれが限界なのかも知れません。
折良く、遊舎工房で新型Kailh choc Sunset Tactileのグループバイをやってます。
この際なので応募してみようかなと思います。

• 夕焼け軸：タクタイル（改良強化型）、押下圧35gf（開発元LowproKBによると40gfに変更、出荷日は8月まで延長）、タクタイル動作圧50gf

とは言え、しばらくは今回の改造茶軸を使ってみようと思います。
わたしは今のところロープロファイル縛りを設けているので選択肢はこれくらいなのですが、MXスイッチにも手を出してしまうとスイッチとキーキャップが無数にあって恐ろしいですね。

この投稿はLilith proto＋「choc茶軸＋ピンク軸スプリング」を使って書きました。

自作キーボードの沼へ、その2：自作第一号Lilith proto - Alice配列、左右分割、薄型、ジョイスティック

下がジョイスティック付き自作プロト1号

作りました、本当の意味での自作（本人が作った）キーボードの第一号です。
前回の投稿の、カラムスタッガードと十分な追加キーを備えた74thさんのSparrow62 v2（ご本人の紹介記事）で、すっかりメカニカル自作キーボードの魅力の虜になりました。
既存のキーボードで満足できればよかったのですが、個々人のクセや好みを満たせない面がどうしても出てきてしｆまいます。

そこで、わたしとしてやりたいことを整理して進めることにしました。

Sparrow62から取り入れたい利点：

• フルキーボードの、矢印キーとFnキーを除くすべての文字をレイヤ切り替えなしで入力できるだけの十分なキー数
  （6x3をSparrow62上でシミュレーションしてみましたが、どうにも頭と指がついていけませんでした）
• ロープロファイル
• 左右分割で、気分に合わせたタイピング

追加したかった機能、特性：

• カラムスタッガードだと、人差し指でCを押す癖にどうしても対応できず（Fのすぐ下をCを置いてしのいでいるほど）、Aの段とZの段が横に0.5uズレた標準キーボードに近い配列を兼ね備えたモノを実現したい
• 小指が短い方なので、左右端の小指担当キーはカラムスタッガードでももっと下にズラして届きやすくしたい（たとえばRemapの共同作者YoichiroさんのLunakeyのように）
• この2つをちょうど併せ持つAlice配列が良さそう
• 左右分割キーボードはMagic Trackpadを中央に置けますが、大きいので、キーボード自体にポインティングデバイスが一体化されているのが理想かも
  ゲーム機（Nintendo Switchなど）のアナログジョイパッドの部品が潤沢に手に入るので繋いで試してみたい
  

第一号なので、配線やレイアウトが、簡単にカット＆トライができるのが重要と考えました。
これにうってつけのキットがe3w2qさんのSU120です。
事前にPowerPointなどでレイアウトを練り、アナログジョイスティック部品（例えばAmazonのこれ）も取り寄せてテストした上で、実際の組み立てに取り掛かりました。
このレベルのものは、いわゆる動作検証用のプロトタイプですね。

組み立ては1日2〜3時間のペースで進めて、3週間ほどかけて、一通り組み上がって使える状態になりました。
写真が現在の姿です。

• キー数は、左側25＋親指5＋追加3と、右側30＋親指5＋マウスボタン2の、合計70キーです。自作キーボードとしては少し多めになってしまいました（たぶんキー数は少なくするのがコツなのかもしれません、部品も手間もかかりました）
  
• アナログジョイスティックがいい感じの薄型で、サイズがほぼピッタリ1uなので、収まりが非常に良いです。ブランク基盤の1コマに結束用の針金で縛っているだけですが、意外とグラつきません。0.5㎜ピッチのＦＰＣリボンケーブルから標準ピッチへの変換ボードもテープで張り付けています
• 左右クリックや、クリック・ホールドしてドラッグ、縦横スクロールにも対応していますが、遠くへ素早く移動したい時のために加速度をつけるチューニングが必要と思っています

自分の取り組みのご紹介としてまずは投稿しました（工夫した点やファームウェアに関しても整理したいと思います）。

この記事はLilith proto（仮称）を使って書きました。

自作キーボード沼へ、その1： 薄さと絶妙なキー数が使いやすい Sparrow62 (+1) v2

わたしのSparrow62 (+1) v2、
矢印キーは試行錯誤中の状態

先月の書き込みでは、Kinesis Freestyle2というメーカー製の分離型エルゴノミクスキーボードを購入した顛末をご紹介しました。
Freestyle2を使って次のことを学びました。

• 高さがあってタイプ音がうるさい印象のメカニカルキーボードスイッチを避けることができる
• やはり分離型キーボードはより体に自然にフィットして、肩や腕に優しい、トラックパッドは真ん中置きが絶対的に良い
• 厚めのキーボードは後方をチルトしないと奥の方のキーに指が届かない。手首を机に付けるタイピングスタイルでは指に負担がかかって疲れやすくなる
• WindowsとmacOSのキーカスタマイズツールを使って、ある程度の入力キーの置き換えを行なってみたものの、どうしても限界があり、結局はフルカスタマイズできないと飽き足らなくなる

そして、より良いキーボードを求めてさらに色々と物色し始めました。
自作キーボードであれば、キーのカスタマイズはほぼ無限に自由にできます。

• 多くのものは通常サイズの背の高いキースイッチ（Cherry MX互換）だけれど，少数だが背の低いLow Profileのキースイッチ（Kailh  choc）を採用あるいは両対応のものあり
• 分離型のキーボードが自作キーボードの中では多数を占めていて、いい感じ
• キーボードのキーの数も様々で、数字キーを含んだ6x4と、アルファベットのみの6x3に二分されています。6x3はホームポジションを一切崩さないメリット（ホームポジションの範囲にしかキーがないので崩れようがない）はありますが、Modifierをそれも複数を駆使しないと必要な文字が入力できません。わたしはコンパクトさよりも標準キーボードのようにすぐに全ての文字を入力できる方が好きだと思いました
• キーの配列は、標準キーボードのように上下に隣り合ったのキーが横にズレているもの（ロースタッガード）と、指を斜めに動かさず前後に曲げ伸ばししてキーを押せるようにしたもの（格子状配列のオーソリニアと、中指・小指等の長さに合わせて縦に多少のずれがあるカラムスタッガード）があります

数ある自作キーボードキットの中で、作者さんが薄さにこだわって、かつ、キー数も過不足ない数を載っけた作品がありました。
それが、74thさん作のSparrow62 (+1) v2です（キーボードのビルドガイド、Boothでの販売ページ、遊舎工房での販売ページ）。
自作キーボードキットではありますが、初めてでも安心な組み立て済みのものも提供されている点もポイントが高いと感じました。

わたしの自作キーボード第一号（とはいっても作成はしていませんが）としてSparrow62 (+1) v2を約1ヶ月使っての感想、気付きです。

• 足りないキーがないことは絶対的な正義だと思いました。単純な6x4だと、Escや右端の[や]やBackspaceやDelが収まらないのですが、Sparrow62 (+1) v2は左側にEsc用の追加1個、左右の中央にそれぞれ3個の追加キーが置かれていて、十分な余裕を持たせています
• とは言っても、カーソルキーとF1〜F12のキーはありません。F1〜F12キーはMod＋数字と-=で良いとして、カーソルキーをどこに置くかは迷いました。逆T配列を右下の端に置いたりと色々試してみましたが、右手のホームポジションであるJKLとIに置くのが今は一番しっくりきています（贅沢に右手側SDF Eにも同時に置いたりも便利です）。数字キーも左右に分断されていてとても押しにくいと感じるので、これもホームポジションのUIO JKL M,.を中心に配置する方式で検討中です
• 親指キーの活用として、右手親指にSpaceキーとEnterキー、左手親指にBakspaceキーを置いています。わたしはSpaceは圧倒的に右手のみで入力していたのと、前方に進むSpaceとEnterを同じ右側に、前に戻るBackspaceを反対側と、右左に分けて置きました。Backspaceは通常のキーと同じくらい入力頻度が高いのも親指ブロックに置いた大きな理由です
• ファームウェアがKMK Firmwareなので、キーマップはPythonインタープリタのソースコードになっています。これをテキストエディタで書き換えるだけでカスタマイズすることができて、いつでもどこからでもすぐに変更できる気楽さがうれしいです（これに対して多くの自作キーボードが採用しているQMK Firmwareはなにがしかの専用のツールがないとキーマップを変更できません）
• わたしの場合、Cのキーをどうしても人差し指で押してしまう癖がついていることに気付きました。中指への矯正をやってみようとはしましたが、できそうにありません。ここは入力の気持ち良さを優先して、左手最下段は一文字右にずらして配置しています。押し出されてしまうBのキーは中央の追加キーのおかげで居場所が確保できました。左端、Aの下はShiftキーを置けたのでこの配置は一石二鳥です
• こだわりのロープロファイルなので、ベタ置きでも、ダイソーのゴム製ノートPCスタンドを少し削って傾斜させても、どちらでも快適です

まだまだ、わたしのキーボード探求は続きそうです。
なお、本記事はSparrow62 (+1) v2を使って作成しました。

Apple Silicon Mac上でIntel x86 Windowsのアプリを最も高速に実行する方法は、現時点はWine

Hypervisor Framework（これに対してVirtualization FrameworkはHypervizor Frameworkにひと皮被せてLinux OSを実行しやすくしたもの）を使ってArm版WindowsをApple Silicon macOS上で実行できることは既に知られていることです。
更にその中で、Microsoftのエミュレータ機能を使って、Intel x86用のWindowsアプリを実行することもできます。

Appleは独自技術を使ってIntel x86アプリを実行するRosetta 2を提供していますが、Arm Windowsの中ではRosetta 2を使用することができなくて、Intel x86 Windowsアプリの実行速度はそれほど高速ではありません（おおよそ半分の速度くらいでしょうか）。

従来から有名なWineを使用すれば、Windowsアプリの実行をWindows OSをインストールすることなしに行うことができます。
このWineが昨年からApple Silicon Macに対応しています。
WineはmacOS上で直接実行されるもの（仮想化は使用しない）なので、Rosetta 2が活用できます。
少し試してみたところRosetta 2らしい高速性が発揮できていることが確認できました（わたしが軽いベンチマークでよく使う7zipのbオプションで、Apple Siliconネイティブのバイナリに比べてIntel x86 Windowsバイナリは2割程度の速度減に収まりました）。
（QEMUやUTMでIntel Windowsを丸ごと実行した場合は3～4倍遅いのに比べると雲泥の差です。）

ただしWineは、Windowsアプリの実行のためのOS環境を互換ランタイムライブラリで代替する方式のため、たとえば.NETなど複雑なランタイムを使用したアプリは互換性が取れなくて実行できません。
わたしが一番使いたかったWindowsアプリであるPaint.NETも実行できませんでした。

しかしながら、Wineで実行できるWindowsアプリでさえあれば、現時点でApple Silicon Mac上で最も高速に実行する方法であることは間違いないと言えます。
ゲームアプリなどでWineが対応しているものもあるようです。

ちなみに、Intel WindowsアプリではなくてIntel Linuxアプリの場合は、前の書き込みの方法の、macOS 13 VenturaのVirtualization Frameworkの新機能を使って、Arm Linux VMの中でRosetta 2を使う方法が最速です。

Apple Silicon macOSのRosetta 2が進化して、仮想Arm Linux内でx86バイナリの実行をサポート

今日はApple Silicon Macの仮想化とIntelエミュレーションに関して2つの話題を書いてみたいと思います。

先日のWWDC22でmacOS 13 Venturaが発表されました。
盛りだくさんの新し機能の中で私が一番だと感じたのは、やはり、仮想環境の中でIntel x86バイナリの実行が出来るようになることです。
ただし、手放しに喜べる機能ではなくて次の使い方に限定されたものです（Apple Developerサイトの解説）。

• Virtualization Frameworkを使ってArm版のLinuxを起動する
• Linux内でmacOSが提供するツールのおまじないを設定する
  
• Arm Linuxの上でRosetta 2を使ってx86用のバイナリを実行できるようになる
  

x86のLinuxを直接実行できるとか、ましてやx86 Windowsを実行できるなどは、まだです。
Linuxではなくて、Arm Windowsの中でx86のWindowsアプリを実行する場合には、引き続きMicrosoftのツールを使うことになります。

Rosetta 2のx86エミュレーションはApple Siliconの非公開機能を使用しているのでとても高速に動作します。
また、現状のmacOSの仮想化機能では、仮想OSの中で仮想化機能を使用すること（Nested Virtualization）はまだできません。
今後も徐々にRosetta 2やVirtulization Frameworkの適用範囲が広がっていってほしいと願います。

 

[2024-06-13] x86バイナリのコンテナもそのまま実行できるような環境が整備されてきました。
Docker DesktopやLimaのコンテナ実行環境で、直接Rosetta 2を利用するための 「Linux内でmacOSが提供するツールのおまじないの設定」が適用されるようになったようです。

macOSはLinuxそのものではないので、Docker DesktopやLimaはコンテナ実行マシーンを作成し、リモート環境としてコマンド接続してコンテナを実行するひつようがあります。
dockerコマンドだと、環境変数 DOCKER_HOST 指定、または .docker/config.json の Host 指定、あるいは context での指定、あるいは廃止になった以前の機能なら docker remote xxx をしているのと同じですね。
もっとシンプルなpodmanコマンドなら --remote と --connection の指定をしているのと同じです。

iPad Pro専用のiPadProOSがmacOSと共通化すればよいはず

Apple Siliconへの移行の仕上げの年のWWDC22開催までいよいよ1週間を切りました（キーノートのページ、WWDC22の全体目次ページ）。

前回の書き込みで指摘したように、Apple Silicon M1になったiPad Proは、処理性能面では完全にMacBook Airと同じものと言えます。

iPadに対してiPad Proのプレミアを付けて、iPadOSから派生してiPadProOSだけをmacOSと統合すればよいのです。
あるいは、むしろ逆にmacOSにiPadOSのタブレット由来機能を統合して、MacBook AirとiPad Proを共通化すればよいのです。

MacBook Airのディスプレイ部分とボトムパーツが分離できるようにして、あるいはiPadにフロ－ティングMagic Keyboardを付けた状態がMacBook Airみなしの状態になって、分離した状態では純粋はiPad Proタブレットモードとしての利用状態になり、一体化した時または外部ディスプレイとキーボードを接続した時にはmacOSモードでマルチウィンドウの動作になる、という仕組みです。

このiPad ProとMacBook Airのハイブリッドマシンは、あえて安価にしなくてもよいので、是非とも実現して欲しいものです。
iPad ProでもMacでもない、Apple Siliconによって生み出された新たなカテゴリの製品としてでも良いかもしれません。

さらに、iPad miniサイズやiPhone Pro Maxサイズで、ポケットに入るMacというものもとてもあこがれます。
これ、最高にわくわくしてしまいますね。

iPad ProのmacOSモードは永遠の夢物語か

MacRumorsの記事Apple Patent Suggests Future iPad Could Transform Into macOS-Like Experience When Attached to a Keyboardから

Apple Siliconの登場後、とうとうiPad ProとiPad AirにまでM1チップが搭載されました。

macOS側は、Mac CatalystによってiPadアプリとmacOSアプリのソースコードを共通化できるし、実行環境としてはiOSとiPadOS用のアプリをそのまま実行できるようになっています。

MacBookシリーズが電源と外部ディスプレイとキーボードを接続するとクラムシェルモードになるように、iPad Proもドッキングステーションに繋げたらmacOSモードになったら、とてもスムーズですよね。
これ、見ようによってはSurface Proと同じなのですが、タブレットとしてはiPadOSの方が断然使いやすいので、別物として忘れてよいと思います。

以前のわたしの書き込みでも、MacBook Air（あるいは12インチMacBookの復活版）の新筐体デザインとして、ディスプレイ側にロジックボードを組み込む方式を妄想しました。
そもそも、すでにMacBook AirとiPad Proのロジックボードはほとんど同じサイズなのだし、どちらもファンレス、CPU＋メインメモリも共通、SSDストレージオプションも全く品揃えです。

現在のMacBookシリーズで一番嫌いな点は、ディスプレイを最大限開いた時の角度が少なすぎて、とうてい水平にならない点です。
このせいで、外部ディスプレイを接続する時に内蔵ディスプレイがどうしても邪魔をしてしまうので、せっかくのとても使いやすいキーボードとトラックパッドを使うのを泣く泣くあきらめて、外部キーボードと外部トラックパッドで使わざるを得ないことになります。
外部ディスプレイを接続してクラムシェルモードにしてしまうと、せっかくの良質の内蔵のディスプレイ、キーボード、トラックパッドがすべて無駄になってしまいます。
iPad ProにキーボードをつないでmacOSモードで使えるようになるのであれば、一組のキーボードとトラックパッドだけを所有していればよいことになるし、iPad本体もセカンドディスプレイあるいは超大型のタッチバーあるいはペン入力デバイスとしてそのまま活用出来て無駄がありません。

iPadOSにも、マルチウィンドウ操作用の3つのドットが画面上部に出るようになって、もうゴテゴテしてきています。
この際ですから、macOSと共通化してしまった方がすっきりしそうに思います。