かな配列を使おう－JISでもNICOLAでもなく

無題

最近ノートPCを買いました。薄くて軽いのは良いんですが打ちにくいのです。ちょこっと打つのに外付けも面倒なのでコンパクトで簡単な配列を作ってみました。
QWERTYローマ字の殆どの定義はそのまま残っていますので、簡単に導入できます。「っ　ん　じゃ　じ　じゅ　じょ」を覚えたらとりあえず使えます。
詳細図は推奨の打ち方を示してあります。今それで打っているのですが、これはもうQWERTYとは別物です。上段はWEIOだけですし、句読点を中段で打つので下段もNM以外はあまり使わないのです。

Google日本語入力定義ファイル

変換を快適にするには機能キーの誤爆を減らすには

思いつきのメモです。

考えてみたら殆どの機能キーは文字入力中にはいらない。
未確定の文字があるときは文字キー同時押しで機能キーが発動する必要はない。

変換中には文字キーはいらない。
変換を押したらホームポジションが単打でカーソルになれば良い訳だ。「確定→次の文字を入力」という使わない機能を割り当てる必要はない。確定を押したら文字キーに戻れば良い。句読点を「句読点＋確定」として確定同様に使うのも良いだろう。

単純にFlagを用意しておいて、文字を発行したらFlag+=１、機能キー発行で０で行けそう。
Flagが正のときには機能キーは抑制して仮名ニ文字と判定すれば良いし、スペースを押せば変換中になる。このときFlagはー１とする。
Flagがー１のときはカーソルキーが表面に来る仕組み。
BSはFlag-=1なのだけど、拗音でずれたりするようなら、ここだけime.ahkに頼る手もある。

頻度情報付き配列図

大岡さん考案の頻度情報付き配列図が面白いと思ったので早速制作しました。そういえば今まで一枚にまとめた配列図がなかったのです。ひとつのキーに五個もかなを並べるとどうにも見ずらいと判断したからなんですが、こうして大きさを変えていくと、不思議と見やすくなりました。小さすぎて見えない字もありますが、それだけどうでも良いということで。
句読点を変換後にあとづけするのは、慣れたら問題ないですがコピー打鍵の際にはやはり不便です。そこで新たに長打シフトを導入する実験をしています。なかなか良いのですが編集キーも単打にできるんじゃないかと思いつきまして試作しています。といってもカーソルキーは連打するものです。いちいち長押しの連打なんかできませんよね。どうするかというと編集モードと文字入力モードをトグルするのです。そのトリガーは任意の文字領域キーの長押しです。思いつきなので快適かどうかはわかりませんが面白そうでしょう？

楽の多様性

キーボード配列に求めるものは人によって違っていて、それが面白いと思った。
手の運動性能の問題よりも重要かもしれない。

楽ということにもいろいろあって「脳が楽」「手が楽」は一寸違っているようだ。「思考とリズムが合わない」「覚えることが多い」ということは気が散って書き物の邪魔というのは解るが、なれたらどうということもない筈なんです。手書きの場合を考えるとそういう考えになります。だけれど日本語の表現は実に多様なので何年経っても「慣れてない言葉」があるんですね。言語と同じで大人になってから完全に習得するのは難しいのかも知れない。これをどの程度重視するか。

正確性は楽さに包含されるかどうかですが、当時は違う概念だと考えていましたが今は正直わかりません。それくらい薙刀式が優秀ということですね

正確性も楽に含まれると思います。これも慣れたら克服できるはずだけどいつまでも慣れないから。手にとっても脳にとっても間違えにくいことは楽なことであるはず。コピータイプならすぐ直すなら、間違いはどうしようもなくリズムを乱しますよね。ゆっくりでも正確なのが良い。

大岡さんのおっしゃっているのは、リズムが途切れないようにということだと思います。そのためには無駄打ちが増えたって仕方ないと。

私はどちらとも少し違うようだ。「手が楽」で考えると２打鍵を１打鍵に出来るなら一寸ぐらい間違えたって良いし、清濁分離のためにたまに間違えるのも仕方がないと思っています。でもこれ　「脳が楽」の立場からしたら不愉快でしか無いでしょうね。

仮名の配列でも機能キーのバインドでもそうなんですが、違う立ち位置から作られたものが、自分には思いつかなかったのだけど、試してみたら良かったとか、そこから新たな着想につながることはよくあります。
違う環境に合わせてどんどん分化していく、そうやってまず種が増えるのが生物進化の仕組みでしたね。ここでも多様性は善であると私は信じる。

かな連接頻度

