2021年08月03日

【DvorakJ】パラメータの制御

以下のようなツイートを見かけたので。
https://mobile.twitter.com/minyu1/status/1419847645674180610
> @DvorakJとATOKを併用して新下駄配列を打ってると、この頃なぜか以下のような誤変換がよく発生する。
> コラムの⇒コラムンお
> 練習で⇒練習dえ
> 最後の一語は未変換状態となるので、おそらく「no+【スペース】」とすべきところを「n+【スペース】+o 」と処理されてしまっているものと予想。

多分、以下で対処できる。


原因は、打鍵速度が早すぎて、
DvorakJの処理が追いついてないことと推測。

n出力とo出力の間に、
スペース出力が追いついてしまったゆえに、
n、スペース、oの順で出力されてしまう。

AutoHotKey(DvorakJの記述言語)はマルチイベント前提で、
各キーの入力判定、各キーの処理が並列処理だから、
入力判定と処理が混ざることが時々ある。
打鍵速度が処理速度を超えてればね。

で、これを対処するには、
入力判定から処理を少し遅らせるといい。
受付から吐き出しまでミリ秒のラグを設けると、
受付→受付→受付→処理→処理→処理…
になる確率があがり、
意図通りになりやすい。



設定方法は、DvorakJの、

キーボード/入力全般/待機と遅延/
キーをを発行する際に待機させる時間

をいじるのみ。

僕は1でやってる。
ディレイをかけると全体にもったりするからね。
3とか5くらいでも限界かも。

10とか20入れれば確実だろうが、
それは快速な新下駄の特性が活かせないだろう。
このへんはお使いのPCで変わってくる。


キーボードをもっといいものにする、
という手もある。
キーボードは何ミリ秒おきに入力信号を検知して送るか、
というポーリングレート(サンプリングレートみたいなもの)があり、
高級なリアルフォースはそれが極めて短い。
データシートによれば1000Hzだから秒間1000回。
つまり1msに一回判定している。

自作キーボードが16ms程度、
つまり交流の60Hzって話をどこかで聞いたので、
リアルフォースすげえ、ってなったのを覚えている。

安物のキーボードだとその精度が荒く、
入力情報が渋滞しがちかもしれない。

あと単純に沢山アプリを立ち上げてると、
やはりDvorakJの性能は低下するね。
いらないやつは落とした方がいいだろう。


僕は何かを書くときは、
ウェブブラウザとDvorakJくらいしか立ち上げないので、
ほとんど遅延は起こらない。
あとWiFiの通信関係も切ったりするので、
そっちにCPUのリソースを取られないようにしている。


これで無理ならやまぶきR、紅皿を試すか、
1万払ってかえうちかなあ。
posted by おおおかとしひこ at 12:19| Comment(6) | カタナ式 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
> 最後の一語は未変換状態となるので、おそらく「no+【スペース】」とすべきところを「n+【スペース】+o 」と処理されてしまっているものと予想。

DvorakJから「no」と出力され切らないうちにスペースが押され、Dvorakがスペースを感知しないで素通り。「n+【スペース】+o 」となったと考えます。

対策にはSandSをオンにする方法も使えると思います。
Posted by なかやさとる at 2021年08月03日 21:24
>なかやさとるさん

>対策にはSandSをオンにする方法も使えると思います。

なるほど、そういう対策もあったか。
薙刀式でそれが発生しにくいのは、
僕がふつうにSandSを使ってるから説はあるかも。
Posted by おおおかとしひこ at 2021年08月03日 22:45
DvorakJが使っているA_TickCount(Windowsの標準タイマー)の精度は10ミリ秒または16ミリ秒です。

http://hp.vector.co.jp/authors/VA007219/rtc_pic.html

キーボードに、例えRealForceを使ったとしても、そのキーコード信号のタイミングをWindows標準タイマーで計測していると、10ミリ秒または16ミリ秒だけ、実際の時間とはずれる可能性があります。

これに対処するため、紅皿では高精度タイマーを呼び出しています。

DvorakJ のタイマーをWindowsの標準タイマーから、高精度タイマーに書き換えると、使用感が向上するかもしれません。
Posted by Ken'ichiro Ayaki at 2021年08月06日 00:35
>Ken'ichiro Ayakiさん

詳しい情報ありがとうございます。
まあ1ミリ秒単位ではないんだろうなあ、
と薄々思ってはいましたが。

紅皿のレスポンスがいい感じはそういうことだったんですねえ。
ガチで各エミュレータのそうしたスペック比べがあると、
「どのエミュレータを選ぶべきか?」の指標になるでしょうね。
新下駄は紅皿で、みたいなことになりそう。
Posted by おおおかとしひこ at 2021年08月06日 00:51
Ayakiさんに紹介された資料はとても参考になりました。

ところで自作キーボードは、16ミリ秒ごとの通信だったのは一昔前のコルネぐらいで、今ファームウェアを作れば8ミリ秒ごとが普通だと思います。
所有しているHHKBPro2もRealForce(旧型USB版)も8ミリ秒ごとの通信でした。

ノートパソコン内蔵や、PS/2接続のキーボードだともっと頻繁に通信できるものがあるようです。
例えば Panasonic CF-C2内蔵キーボードでは約6ミリ秒間に7キーを入力できました。
https://github.com/tor-nky/KeyTimingChecker

ですが、通信がいくら速くても押した順番を正確に伝えられなければ意味がなく、この点ではHHKBとRealForceだけが次第点です。
自作キーでASDFをどんな押し方をしてもASDFになったりしませんか?


配列エミュレータを作る上では、ディレイを使わない、スリープを一切使わない、が時間をなるべく正確に取得する方法のようですが、キーを出力することで0.5ミリ秒ほど狂ったり、まれにキーを取りこぼしたりするのが泣きどころです。
なので紅皿はとってもすごいことをやってますよね。

さて、薙刀式Autohotkeyなかや版はHachikuと名を変えコツコツ改良していましたが、いよいよ来るAutohotkeyの大規模更新や、Windows 11に対応困難なのでしばらく放置することにします。
Posted by なかやさとる at 2021年08月10日 20:58
>なかやさとるさん

へえ、自作キーボードでも8ミリ秒行けるのか。知りませんでした。
こうした限界性能というか、
そういうことを把握してないと、
エミュレータの設計は思わぬ穴があるんでしょうね。
ちょっとした処理がキー入力のトップスピードに負けるときに、
ややこしくなるのは想像がつきます。

紅皿は快適なんですけど、
今私家版を色々試すためにDvorakJを使い倒してます。
試行錯誤の回数回すにはちょうどいい。
(編集モードの改訂は、100バージョン以上あったりするので)

Win11とAutoHotKeyはどうなるか心配ですねえ。
でもデフォルトのqwertyには一生戻らないだろうなあ。
Posted by おおおかとしひこ at 2021年08月10日 23:57
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

※ブログオーナーが承認したコメントのみ表示されます。