twitterでアレコレやり取りしてきた上で、「タイパーさんと、配列屋との、考え方の差」について考えつつ、つらつらと囁いてきた……。
(2011年2月16日22:18:01追記)
下駄スレの527さんからご指摘を頂いたことに伴い、「文字キー同士同時打鍵法」関連の既言及点について、最後尾に追記しました。
要約すると『文字キー同士同時打鍵法は、逐次シフト化運用する代わりに、配列内の拡張定義を使って、タイプウェルで36.8秒を切る速度が出せるはず』って話です。
きちんと言及したつもりでいたのですが、結果として「読む方に伝わってなかった」ってのは失敗でした……申し訳ないです。
表題の件、延々と考えた上で、さっきtwitterで囁いてきた。
……で、同時打鍵系配列の欠点だと思ってたものがロジック欠点だッてこともわかったので、そっちについては親指系配列wikiで注記することにした。
タイプウェルで36.8秒を切る速度を目指さない限りは、やまぶきとかのデフォルトを使うほうが快適だと思う。それよりも速く打つなら、設定を変えて「前置シフトあり・シフト遅れ補償なし」にするといい計算になるので、その点だけ書いておくことに。
物理的動作の速さによって、どっちが快適＆文字入力上速いかは、たぶん違うんだと思う……ってことを、うまく表現できているかどうかは不安だけれど。
ここから、囁いてきた内容の元テキストコピペ。
高度競技タイピングで、逐次打鍵法(バス幅1ch)と2指同時打鍵法(バス幅2ch)のどっちが有利か……って聞かれたら、バス幅1chが有利だと思う。バス幅2chで安定度を見込むと「クロック数半分、データ量は倍」が必要だけれど、 2chに詰め込むのは無理があって、多ch化が必要な領域。
もっとも、やり方によっては、クロックタイミングを無視して、前からベタ詰めで1キーあたり1クロックで打つってゆー変則的な運用法もある……のだけれど、それをやるならそもそも同時打鍵ロジックをOFF(前置シフトモードで使う)にして、同配列を逐次打鍵法(バス幅1ch)として運用すべき話。
そういえば、もともと飛鳥カナ配列って、親指ひゅんQのバグを利用して開発が始まったんだよな……連続シフトのシフトキーは、同時打鍵じゃなく小指シフトキーの動作と同じになる環境で評価打鍵してたし。あれも、部分的に逐次打鍵法(バス幅 1ch)としてのシフトキー利用をしていたようなものか。
同期タイミング性を優先して「のんびり打鍵、しかし効率はよく」を目指すなら同時打鍵ロジックを使えばいいし、同期タイミング性を捨てて「とことん高速タイピング！」を目指すなら前置シフトロジックを使えば良いと思う。2006年5月から前置＋同時で運用してるけど、目的に応じて使い分けてるし。
配列を変えて指の痛みが無くなった！ってのは、(モノの置き場所が運動規制を引き起こすことによって生じる)配列を使っていたときの悪癖を一緒に捨てたから……ッて部分のほうが遥かに大きいのかも。あれだけ私にとって辛かったロマかなも、がんばって小指aだけ強制減速すると無痛化したのは意外。
それにしても、私にとって今後もっといいものって、出てくるのだろうか。アレコレ経由して「英字：QWERTY、かな：かえでライティあすか」の組み合わせが快適なので、今はそこに居座ってる……けど、かな部分についてもうちょっと良い解法があるんじゃないかと、今でも淡い期待をしていたりする。
タイプウェルで20秒を出せない構造の入力法はクソだ！ってのは、その速度域ではたぶん真。バス幅2chの2指同時打鍵法をその速度域(87.0msec/actionとか)で操作すると、ブレを許容できないしタイマーの精度基準を割り込んでしまう。時間軸が歪まない限りタイマーと戦うのは無駄。
バス幅2chの2指同時打鍵法が活きる領域って、OSが何とか保証できる40msecに対して、速度ぶれ余裕100%と判定余裕を100%上乗せした、160.0msec/action(単字系ではタイプウェル36.8秒)が天井になりそう……それ以上の領域では、前置シフト化運用するしかない。
tomoemonさんが http://d.hatena.ne.jp/video/niconico/sm5152804 で34秒台を出していたとき、小指シフト的なシフト動作にしているということが記憶に残っているのだけれど、その理由がこういう繋がりからだったのか……と今になって理解。
タイプウェルで20秒を出すなら、バス幅1chの逐次打鍵的に運用するか、 160.0msec/actionペースで230かな/20secを達成できるものを選ばなきゃ……と「NICOLAとかをdisらんと満足できネェ！」ってお感じの方が仮に居たとして、その方の気持ちは代弁できたかしら。
そういえば、そもそも同時打鍵系での速さってのは「運指速度が縛られちゃってる人にとっての、相対速度」が速い方法って何？から始まっていて、配列や実行環境の構造に起因する絶対速度のことは考慮してなかったような印象がある。言い換えれば「器用さが変わらないときの、速い方法」を求めていた。
もっともそれは、同時打鍵判定の時間を200msecとかにしていた時代──30字/分という手書き速度の倍(≒2.5かな/秒にかな漢ロスを乗せて、60字/分)を出せるようにしよう！ッて戦っていた頃──の話で、今みたいに速度拡張されて「タイパーさんによる偉業」が出ることは想定してない。
今となっては、その頃には想定していなかった「タイマーの精度が足かせになるほどに、速い」方が、現実の世界にはわずかだけれど確実に居る。その点を考慮して言及すると、今の速度＆目指す速度に応じて、速い配列……というよりも「速い運用法」は変わる、と言うのが正しい気がする。
タイプウェルで36.8秒を切るための手法として「同時打鍵方式で作っていた配列の、シフト動作を小指シフト的にする」方法が有効だとなると、「同時打鍵方式で作っていた配列の、逐次打鍵的使用法」も同等効果を発揮するのかも……このあたりは、親指で文字キーを打つ最適化をしてきた方が詳しそう。
今のところ、同時打鍵系配列で「ゆっくり打つ人は同時打鍵ロジックを使い、タイプウェルで 36.8秒を切るにはタイマー依存性のないシフトロジック*1を使ってください！」って提案をしてるものは存在しない……けど、そういう可変速度対応の配列提案ってのも、配列屋が考慮しておくべき話か。