「てき」「してきた」が気になったので調べてみた。
「～て＿きた」は「てき」に数えないほうが良いというのはそのとおりです。でもそんなに多かったら「～のよう」「～とおもう」のように繋がってしまうと思うのです。
私の感覚では［「～とおもう」＿のように＿繋がってしまう＿と思うのです。］なんです。
といっても「うと」が切れいるわけでもなくて、出来ればつなげて打ちたいけれど息切れして、いそいで息継ぎする、そんな雰囲気です。読むときは一息ですからね。

てき	17.36
てきた	2.81
してきた	0.57
ってきた	1.06
てきたい	圏外

「てきた」は結構多いけれど、この程度なら「てき」を過大評価してもまあいいでしょ。という検証結果になった。

ソースは手持ちの集計データ。かな一万字あたりの出現回数。kana_hindo.txt
スマホ用 kana_1gram.txt　 kana_ngram.txt

AHK版alpha

TypeWellとE-typing（Edgeで確認、Firefoxは駄目）のかなタイピングが出来るようになりました。
AHKは罠が多いので先人の公開されているScriptが大いに参考になりました。
これもなにかの参考になるかと置いておきます。
後置シフトという方式はローマ字テーブルで不完全ながら実用上は実装できますが、エミュレーターでの実装は難しい、というかPreFixとしてシフト面の数が許すだけしか実装できません。まあマイナー中のマイナーなので当たり前です。月見草のほかには月林檎配列とブリ中トロ配列の拗音部分、他にあったかな…
あ、そうそう月見草配列は「人差し指前置・人差し指中指薬指後置シフト」方式？です。
後置シフトという他にWindowsの設定はUS配列のままJISかなの直接出力をするということをしています。うまく行かなければWindowsの設定をJPにして記号全部置き換えようかとも思ったのですが、なんとなく出来てしまいました。
AHK　Script tsukimisou_kana.txt

同時押しの話II

前回は同時押しの話でしたが、右手が先に動くのは順に押す場合でも同じで、短い間隔で左→右と押すべきところが逆転することも当然あるわけです。月配列で左前置シフトのDを押し遅れるとか右にある濁点を先に押してしまうとか、そういうことがあるわけです。
だから月見草には「左→右」が無いのです。配列図は複雑ですが運動はとてもシンプルに出来ています。
右手が早いの法則は悪いことばかりではありません。順に右左と押すには左手に僅かな遅延を掛けているのですが、その遅延が短くて済むわけです。
同時に押すつもりだと、今の環境では９９％位右が先になります。これを99.99％にしたらこの遅延が要らなくなります。主観的には同時押しです。
左のシフトをわずか先に押しても右左と押したと修正解釈すれば出来そうな気はします。ロールオーバーによる同時押しの判定がうまく行かないのは数10msの話で、仮名同士の間隔は200msでも分速300字になるわけですから。…どんな実装が良いか思案中…

打鍵数と指の負荷

これには強い相関関係があるのは当然だけども、イコールでは無い。新下駄配列は人差し指と薬指を同じ位の回数使うけれど、やはり人差し指の負担がずっと多いと思う。
薬指はあまり動かないということもあるけれど、同時押し比率が高い。同期を取るため、ロールオーバーを避けるため、少しゆっくり打つはず。逆に人差し指は速く打ちそうな仮名が並んでるんだよね。
月見草は右人差し指が最初に疲れる。uhの２ストローク削減したのだけれど、まだ多いのか。でもこれ以上は手が無い。
「じゃじゅじょぎゃぎゅぎょ」を減らした後打ち込んでいない。ちょっとだけ楽になっているはず。

同時押しが何故苦手かというお話

親指に関しては、動きが鈍過ぎる。キーボードの物理的改善でマシにはなるかもしれませんが、自分の親指はどうしたって遅いです。文字入力以外では最大限使いますし、直接入力でも同じように使いたいという事もあります。
では文字キー同士（新下駄）ならどうかといいますと、同時に押すつもりでも右手が圧倒的に早く動きます。なおかつキーによって相当バラツキがあります。ですから、同時押しの判定を厳しくすると２つのカナに別れてしまいますし、と言って緩くしては順に押したつもりがくっついてしまうんです。それを避けようと思うとどうしたって力が入ってしまうんですね。自然な打鍵じゃなくなるんです。
薙刀式テスターは最大限緩い判定ですし、人差し指はやはり器用です。これならできる感はあります。でも速くなってきたら無理かも知れない。
まあ、そういう人も居るのだというお話でございました。

リストラは続く

「ぎゃぎゅぎょ」もシフトを省略できるようにした。
0.1％程度なのでちょっとどうでも良いですが、悪い影響は「スィスェ」が無くなることと、シフトを押してしまって損したと思うだけ（こちらがメイン）なので。