(memo)親指シフトって……「ロールオーバー」が使えないの？
…… そ ん な ば か な 。
そこにあるのは「動作の癖」であって、「言葉どおりに、できない」わけじゃないよ……。
※文字キー同士の同時打鍵には文字を割り当てていないので、文字キー同士の同時押下については「同時打鍵判定」されず、常に「ロールオーバー判定」のみが為されることに注意されたい。
- 非連続シフト系はnキー目の文字キーが離されるよりも前にn+1キー目の文字キーが押されてしまっても、文字キーの押下についてロールオーバーできる(＝n+1キー目に重ね押しされた文字キーが、無視されたりすることはない)。
- ただし、シフトは1文字単位で掛けなきゃいけないという「制限」があり、それを無視すれば「かけようとしたシフトが掛からない」ってゆータイプのシフトミスになる。
- あと、「エミュレータがタコでさえなければ」ってのも、一応「制限」なんだろうなぁ……。
- 連続シフト系は「任意の文字→同一シフト面文字(→同一シフト面文字......)」に限る、という「制限」のもとに、nキー目の文字キーが離されるよりも前にn+1キー目の文字キーが押されてしまっても、文字キーの押下についてロールオーバーできる(＝n+1キー目に重ね押しされた文字キーが、無視されたりすることはない)。
- この制限を無視すると、要は「シフトミス」になる……って話(ロールオーバーできないなら、そもそもシフトミス文字が出るわけないし)。
……って、この誤解、一体どこから始まったんだろう……あとで調査しよう。
#親指エミュのロジックやスイッチによって「使い心地が違う」ってゆー感触を抱くのも、「ロールオーバーさせたときの挙動が異なっている」ことが原因だし。
(2010年11月8日20:39:21追記)解りにくすぎる書き方になっていた……ので、↑の部分について(「そんなばかな」部分の太字化を外したうえで)追記しました(追記部は太字としています)。
ちなみに、この記事では「混用される前の基準」を元に、語の意味を使っています。
| 名称 | 古い意味での結果 | 判定状況 |
|---|---|---|
| 同時押し対応(重ね押し対応) | 2つのキーの単独押下とは、異なる文字が出る | 物理的には「同時に押している期間がある」キーについて、その全てのキーが「論理回路上でも」キーdownを保持してる状態。 |
| ロールオーバー対応 | 2つのキーの単独押下とは、等しい文字が出る | 物理的には「同時に押している期間がある」キーについて、そのキーのうち最低一つが「論理回路上でも」キーdownを保持してる状態(残りのキーが「論理回路上では、キーupを発行されてしまい、すでに離されていることになっている」場合、それは「nキー同時押し対応」ではないが「nキーロールオーバー対応」ではある)。 |
今のメーカーさんが「ロールオーバー」と「同時押し」を混用しちゃってるのは、単純に「同時押しなんて、ショートカット以外では使わないでしょ？」って考えてるから……なのかも。なので、イマドキなら「ロールオーバー＝同時打鍵」と表現しても、間違いじゃないわけで*1。
ただし、「シフトキーの単独押下によって、文字の入力を行わない入力法*2」であって、かつ文字キー同士の「同時押しに対する文字割り当て」がない配列の場合には、『文字キー同士については同時に押している期間があっても判定に支障がないので、(古い表現で言うところの)ロールオーバー的な打ち方をしても、全ての文字が正しく打たれていく』ので、「ロールオーバー」と「同時打鍵」とを、古い表現で書かないと解りにくくて仕方がないんですよね……。
そういえば、『文字キー同士同時打鍵方式』の入力法でも、エミュレータ側のロジックが「動的な判定の切り分け」を行うように設計されていれば、ロールオーバー打鍵は条件付で行えます……その代表例が『やまぶき』。
『文字キー同士同時打鍵方式』では、文字キー同士の同時打鍵にも意味が設定されてるので、「文字キー同士の同時打鍵を、完全に無視する事はできない」のはアタリマエ……なのですが、だからと言って「(操作者本人は同時打鍵判定して欲しくないキーシーケンスを打鍵しているにもかかわらず)ほんのちょっとだけ同時押しされたものまで、同時打鍵として判定されてしまっては、うんざりする可能性があってあまりよろしくない」わけで、『やまぶき』では以下のように同時押ししたときの挙動が振り分けられています。
ちなみに……。
810 名前：809[sage] 投稿日：2010/11/08(月) 16:42:04 0 さらにこんなブログも見つけた。 タイトル： 「親指シフト≠同時打鍵」？？ 飛鳥カナ配列 ☆未来の子供たちへの贈り物☆ ttp://ameblo.jp/asuka-layout/entry-10011269780.html こっちでは「親指シフト」が必ずしも「同時打鍵」の配列ではない、という話になっているし。 混乱してきた。
この件について。
飛鳥系の配列は、「同時打鍵判定」と「連続シフト(というか、シフトの非打ち切り)」の、どっちに強く依存してるか？ッて話、だったような。
飛鳥系は、シフトの変移回数(≒押下回数)を減らそうとしてるシフトの変移回数(≠押下回数)を減らそうとしてるので、「同時打鍵判定」はなくても何とかなるけど、「連続シフト(というか、シフトの非打ち切り)」がなかったら結構洒落になりません。
実際のところ、超簡易的にやるなら「(新JISかなの資料にあった、文字キーを数十ミリ秒ディレイで遅らせただけの)タイムシフトロジック」でも、シフト残りの問題を含めて、まず何とかなります。
ただ……打ちやすさを考えると、「シフト残り対策」を真面目にやってくれる、「繭姫」とか「やまぶき」があるほうが、絶対にありがたい！と、そういう話となっています。
#「シフト残り対策」ってゆーと、なんか飛鳥専用の特殊処理っぽく感じる……かもしれませんけど、↑で書いてる『文字キー同士同時打鍵方式』に関するやまぶきの「ほんのちょっとの同時押しは無視して、逐次入力と解釈する」ってゆー挙動も、まるっきり「シフト残り対策」と表現できるものです。こーゆー処理があるので「連続シフト(というか、シフトの非打ち切り)」をOnのまま使っても、配列にあまり関係なく『上手く機能してくれる』わけで。
