もうdeprecatedとなったSceneKit。今さら使う人もあまりいないと思うが、もし困っている人がいたら。ちなみにタイトルのとおり解決はしない。
let material = SCNMaterial() material.diffuse.contents = <なにがしかの画像形式（MTLTexture / UIImage 等）>
みたいな感じで作ったマテリアル。破棄しようがcontentsにnilを設定しようが一度設定した画像のテクスチャサイズでメモリがしっかりリークする。今のところ回避方法を見つけられていない。知っている人がいたら教えてほしい。
Sendable適合のためにclosureをOSAllocatedUnfairLockで保護することを考える。大体用途的にhandlerということでoptionalにしたい。
final class Po: Sendable { let handler: OSAllocatedUnfairLock<(@Sendable (Po.Result) -> ())?> = .init(initialState: nil) func setHandler(_ handler: (@Sendable (Po.Result) -> ())?) { self.handler.withLock { $0 = handler } } func call(with value: String) { let handler = handler.withLock { return $0 } handler?(.init(value: value)) } struct Result { let value: String } }
これは簡単すぎるコードで再現確認もとってないけど、だいたいこういう状況でhandlerを呼んだらstack overflow（EXC_BAD_ACCESS code=2）した。なぜ？
call stackの状況をプリントしてみる。
for symbol in Thread.callStackSymbols { print(symbol) }
結果がこう。
1 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 2 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 3 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 4 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 5 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 6 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 7 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 8 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 9 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 10 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 11 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 12 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 13 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 14 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 15 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 16 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 17 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 18 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 19 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 20 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 21 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 22 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 23 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 24 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 25 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 26 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 27 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 28 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 29 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 30 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 31 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 32 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 33 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 34 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 35 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 36 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 37 Example1Event.debug.dylib 0x0000000103f80ec0 $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR + 24 38 Example1Event.debug.dylib 0x0000000103f80e98 $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR + 36 39 Example1Event.debug.dylib 0x0000000103f82878 $s12Example1Core13CameraCaptureC13captureOutput_03didF04fromySo09AVCaptureF0C_So17CMSampleBufferRefaSo0I10ConnectionCtF + 636 40 Example1Event.debug.dylib 0x0000000103f83018 $s12Example1Core13CameraCaptureC13captureOutput_03didF04fromySo09AVCaptureF0C_So17CMSampleBufferRefaSo0I10ConnectionCtFTo + 116 41 AVFCapture 0x00000001a9e96fac 31134C66-3B30-3B0E-B11A-00CEFB451A52 + 163756 42 AVFCapture 0x00000001a9ebad48 31134C66-3B30-3B0E-B11A-00CEFB451A52 + 310600 43 CMCapture 0x00000001ad70b3a0 E68AFBBE-7145-38E8-B796-F5399CE474DB + 844704 44 CMCapture 0x00000001ad70b010 E68AFBBE-7145-38E8-B796-F5399CE474DB + 843792 45 libdispatch.dylib 0x0000000102f6e7bc _dispatch_client_callout + 20 46 libdispatch.dylib 0x0000000102f718e0 _dispatch_continuation_pop + 676 47 libdispatch.dylib 0x0000000102f88cc8 _dispatch_source_latch_and_call + 480 48 libdispatch.dylib 0x0000000102f87718 _dispatch_source_invoke + 860 49 libdispatch.dylib 0x0000000102f764a4 _dispatch_lane_serial_drain + 376 50 libdispatch.dylib 0x0000000102f77408 _dispatch_lane_invoke + 408 51 libdispatch.dylib 0x0000000102f84404 _dispatch_root_queue_drain_deferred_wlh + 328 52 libdispatch.dylib 0x0000000102f83a38 _dispatch_workloop_worker_thread + 444 53 libsystem_pthread.dylib 0x00000001e9804934 _pthread_wqthread + 288 54 libsystem_pthread.dylib 0x00000001e98010cc start_wqthread + 8
終わってるcall stack。2つの再帰してる呼び出しをdemangleしてみる。
~ swift demangle '$s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR' $s12Example1Core10VideoFrameCytIeghnr_ACIeghg_TR ---> reabstraction thunk helper from @escaping @callee_guaranteed @Sendable (@in_guaranteed Example1Core.VideoFrame) -> (@out ()) to @escaping @callee_guaranteed @Sendable (@guaranteed Example1Core.VideoFrame) -> () ~ swift demangle '$s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR' $s12Example1Core10VideoFrameCIeghg_ACytIeghnr_TR ---> reabstraction thunk helper from @escaping @callee_guaranteed @Sendable (@guaranteed Example1Core.VideoFrame) -> () to @escaping @callee_guaranteed @Sendable (@in_guaranteed Example1Core.VideoFrame) -> (@out ())
取り出して差分強調
なんか知らない reabstraction thunk helper なるものが作られて呼ばれている上に、それが無限に相互に変換し合っている。なんでこんな事が起こっているか厳密には理解していないので言及は避けるが、OSAllocatedUnfairLockに型パラメータとして渡る型、setterで受け取る型、利用側で取り出す型それぞれについてシグネチャは同じだがコンパイラから見ると差分があるらしくこの変換が自動生成されるっぽい。
取り急ぎ対策としてはOSAllocatedUnfairLockにわたす際に一段型を挟んで型のブレを防ぐ。
struct HandlerBox<Handler: Sendable>: Sendable {
let handler: Handler
public init(handler: Handler) {
self.handler = handler
}
}
全く意味のなさそうな型だが
final class Po: Sendable {
let handler: OSAllocatedUnfairLock<HandlerBox<(@Sendable (Po.Result) -> ())>?> = .init(initialState: nil)
func setHandler(_ handler: (@Sendable (Po.Result) -> ())?) {
self.handler.withLock { $0 = handler.map { .init(handler: $0) }}
}
func call(with value: String) {
let box = handler.withLock { return $0 }
box?.handler(.init(value: value))
}
struct Result {
let value: String
}
}
にすると上記のstack traceの再帰呼び出しは解消された。ふわっとした記事だけどハマる人（自分）のために念の為。
let rotation = CABasicAnimation(keyPath: "transform.rotation") rotation.fromValue = 0.0 rotation.toValue = Double.pi * 2 rotation.duration = 1.0 rotation.repeatCount = .infinity rotation.timingFunction = CAMediaTimingFunction(name: .easeInEaseOut) rotation.isRemovedOnCompletion = false
こんな感じの無限ループ CAAnimation を設定するときに isRemovedOnCompletion を設定しないと、バックグラウンドから復帰したときにアニメーションが再生されなかったり、 removeAllAnimations() でもアニメが停止できなかったりする。本当にハマるし困る。
遅ればせながら PREDUCTS さん主催の WORK TYPES を見に行ってきました。
WORK TYPES は、モジュール式でカスタマイズ可能な電動昇降デスクをつくっている PREDUCTS さんが「いい仕事を生む、道具展」をテーマに PREDUCTS DESK と様々なブランドの仕事道具の組み合わせを提案している展示会です。
PREDUCTS, VIE, Japan Sauna, Bambu Lab, Herman Miller, WORK LOUDER™, HHKB, teenage engineering, Wacom, Docket Store, TourBox, Native Instruments, EVE Audio (順不同・敬称略) などオタク好みなブランドが勢揃いで、これは行かざるを得ない、ということで行ってきました。
乃木坂駅を上がってすぐのところにある New Stand Tokyo Gallery で 6/2(日) まで、木金土日曜日の 12:00 〜 18:00 で開催されています。つまり残すところ 5/30 (木)、5/31 (金)、6/1 (土)、6/2 (日) の 4 日間の開催です。
PREDUCTS DESK は昇降テーブルにありがちな「机の天面と床においたデバイスの相対距離が変わってしまう」という問題を「じゃあ PC やゲームコンソール自体を机の天板に固定してやるよ」という 力技 エレガントな手法で解決しています。teenage engineering のオレンジの PC ケースがおしゃれ。
みんな大好き TourBox や HHKB ももちろん展示されていました。
Wacom の新型 Cintiq Pro と専用スタンド。専用スタンドだけで 8 万円程度する高級品だけど質感抜群でした。かっこいい。
TYPE CRAFT と名付けられたデスクではディスプレイアームによって 2 画面がセットで吊られていたり、私も使っている Herman Miller の Sayl Chair や HHKB Studio、Wacom の新型 OLED タブレット Movink、lofree のマウス、Bambu Lab A1 などが展示されていました。
元気に動く Bambu Lab A1。
ディスプレイアームは後ろで 2 画面が固定されていました。ハンドルも付いていて 2 画面同時に動かせるのが便利そう。
Wacom 初の OLED タブレット Movink は信じられないぐらい薄くて軽くてよかったです。しかも意外と安い… (118,800 円)。OLED らしく発色もよいけれど、解像度が Full HD しかなく、OLED 特有の sub pixel 配置によるドット間のボケ？違和感？が若干気になるところ… でもだいぶ欲しい感じでした。
オーディオゾーンでは teenage engineering のかっこいいデバイスや
WORK LOUDER のキーボードが展示されていました。
他におもしろかった展示といえば、Japan Sauna さんの自宅用サウナがおもしろかったです。従来モデルと異なり使わないときは扉を開けておけばソファとしても使えるんだとか。ちょっといいなと思ってしまった。
という感じで WORK TYPES、あまりにもオタク好みな展示の数々でした。PREDUCTS DESK についても昇降がスムーズでオプションのモジュール類も勘所を押さえたラインナップになっていてよかったです。
会期は残り短いですが、現在は遊舎工房さんも出展されているということなのでぜひ今週末遊びに行ってみてください。入場無料・予約不要です。
この記事は キーボード #1 Advent Calendar 2023 - Adventar 2023https://adventar.org/calendars/8789 23 日目の記事です。
22 日は ai03 さんの Altair (-X) の裏話 | Notion 、24 日は m.ki さんの 36キーで事足りますか（その後） #自作キーボード - Qiita でした。
まず簡単に告知です。コミケ C103 2 日目の 12/31 (日) 東 U30b にサークル「kabesa*」として出展します。
AI イラスト生成によるゆっくり形式の解説コンテンツとそれをつくるためのアダプター学習の話やモノクロフィルム現像写真集、短編小説、マンガ等引き続きざっくばらんな内容になっています。私は編集・デザインを担当しましたが今回は記事なしです…
作者: azami_86e40
予価: 1 部 300 円
作者コメント: SIGMA fpのマルチアスペクトから21:9を選択し、掛け軸や栞に見立てて楽しもうというものの一環です。それぞれの写真は、切り出して文庫本用の栞として使うことができます！
作者: タイビィ
予価: 1 部 200 円
本誌上で講評を受けている原作マンガです。
ここからが本題。
概ね キーボードの内部マウント方式一覧 - Self-Made Keyboards in Japan の簡単な解説・考察です。
最近の打鍵感の注目点、特に今回注目するマウントプレート・ケースについては「柔らかさ」「均一性」が 2 大トピックであると思います。そもそも「柔らかさ」が重要なのかどうか等の議論は一旦後半に置いておいて、この 2 つのトピックについてどのようなアプローチがありうるのか、また最新の事情はどうなのかについて見てみます。
まず「柔らかさ」に関して導入され現在も強い人気を誇っているマウント方式であるガスケットマウントやリーフスプリングマウントについて、その物理的特性を考えてみます。
上記の写真はガスケットマウントのはしりであり比較的低価格で日本でも人気を博した Polaris のガスケットマウント部分の写真です。キースイッチを支えるマウントプレートをケースに直接固定するのではなくクッション性のあるスポンジ状のクッション材によって挟み込むようにして固定することで、見ての通り柔らかな打鍵感を実現しようという設計です。
同様にこのクッション材を板バネに変更したのがリーフスプリングマウントです。名前のとおりですね。
いずれのマウント方法も底打ち時にマウントプレートが衝撃を吸収するように動くことで「柔らかさ」を実現しています。キーボードの宣伝としてわざわざキースイッチを強く押し込んでキースイッチが沈む様子を動画に撮るなど、マーケティング上のバズワード的な要素にすらなっています。
では、ガスケットマウント・リーフマウントは実際底打ち時にどのように振る舞うでしょうか？
基本的には lunar0 さんの以下 post の内容です。
https://twitter.com/lunar0/status/1526080045097267200?t=V1-wzSWO3W11uaGIGAhEyA
ガスケットマウントを側面からの断面の 2 次元で考えます。マウントプレートは一旦剛体として歪まないものとします。「柔らかさ」は実質的にばね定数であると考えて、この構造の位置ごとのばね定数を求めてみましょう。
上に想定する環境を図示しました。マウントプレートのある位置 に力
を加えているとします。それぞれのクッションやバネの反発力が
、
です。
ここでそれぞれのクッションについて独立に考えることにして下図のように片方を固定して考えます。
ここでモーメントの釣り合い (テコの原理と捉えてもよい) から
ここで変位量を とすると、ばね定数は
なので
以上の関係から
これを右側を固定した場合も同様に考えて、左端を固定した場合の位置 におけるばね定数を
、右端を固定した場合の位置
におけるばね定数を
、どちらのクッションのばね定数も等しく
とすると
ここで位置 における変位
を考えると、それぞれ左端・右端を固定した場合のばね定数
、
を用いて
ここから位置 におけるばね定数
が
となり、位置 におけるばね定数
が
の関数であることが示されました。
両端のガスケットのばね定数 に対して、中心部ではばね定数が 2 倍になっている = 2 倍硬く(？) なっていることがわかります。なんとガスケットマウントはそのまま使うと「均一性」を損なってしまうのです。また周辺部のほうが柔らかいというのは人によっては直観に反するのではないでしょうか？
上記のようにガスケットマウントは「柔らかさ」は導入できるものの打鍵感の不均一性も同時に導入してしまうということがわかりました。
では、ガスケットマウント・リーフスプリングマウントで損なわれた「均一性」を回復するにはどうしたらいいでしょうか？
上記の議論では簡単のためにマウントプレートを剛体として扱いました。ですが現実的には皆さん御存知の通りマウントプレートは多少柔らかくしなります。そしてこのしなりによる変位は直観どおりに固定点から遠いほど大きくなります。すなわち中央ほどやわらかくなります。
ここでわかる通り、ガスケットマウント・リーフスプリングマウントはそのまま使うと中心部が固くなってしましますが、マウントプレートは逆に中心ほど柔らかくなるので、これらを組み合わせれば均一性を回復できそうです。
おそらくこの問題と解決法にいち早く気づいていたのが、ガスケットマウント・リーフスプリングマウントを導入しカスタムキーボードに「柔らかい打鍵感」という観念を与え、マウントプレートにフレックスカットも同時に導入した、IRON シリーズのデザイナ「Smith and Rune」だと思われます。
IRON165 は 2019 年に GB が行われた、リーフスプリングマウントを採用した最古参と思われるキーボードです。この geekhack の GB ページに Optimized Plate, the Process, and FEA analysis という章があり、ここで有限要素法によるスイッチ押下時のマウントプレートの場所ごとの変位量解析のレポートが含まれています。
当時は「オーバーなアプローチだなぁ。しかも静的解析だとどの程度有効なんだろう？」などと愚かなことを思っていましたが、Smith and Rune はおそらくガスケット・リーフスプリングの導入で中心部が固くなる問題に気づき、同時にフレックスカットを導入することでマウントプレートを柔らかくし、全体として「柔らかく」かつ「均一性」のある打鍵感を目指していたことが想定されます。
その後、リーフスプリングマウントおよびガスケットマウントはあっという間にバズワード化しあらゆるキーボードがガスケットマウントと吸音フォームを採用したことは現状を見れば明らかですが、上で議論した通りガスケットマウント・リーフスプリングマウントおよびフレックスカットの導入は精緻な計画に基づく設計の調整が必要とされる複雑なプロセスであり、残念ながらこれらの設計要素を単に導入しただけでは打鍵感の向上に繋がるかどうかはなんとも言えなさそうです。
特に吸音フォームをマウントプレートと PCB の間にテンションを掛けて詰める設計などは、マウントプレートの柔軟性を損ない、ガスケットマウントの打鍵感の不均一性を強調してしまうおそれがあります。同様に一時期 Mode Designs が採用し、現在は採用されていない Stack Mount もマウントプレートの柔軟性を損なう可能性が高く、計算上ガスケットマウント以上に中央が硬くなってしまいます。面で支えるほうが均一になりそうなのに意外ですよね。
実際このような設計の難しさからか、最新のカスタムキーボードのトレンドは「トップマウント回帰」「脱フレックスカット」です。大手メーカーでなく、趣味としてカスタムキーボードを追求している設計者および購入者たちは、ガスケットマウント・リーフスプリングマウント等の柔軟な機構が、設計に過度の複雑性をもたらしていると考え始めている可能性があります。
個人的な反省なのですが、今年 無線キーボードランキング 打ち心地のとりこになる名機10選 - 日本経済新聞 にレビュワーとして参加させていただいた際、Logicool や FILCO、REALFORCE や HHKB に混じって Keychron 製のキーボードが複数ノミネートされていました。Keychron といえば皆さんご存知かと思いますが、新進気鋭のメカニカルキーボードメーカーで、最近は Keychron Q シリーズといういわゆる自作キーボード / カスタムキーボード的な製品を次々とリリースしています。
Keychron Q シリーズの基本的な設計として
という、モダンなカスタムキーボードの要素てんこ盛りという感じです。恥ずかしながら Keychron Q シリーズについて私は今まで触る機会がなく、なんとなく「これだけモダンなカスタムキーボードの設計を取り入れてるから打鍵感はそれなりにいいだろうな」と思っていました。
そんな Keychron Q シリーズが上記品評ランキングにノミネートされていたため、これはさすがに Keychron が勝ってしまうだろうなぁという予断を持っていたのですが、実際に品評会でそれぞれのキーボードを触りそれなりの文章量を入力してみた結果、個人的には Keychron Q シリーズのキーボードよりも「FILCO Majestouch Convertible 3」等の歴史あるメーカーによるキーボードの方が打鍵感がよく感じました。もちろん打鍵音等に関しては Majestouch Convertible 3 はバネ鳴りも筐体の金属音の残響も大きく、モダンなカスタムキーボードの観点からすれば厳しい評価をせざるを得ないのですが、それでもなお Majestouch Convertible 3 の方が個人的には心地よく打鍵できたんですよね (平等のために書くと Keychron Q シリーズも思ったよりは打鍵音もよくなかった)。
理由が語れるほど長く触って比較することもできなかったのでこれ以上の詳細については踏み入りませんが、この一件に関しては、再三「キーボードは触ってみないとわからない」と自ら言っていたにも関わらず、設計の情報から勝手に打鍵感を予想してしまっていたことをいたく恥じ入りました。同時に歴史あるメーカーの設計ノウハウの凄みを身をもって感じることができました。具体的な違いは言語化できていないものの、キーキャップの仕上げや材質、キーボードのチルト角、筐体の剛性、今思えば打鍵感の均一性など、微妙な組み合わせによってきちんと気持ちよい打鍵感が研究されているのだなと感心しました。
最近では HHKB Studio の内部構造が特に吸音フォーム等もなく非常にシンプルであるということも話題になりましたが、HHKB Studio はキースイッチとケース・マウントプレート、キーキャップ等の総合的な設計によってまるで静電容量無接点スイッチの HHKB Professional シリーズを思わせる、見方によってはより高品質の打鍵音と打鍵感を実現していました。それで十分素晴らしいですし、設計要素は手段であって目的ではないということは肝に銘じておきたいところです。ほしいのは「よいキーボード」であって、ガスケットマウントや吸音フォームではなかったはずです。
このような貴重な機会に恵まれなければ、某ラーメン評論家の言う通り「情報を食べて」しまっていたと反省しています。
www.youtube.com 反省を促す教訓動画
ガスケットマウント・リーフスプリングマウント、フレックスカット等柔らかいマウントプレートの組み合わせの設計が難しいということはこうしてよーくわかりました。ただ問題点だけ指摘して投げっぱなしというのもアレなので現在これを改善できる設計ができないか検討中です。
上記の柔軟性の導入に対する不均一性付随の問題の肝は、ばね定数の導出でも用いた回転方向モーメントの存在です。マウントプレートが押下に合わせて回転してしまうことが問題なのです。すなわち マウントプレートが常に回転せず平行に移動する 限り、マウントを柔らかくしても打鍵の均一性を犠牲にせずにすみます。そしてこの平行移動機構、キーボードを触っている人にとっては非常に馴染み深いもののはずです。そうです キースイッチ です。Cherry MX スタイルのキースイッチや静電容量無接点スイッチ、背の高いメンブレンスイッチはプラスチックの摺動レールによってスイッチの平行移動を実現しています。最近のメカニカルキースイッチはこのレールの精度を高めてキースイッチの軸がぐらつかない = 回転しないように血道を上げているほどです。なんと正解はめちゃくちゃ近くにあったというわけです。
現在はこの理論が実用的であるかを確認するために設計を始めています。来年 2024 年 3 月 2 日 (土) に開催のキーボードマーケット トーキョー に向けてこの機構を搭載したキーボードを発表・発売できればと考えています。遅すぎると言われたらそれまでなのですが、努力してみようと思います。
www.itmedia.co.jp biacco42.hatenablog.com keeb-market.jp
もう少しアウトプットしたいなぁ…
ついに HHKB Studio が発表・発売されました。
※発売直後に売り切れてしまっていましたが、今日 10/31 に再入荷されるようです。
※10/31 の販売も即完売になってしまったようです… 次回入荷は 11 月中頃とのこと。
ポインティングスティックとジェスチャーパッドの追加と、なんと言っても HHKB の名を冠しながらメカニカルキースイッチを採用するなど、大きな変化に興奮と動揺があったことは発表後の各種 SNS の反応からも窺えます。
実は HHKB Studio にはキーボードニュース の ぺかそ @Pekaso とともに開発の後半 (最終製品に近い検証モデルはすでに作られているぐらい) の段階からおよそ 1.5 年に渡って「後期アセスメント」に関わってきた経緯があります。また、HHKB エヴァンジェリストとしてここ 2 週間ほど最終製品を先行して使ってきました。
ですので、本レビューでは HHKB Studio の基本的な部分の紹介に関しては簡単な説明に留め、上記のような HHKB Studio の大きな変化の部分に焦点を当て、このキーボードがどうしてこのようなモデルになったのか、そして「HHKB としてどうなのか」について、スペックではなく実際の使用感を中心にレビューしてみようと思います。
基本的なところは プレスリリース にあるので、その中の注目ポイントについてだけ簡単に紹介します。
HHKB Studio は 10/25 に発表・発売となった HHKB の 新ラインナップ です。新たにメカニカルキースイッチを採用したほか、ポインティングスティック・ジェスチャーパッドなどが追加された意欲的なモデルになります。静電容量無接点スイッチ (以下東プレスイッチ) を採用した既存モデルは併売されるため、HHKB Professional 系が東プレスイッチ、HHKB Studio 系がメカニカルキースイッチ + ポインティングデバイスという棲み分けになりそうです。
また HHKB Professional HYBRID シリーズから強化されたキーボードカスタマイズのソフトウェアについても HHKB Studio では大幅に強化されています。カスタマイズできるレイヤーが 2 → 4 レイヤーに倍増したほか、新たに Profile という概念が追加されカスタマイズ内容が 4 つまで保存可能になり、その Profile をキーボード上から即時切り替えられるようになりました。これによって Windows / macOS 切り替えが簡単に行えるようになっている他、アプリごとにキーマップをカスタマイズするような使い方もできるようになっています。
機能・デバイス以外の点では、外観も大幅に刷新されました。従来モデルでは出っ張っていた電池ボックスが筐体内に格納されるようになったのもうれしいポイントです。
HHKB Studio は前述の通り HHKB の新ラインナップです。「最小の動きで、無限大の創造を」をキャッチコピーに、HHKB のコアであるコンパクトで合理的なキー配列を継承、HHKB らしい高品位な打鍵体験を提供する専用カスタムメカニカルスイッチを採用し、ポインティングスティック・ジェスチャーパッドを搭載することで GUI 環境での 統合された入力デバイス = 仕事場 (Studio) を提供するというコンセプトを持った製品になっています。
HHKB はもともと UNIX / CUI 環境でどんなマシンにも使えるポータブルでコンパクトで合理的配列のキーボードを作るプロジェクトであり、そういう意味で HHKB は文字入力に特化した環境でのプロの仕事場として愛されてきました。それから四半世紀ほどを経てコンピュータの利用シーンも大きく様変わりし多様なタスクが実行できるようになった今、どんなマシン、そしてどんなタスクにも使えるポータブルな入力デバイスとして、GUI 環境でのプロの仕事場として企画されたのが HHKB Studio と言えそうです。
そういった多様化したタスクに対応した仕事場 = Studio というコンセプトを実現するために、HHKB Studio ではカスタマイズ性に大きく舵を切った設計になっています。物議を醸しているメカニカルキースイッチの採用も、ソケット交換式 (ホットスワップ) で簡単に好みの互換キースイッチに差し替えてカスタマイズできるというところが大きな理由となっているようです。
HHKB User Meetup vol.7 での HHKB Studio 企画者の笠原さんの「HHKB Professional はこれが最高だからこれを使ってください ~(中略)~ HHKB Studio は自分の色に染めてください」 という発言や HHKB Professional HYBRID シリーズからより強化拡張されたキーマップ変更ツールからも、HHKB Professional シリーズに対して HHKB Studio が Studio というコンセプトを実現するためにカスタマイズ性を軸に据えて企画・設計された製品であることがわかります。
すなわち、HHKB Studio はそういった GUI 環境でどんなマシン・どんなタスクにも使えるポータブルな入力デバイスを求める人たちに向けて開発された新しい HHKB ということになりそうです。
そのため、既存の文字中心の利用を想定した東プレスイッチ採用の HHKB Professional シリーズは継続して販売されますし、HHKB Studio が HHKB Professional シリーズの後継機・上位機というわけでもありません。和田先生が求めた、長く使えるコンパクトで合理的なキーレイアウトのキーボードである HHKB Professional シリーズは、引き続き完成された理想形として提供されることになります。
ですから「東プレスイッチにあらずんば HHKB にあらず」という人や「HHKB の後継・上位機種が出たから買い換えよう」といった考えの人が HHKB Studio を購入すると納得できない可能性があります。
逆に「高品位で完成済みのリニアスイッチな HHKB が欲しかった」「HHKB Studio の統合されたインプット環境というコンセプトが自分にフィットする」「HHKB をより深くカスタマイズしたかった」といった方にはおすすめできる製品になっています。
ここからは HHKB Studio の新規要素であるメカニカルキースイッチ、ポインティングスティック・マウスボタン、ジェスチャーパッドについて先行体験 2 週間での使用感をお伝えします。
HHKB Studio では東プレスイッチを採用した既存の HHKB Professional シリーズとは異なり、Kailh 製の PFU カスタムスイッチ (以下 HHKB Studio スイッチ) が採用されています。東プレスイッチが支持されているポイントの一つがその高い耐久性ですが、PFU さんもこの点にはこだわっており東プレスイッチ採用 HHKB と同様の耐久性テストをこのカスタムスイッチでも実施し、少なくとも東プレスイッチ (3000 万回耐久) 以上の耐久性があることを確認したとのことでした。
HHKB Studio スイッチの概観としては、リニアスイッチのためタクタイル感のある東プレスイッチと打鍵感は異なりますが、スイッチだけでなく筐体やキーキャップまで含めたチューニングによるものか打鍵音や底打ちの感触が東プレスイッチの HHKB Professional Type-S シリーズに近く、不思議とたしかにこれは「HHKB」っぽいなというおもしろい感覚があります。
HHKB Studio スイッチは東プレスイッチに近いと同時に最近のメカニカルスイッチらしく軸のブレは Type-S スイッチと比べて大幅に小さく、潤滑も適度で軽いスレ感はあるもののなめらかで、安定感があり上質です。ただタクタイル感はないためやはり東プレスイッチとはどうしても打鍵感は異なります。打鍵音は HHKB Studio のほうが HHKB Professional HYBRID Type-S よりはだいぶ静かですが、心地よくはっきりした低音寄りのサウンドプロファイルで打鍵のたのしさは負けず劣らずといった印象です。このあたりは究極的には好みだと思うので、ぜひ触って判断してみてください。
また、スイッチの好みに関しては HHKB Studio は後からスイッチを差し替えることができるのでそういった面でも融通がきくのが美点です。メカニカルではありますがタクタイル感のあるキースイッチに差し替えてもいいでしょう。HHKB Studio で手に入らないのは東プレスイッチだけですね…
HHKB の完全新規要素の一つがポインティングスティック・マウスボタンです。私はもともとトラックボーラーですが、ポインティングスティック素人の私でも数日で操作に慣れることができました。ただ他のキーボードのポインティングスティックを知らないので、あくまで「少なくとも私は簡単に操作できた」程度の感想と思ってください。
ポインティングスティックをしばらく利用した印象としては、基本的に問題ないレベルでは使えるものの私が普段使いしているトラックボールやトラックパッドに比べると操作精度に関してはどうしても一段落ちる印象です。マウス・トラックパッド・トラックボールが直接的に位置情報を入力するのに対し、ポインティングスティックは速度 (位置の微分) を入力するデバイスであるため相対的にはどうしても制御は難しいです。
HHKB Studio のデモ動画に出てきているような Adobe Illustrator や Adobe After Effects 等の比較的細かなマウスポインタ制御を求められるツールを実際に HHKB Studio を使って 2 週間ほどヘビーに操作してみましたが、操作精度の不足によるストレスや作業速度低下はさすがに否定できません。これは上記のデモ動画が示すようなユースケースに関して残念ながらネガティブな要素です。ポインティングスティックで動画や画像編集を行うことは可能ですが、最高のデバイスになるのは難しいかもしれません。慣れによるところも大きいとは思いますが…
逆に既存の HHKB ユーザーとして多いと思われるプログラマや文筆家、編集者などの人にとってはキーボードから手を離さず GUI を簡単に操作できて意外にも親和性が高いと感じました。あまり高精度なマウスポインタ操作を要求されず GUI 上のボタンやテキストを操作する程度であればストレスなく使えるため、上記業種等に加えてオフィス系ソフトウェアの利用にも適しているかもしれません。
実際のところキーボードから手を離さずに操作できる没入感は圧倒的で、上に書いたように Adobe 製品のような画像編集等の操作に多少の不満はあるものの、結局この没入感のある操作の気持ちよさ負けてここ 2 週間は HHKB Studio のポインティングスティックでの操作に統一してトラックボールを撤去してしまいました。
個人的にはポインティングスティックの感度を 3 にして、OS 側で速度を微調整すると操作感がよく感じました。このあたりもファームウェアアップデートで洗練されていってほしいポイントですね。
ポインティングスティックの追加に伴ってマウスボタンも追加されました。スイッチには Gateron のロープロファイルスイッチが採用されています。キーボード部分とマウスボタンでわざわざ異なるキースイッチメーカーを選んだ PFU さんこだわりのポイントです。
実際、操作感やデバイスとしての枯れ具合から後期アセスメントではマウスやトラックボールで一般的に用いられるマイクロスイッチの採用を提案したこともありましたが「キーボード本体のスイッチと耐久性に差があり、マウスボタン側が先に壊れてしまう」という理由で却下されるなどかなりこだわりを持って選択されているようでした。
ただ、後期アセスメントではこのロープロファイルメカニカルキースイッチの選択によって大揉めすることになります。
HHKB Studio ではマウスボタンがケースのフチとツライチであわせられた、かなり意匠性の高い設計がされています。それ自体は素晴らしいことなのですが、初期の試作モデルではキーキャップのスイッチへの嵌合が甘かったのかその時点で選定されているキースイッチの精度がよくなかったのかこのツライチのデザインが完全に裏目に出ており、マウスボタンの隙間が不均一だったり平行が出ていなかったりと組み立て精度の不足がガチャガチャした見た目としてめちゃくちゃに悪目立ちしてしまっていました。
また、キーボード部分の打鍵感が前述の通り非常になめらかで洗練され、打鍵音がコントロールされているのに対し、マウスボタンの打鍵感・打鍵音ともにパカパカとしたかなり安っぽいものになってしまっていたため、一時は「このクオリティではちょっと OK は出せないですね…」とだいぶ暗雲垂れ込めたりもしていました。
そういった中で、前述のマイクロスイッチの採用、いっそのこと静電容量タッチパネルに変更、キースイッチをより精度の高いものに選定やり直し、マウスボタンのキーキャップのスカートを伸ばす・肉厚にするなどの構造的変更、マウスボタンのキーキャップの裏にフォームを貼り付ける… などなど様々な提案を PFU の担当者の方々と頭を突き合わせて、それこそ終電間際まで付き合ってもらいました。もちろん全てが採用されたわけではなく、PFU さんも高耐久のロープロファイルメカニカルスイッチは譲れないなど喧々諤々の議論がありましたが、その結果は発売された HHKB Studio を見ていただければと思います。
HHKB Studio の完全新規要素のもう一つがジェスチャーパッドと称する本体左右側面それぞれに 1 つずつ、本体前面のマウススイッチを挟んだ左右に 1 つずつ、合計 4 つ搭載されているアナログスライドパッドです。本体がチャコールグレーとマットシルバーの二色構成になっていますがこのデザインには意味があり、チャコールグレーの部分にのみジェスチャーパッドがあり、マットシルバー部分は単なるケースになっているので触れても反応しないようになっています。標準では左側にカーソルキー上下、手前左側にカーソルキー左右、右側にスクロール、手前右側にタスクスイッチャーが設定されています。
ジェスチャーパッドの検出精度に関してはもう少しなめらかな解像感がほしいものの、基本的にはきっちりと検出してくれる印象です。ただ現在のファームウェアの実装だと誤検出防止のためのタッチ開始時の入力を一定時間ブロックする処理が長く、しばらく反応しないなと思ったら突然スムーズに動き出すというやや違和感のある挙動になっており、これについてはファームウェアアップデート等で改善してほしいポイントです。
前述の操作精度はソフトウェア的に改善できそうなのですが、より根源的に気になるポイントはポインティングスティックとの相性の悪さです。前述した通りポインティングスティックは操作性こそ癖があるものの、キーボードのホームポジションから腕を大きく動かす必要がないシームレスな体験が非常に快適なのに対し、ジェスチャーパッドは手をホームポジションから離して大きく動かして操作する必要があり、ポインティングスティックのよい点と完全にバッティングしてしまっています。
これについては近年ブームとなっているキーボード搭載のロータリーエンコーダにも当てはまるため、私が思いついていないだけでホームポジションから手を移動してでも使う価値のあるユースケースが存在するのかもしれません。このあたりは PFU さんからも「画像編集ソフトのブラシサイズ変更に便利！」等の具体的な使い道をもっと提案、アピールしていただけるといいかもしれないな、とは感じています。
結論から言うと HHKB Studio はかなり HHKB なのではないかと思います。
HHKB Studio は挑戦的なモデルであり新規要素も多く、まだまだ荒削りな部分があることは否めません。その一方で「HHKB とはなにか？」という点について真剣に検討し、磨き上げられてきた設計製造技術とこだわりによって HHKB らしい非常に高品位な製品 に仕上げられています。
特にポインティングスティックとマウスボタンの統合は、コンパクトで合理的な HHKB 配列というコンセプトを守りつつ、この考えを時代に合わせて GUI にも拡張したと考えると非常に腑に落ちます。ただ同じものを作るのではなく、守るべき根幹を守りながら再解釈を行ったアップデートは衝撃的であると同時に実際に使ってみると納得感がありました。
議論を呼んだメカニカルキースイッチの採用についても「プロのための合理的なキー配列と心地よいキータッチ」という目的をブレさせず、東プレスイッチという手段にこだわらないで、実際に高品位な打鍵感を実現できた技術力には素直に感心しました。
もちろん最初でも述べた通り HHKB Studio は HHKB Professional の後継機でも上位機でもありません。そのため HHKB Professional シリーズをすでに持っている人が無理に乗り換える必要はないと感じますが、HHKB の名を冠したキーボードの最新作やポインティングデバイスの統合というコンセプトに惹かれる方にはぜひ触ってみてほしくはあります。
では、広くキーボードとしてみた場合の HHKB Studio はどうでしょうか？
あなたが本当によいキーボードがほしくて、かつ自作キーボードやカスタムキーボードのような電子工作や打鍵感向上のための試行錯誤に時間を溶かすことがしたくないのであれば、HHKB Studio は数少ない最高の選択肢の一つでしょう。
現状「購入して箱から出してすぐに使える」という完成品の範囲では、どれだけお金を積んでも HHKB Studio レベルによい打鍵感・打鍵音のキーボードを手に入れるのは容易ではありません。それこそライバルは東プレスイッチを採用した HHKB Professional シリーズや REALFORCE になってくると思われます。
HHKB Studio はたしかに絶対的な価格は非常に高価ですが、これだけの品質のキーボードが組み立て済みの完成品として、しかも安定した供給がある状態で販売され、アフターサポートも受けられると考えると十分現実的な価格と言える気がします。
あなたが自作キーボードやカスタムキーボードなど、電子工作や黒い画面を厭わず、その打鍵感を向上させるためにスイッチを全て剥がしてははめ直し、キースイッチを潤滑し、Tape Mod 等の効果を検証するべくキーボードを分解しては組み立てることに情熱が傾けられるだけの時間とお金があるのならもう少し選択肢は広がって、HHKB Studio はそれらの選択肢の中の一つになるかもしれません。
それなりのクオリティ以上のキーボードを作ろうと思うと結局 HHKB Studio ぐらいの金額はしてしまう気がしますが、自作やカスタムを考慮に入れると HHKB Studio のライバルはかなり多くなってくると思われます。それでもポインティングスティックのついたキーボードは珍しいのでポインティングスティックに目がないのならおすすめです。
一方で、あなたがちょっとよいレベルのキーボードを求めているのであれば HHKB Studio は少しばかり過剰かもしれません。HHKB Studio はマウスボタンの項でも書いた通り、若干偏執的ともとれるこだわりがところどころに見受けられるキーボードです。その細部にまで気を配るために HHKB Studio はそれなりに高いコストを強いられています。
打鍵感や打鍵音、バネ鳴りの一つまで、微に入り細を穿つこだわりがあるのであれば HHKB Studio の金額を払う価値は十分にあると思いますが、そうでなければ国内メーカーのメカニカルスイッチ採用キーボードや Keychron などの新興カスタムキーボードメーカーのキーボードを選んでみるのもいいかもしれません。もちろんお財布に余裕があればぜひ HHKB Studio のこだわりと良さを体験してみてほしいですが。
個人的には HHKB Studio のキーボードとしての立ち位置はこのような印象になっています。
いずれにしても HHKB Studio は HHKB 初代から実に 25 年以上ぶりの大変革モデルです。打鍵感に関してはぜひ毛嫌いせず、実際に体験してみてほしいと感じています。
HHKB Studio は各地にある HHKB タッチ&トライスポット で触ることができます。また、今週末 11/4 (土) に開催される 天下一キーボードわいわい会 vol.5 でも、PFU 協賛ブースにて HHKB Studio と HHKB Professional HYBRID の打ち比べ体験などができる予定とのことです。天キー vol.5 にいらっしゃる方はぜひ東プレスイッチ HHKB とメカニカルスイッチ HHKB を並べて触って比較してみてください。
HHKB Studio は 10/25 の発売直後に売り切れてしまっていましたが、本日 10/31 に再入荷されるようです。
次回入荷は 11 月中頃とのこと。間違いなく色々な意味でおもしろいキーボードなので、本当に触ってみてほしいです。
HHKB Studio は小売流通に乗っていないので家電量販店等の店頭では触れません。HHKB タッチ&トライスポット で触ることができるので、お近くのところにぜひ伺ってみてください。
この記事は HHKB Studio を使って書かれました。
この記事は ぺかそ 氏、サリチル酸 氏、モン𝕏オブファンク 氏、yohe 氏にレビューいただきました。本当にありがとうございました。
コミケ C102 2 日目の 8/13 (日) 西 "あ" 02a にサークル「kabesa*」として出展します。
技術とイラストのサークルとして第 2 号、「kabesa* vol.02」を発刊します。
二輪の魅力を写真で伝えます。二輪といってもバイクだけでなく自転車も出てきます。手が離せない二輪での撮影のお供「GoPro Hero 10」「DJI Osmo Action 3」の作例も載っています。
昨今話題の AI 生成イラスト。それを検出する「AI生成イラスト検出 AI」とその危険性などについて実践的検証を含めて議論します。マンガとテキストの混成です。
Lili58 作者の yuchi が、ChatGPT で VJ 映像素材を生成する事例を実践的に紹介します。実際に与えるプロンプトと生成されるコード、開発プロセスについて紹介しています。
ドーナツの穴を飼い始めてからというもの、気分が良い。 で始まる短編小説。SF 的・散文的作品です。
といった感じになっています。引き続き私 Biacco42 が編集・写真・デザインを担当させていただきました。前回 vol. 1 よりだいぶクオリティアップしています。 vol. 1 に引き続きごった煮感の強いおもしろい本になっていますので、ぜひお立ち寄りください。
既刊少部数・新刊ともに 1000 円での頒布になります。 コミケ C102 2 日目 8/13 (日) 西 "あ" 02a サークル kabesa* でお待ちしています！
キー部 5% に行ってきました。
共同主催のゆかりさんから開会挨拶。キー部はもともと天キーを再開するための試金石だったが、天キーが再開された今、キー部の位置づけを再検討してよりマニアックな・設計者や販売者向けのイベントとして特化していく方向性が案内されました。
共同主催のサリチル酸さんも ErgoArrows Pro を片手に。
ついに量産用の最終確認が完了したとのこと。今回はダブルショットの最終製品版キーキャップが初展示されていた。成形がめちゃくちゃにキレイだった！
キーボードのようにキーの入力を一旦電気的に検出してから電動ハンマーで文字をタイプする電子タイプライターというおもしろいものをアンドラさんが展示していた。
まさかのバックスペースもあり、バックスペースを押すと白いテープ？で文字の上からタイプすることで消すようになっていた。自動修正テープ的な。
磁力でスイッチの反発力と入力検出を同時に行う MagLev Switch の発表を @famichu さんがしていた。大型カットモデルは FFF 方式 3D プリンタで、実際に Cherry MX と互換のサイズのものは光造形方式の 3D プリンタで造形されていた。光造形で高精度な機械もの作るのすごい…。そして実際発表でも光造形の精度追い求めるとキツイ…
という話をされていた。
反発力が距離の 2 乗に反比例するので超強烈プログレッシブスプリングみたいになる。おもしろいが、強い反発力のある磁石は高いらしく…むずかしいね。とはいえ実際に動くモデルがあるのはすごかった。
Buckilng Spring 方式の伝説的キーボード。こんなのも触れるのすごい。
可動式パームレストの zumuya さんの新作。力強い。
public (i)mage さんのめちゃくちゃオシャレなキーボード。よすぎる。
Daily Craft Keyboard さん。
カスタムキーボーズ。
YMG WORKS さん。キーボードニュース 200 回記念キーキャップ！
3araht さんの楽器シリーズ。演奏してる人がいた！
You Tatekawa さんによる、世にも珍しいアルプススイッチのルブの実演発表。
ALPS スイッチのルブの様子が全世界にリアルタイムに発信される稀有な現場をみんなで目撃した。
ぴろりどん さんの 3D プリント立体キーボード SLIDE64 と CygSUS。SLIDE64 は以外にも手前側のキーが押しやすくてよかったものの結構癖があり、ぴろりどんさん自身も今は使っていないとのこと。これが初めての設計だったとか！？
CygSUS は打鍵音が非常によかったです。
機嫌を損ねたシェフさんのアクリルケースだけどウェイトがついててかなり重厚だったキーボード。
ぎーくらびっとさんのおレーザー加工がきれいな山田アリスとパズルみたいに接続できるスイッチ台。
takashicompany さんのテーブル。KEEB_PD を二連覇した Ergomirage や狭ピッチの miniDivide など Twitter でみたことのあるキーボードがたくさん。狭ピッチは本当に小さくてよかった。
homura さんの col staggered で列を移動できるおもしろいキーボード。
alg さんテーブル。フロッピーディスク型キーボードもありました。
orihikama さんの Hermit。中 2 列だけ斜めになった配列や左右接続ケーブルが特徴的…
いつも狂気の手作業で仕上げてくるジョンマイヤーさん。強烈な研磨の印象が強いけど、新作はめちゃくちゃ精緻な海底に沈んだ都市。
CRAB CRAFT さんのテーブル。アルチザンキーキャップもさることながらブランドデザインとか見せ方がキレイ。
オタク ブラックの CreatorPad。
techmech さんの OLSK60 と Boardwalk。Ortholinear かっこいいですね！オレンジのケースがマジでかっこいい。
policium さんテーブル。GRIN シリーズが並んでいる。GRIN One が打鍵音よくてよかった…
mikekoma さん、nana さん。アルミシャフトで左右を固定する機構が無骨い。
yohe さんの新作 Alic/Ja (アリシア)。修正用メモのホワイトがおしゃれでもはやこういうデザインっぽくてかっこいい。
Thinking Face キーキャップの荒涼さんの新作。ロブスターとオマール海老。右手と左手でハサミの大きさと形が違うとのこと！
今村勇輔さんの名前の通り親指シフトな ThumbShift v0.1。
みつきさんの glade60。Ortho 3 連！
ALPS スイッチのルブ実演発表をされていた縦川さんの展示。かなり個性的な 3D プリントキーボードを設計されていた。
MDA Future Suzuri のモンクスオブファンクさんの Aleth42 三兄弟。
最後には天キー vol.5 が 11/4 に六本木 DMM 本社で開催する予定であることや、9 月ぐらいにキー部 6% が開催されるかもしれないことが発表されて幕を閉じた。
いろいろなキーボードを見て設計している人とも話せてかなりコアだけどたのしいイベントでした！キー部に参加するならぜひ自分で設計したキーボード持っていきたいですね。
レポでした。
コミケ C101 2 日目の 12/31 (土) 西"せ " 05a にサークル「kabesa*」として出展します。
技術とイラストの本と題して「kabesa* vol.01」を発刊します。
内容としては
といった感じになっています。私 Biacco42 は編集・表紙イラスト線画・写真・デザインを担当しています。 ごった煮感の強いおもしろい本にはなったので、ぜひお立ち寄りください。
コミケ C101 12/31 (土) 西"せ " 05a でお待ちしています！
