交差打鍵判定ロジックを基礎として用いて「打鍵順序補正機能を除去した(＝補正せずそれぞれに文字を割り当てる)」ロジックを作るしかないような……。
(言及:新配列を考えてみた 4: アイデア屋なななの部屋)
(関連:新配列を考えてみた 3: アイデア屋なななの部屋)
(関連:新配列を考えてみた 2: アイデア屋なななの部屋)
(関連:新配列を考えてみた: アイデア屋なななの部屋)
この記事をお読みになる、「該当配列設計者さん以外の」配列屋さんに対する解説を……。
錦山配列とは、「AT互換機用キーボードのテンキーを使った３シフト方式の行段系配列」です。
３つあるシフトキーのうち少なくとも２つは「プレフィックスシフトキーとしても、プレポストフィックスフィックスシフトキーとしても用いる*1」という、幾分ややこしい仕掛けを採用しています(このため「菱」による実装が不可能になっている)。
実用新案として申請済みとのことで、配列設計をするときには仕掛けを踏まないようにご注意ください……。
#(実装＆評価打鍵が未試行であるためか)該当解説を100%そのままでは実装出来ない、という点に注意。以下では実装出来るようにロジックを「かえで化」しています。
はじめまして。
個人的妄想？の結果から申し上げますと、「綿山配列」のシフトロジックは、次のように設計する必要があります。
- 同時打鍵ロジックの一種で、簡易ロジックの一つである「交差打鍵判定ロジック」を用いること。
- 交差判定ロジックのうち、打鍵順序の逆転を補正する(＝打鍵順序が逆転しても同じ文字を出力する)機能を崩し、打鍵順序が違うときには違う文字を出力する。
- (人差し指シフトキー＋行キー(→親指or小指シフトキー)という「打鍵順序つき同時打鍵」を実現するために)速記入力法で使う「全キーのリリース時にパターンを確定する」仕掛けを、先の同時打鍵ロジックと組み合わせて「打鍵順序つき全キーリリース時パターン検索」にする。
……と、すごく説明が意味不明なことになっていますが、こういうロジックを使わなければ、実現は無理だと思います。
こういうロジックにするためには、タイマー機能が不要で、かわりに複雑な交差判定が実装できる必要がある……ので、「窓使いの憂鬱」「のどか」「em1keypc」「AutoHotKey」あたりのツールを使う必要があるでしょう。
「窓使いの憂鬱」「em1keypc」については、交差判定を用いた「NICOLA」「飛鳥カナ配列」のためのスクリプトが公開されていますので、そういったものを参照しつつ、同ソフトウェアのスクリプト記述用ドキュメントを元にスクリプトを書く必要があります。
もしも「姫踊子草」または「繭姫」で表現できるような入力法であれば、私が書いて提供することも可能……なのですが、これらは「綿山配列」を実装することが出来ませんので、お手伝いをすることは出来そうにありません。
従来法を使って「綿山配列」のシフトロジックを実装すると、以下の通りの問題点が出るのではないかと予測されます。
逐次打鍵順判定＋タイマー法では(連続シフトにせよ非連続シフトにせよ、仮にタイマー時間を動的に設定しても)速く打たれる言い回しでのシフト誤判定がおきます……練習初期は良くても、実用速度になったあたりから影響が出るはずで、実装用のソフトウェアもないはずなので、これはお勧めできないような。
また、同時打鍵ロジックはそもそも「打鍵順序ミスによる打鍵順の逆転を、ソフトウェアのチカラで補正する」ためのものなので、これもそのままでは利用できません。
さらに、速記入力法のように「キーが全て離される度に、それまでに押されたキーの組み合わせに合致するパターンを表示させる」という方法も、そのままでは使えません。
唯一の例外として
- １文字ごとに「文字確定キー」を押す。
という方法を使えば、こういう複雑なロジックを使わず逐次打鍵で処理できます……が、これでは実用新案にしようとしている配列とは異なるものになってしまうんですよね……。
「行キー」を単独で押すと「あ段」が入力されます。
「行キー」「小指シフトキー」と押すと「い段」が入力されます。
「小指シフトキー」「行キー」と押すと「う段」が入力されます。
「行キー」「親指シフトキー」と押すと「え段」が入力されます。
「親指シフトキー」「行キー」と押すと「お段」が入力されます。
(from http://nananakakuyoku.seesaa.net/article/112192703.html )
この時点で、実装方法は「交差打鍵判定法」以外に存在しないと思われます。
交差打鍵判定法は、同時打鍵ロジックを必要とする配列に対して「タイマーが使えない環境のために」作られた、擬似的な同時打鍵ロジックです。
同時打鍵ロジックはそもそも「打鍵順序ミスによる打鍵順の逆転を、ソフトウェアのチカラで補正する」ものなのですが、交差打鍵判定法ではこれを「同時に押されている期間がある２つのキーについて、打鍵順序が逆順であっても同じ文字を出す」ことによって実現しています……そのため、綿山配列ではこの逆順打鍵補正ルールを解体して、「同時に押されている期間がある２つのキーについて、打鍵順序が逆順であった場合には、異なる文字を出す」ようにスクリプトを組む必要があります。
そして、
二つ目は、同時押しで判断する方法です。
「あ行キー」を押しながら「小指シフトキー」を押すと「い」
が入力されるように、キーを同時に押すことで判断する方法です。
この方法の問題点は、濁音を入力する際は、
3つのキーを同時に押すことになるので、
うまく検出できない可能性があることです。
(from http://nananakakuyoku.seesaa.net/article/112351260.html )
これを満たしつつ「文字確定専用のキーを用意しない」ことを満たそうとすると、「全キーのリリース時にパターンを確定する」仕掛けを重ね合わせる必要もでてくる……と、内容を読ませていただいた上で、こういうふうに考えたところです。
ただし、今回提案する「打鍵順序つき全キーリリース時パターン検索」というシフト方式は、逐次打鍵による「たとえロールオーバー打鍵してしまっても、キーDownの順序さえあっていれば正しく入力される」というメリットと、同時打鍵による「打鍵順序を無視してキーを押し込んでも、片方がキーUpするまえにもう片方がキーDownされていれば正しく入力される」というメリットのどちらも享受できない(→打鍵順序と同時打鍵の両方を意識しなければならない)ため、初期練習中の「一文字ずつ入力する」上では問題なくても、創作文を打つときのように「打鍵タイミングがカナの出現頻度によって大きくばらつく」シーンにおいては、利用者に対して相応の負担を強いることになるであろうと感じています*2。
それと、もうひとつ気になることが……。
この入力法、手首を内転/外転させつつ打たれる恐れがあるように思うのですが、その頻度が(「あ」段以外の多くが対象となるため)ちょっと高すぎるのではないかという予感がしています*3。
実装できた暁には、念のため数千字/日程度の評価打鍵を行うことを、強くお勧めいたします。
……というわけで、私が考え付いたことは以上となります。
2009年1月11日0:18:52追記。
このシフト方式について、「キツイ」と感じるか、あるいは「ラクだ」と感じるかは、人それぞれに違うはずなので、私には言及できかねるところです。
親指シフト系の配列群でさえも、配列方針やシフト方法、あるいは打鍵範囲などが変わるだけで「全く別物」になるような状態ですし、数年にわたって散々評価打鍵による調整が行われたような配列でさえも「ある人にとっては全く合わない」とかいうことが平然と起きていたりしますので……【打鍵順序つき全キーリリース時パターン検索】を使う配列群の中にも、色々と面白い配列案が眠っていたりするのかもしれません。
それと、けん盤配列を設計するときには「まずシフト方法＆シフトロジックを設計して、そのロジック内で使える打鍵パターンを抽出して、それから必要な文字を割り当てて、最後に評価打鍵しまくる」か、あるいは「まず必要なパターン数を決定して、次にそのパターンを収容するためのシフト方法＆シフトロジックを設計して、それから必要な文字を割り当てて、最後に評価打鍵しまくる」というプロセスを経ることが必要だと思われます。
パソコンで自由に配列設計＆評価打鍵を出来るようになったのは、つい最近の話……なので、評価打鍵が必ずしも必要だとは言い切れないのですが、私自身が「評価打鍵をせずに配列をいくつも作り、結局はひどい思いをしてきた」ものですから、こういうところはやはり気になってしまいます。
そういえば、こういう場合に私(を含む配列屋)は【打鍵順序つき全キーリリース時パターン検索】というロジックを使ってもいいのだろうか？ちょっと気になるところで。
#ってゆーか、【打鍵順序つき全キーリリース時パターン検索】ではなくて、実際には【打鍵順序つき全キーリリース時文字出力】でいいのか、打鍵順序に応じて｢必ず一意にきまる」のだから。
*1:2009年1月11日0:22:19追記……2回も「プレフィックスシフト」があったら意味ないじゃんorz。「ポストフィックスシフト」に修正しました。
*2:2009年1月11日2:26:57追記……「飛鳥カナ配列」と「かえで＊＊＊＊あすか配列」には、この手の問題と根っこのところでは共通する「シフト残り現象」という物を抱えている(ユーザー指定による時限打ち切りか、動的タイマー制御か、あるいは「タイムシフト方式」によって解決するか、そもそも同時打鍵判定自体を止めることで、この問題を解決するしかない)ので、今回提案のような複雑なロジックについては、「なんとなく、こういう打鍵感になるだろうなぁ……｣と感じるところがあります。もちろん、実際に評価打鍵したというわけではないので、確実というわけではない……のですが。
*3:2009年1月11日0:36:19追記……紙キーボードでざっくり評価打鍵した感触としては、掌の上下動＆手首の内外転を極力抑えて、上下動は指先のみ＆左右動は掌のみ(腕がつられて動く状態)にするのが、この配列を軽い負担で使うためのコツになるのではないかという予感がしました。
