Bluetooth接続グッズ制御仕様変更の方針
この記事は現時点での筆者の考えを記しただけのものでありますので、アプリを使いたいだけなんじゃボケ〜！ という方はこの記事を見る必要はありません。
あと、読むの結構大変です。(^^ゞ
自分の思考整理の産物でもあります。
先日の『U.F.O. SA／A10サイクロンSA／バッハスマート／ROCKET +1D 独自制御アプリDual版Ver.1.40』『U.F.O. SA／A10サイクロンSA／バッハスマート／ROCKET +1D 独自制御アプリPro版Ver.2.30』リリースでもちょっと触れていましたが、次回のリリースでは制御仕様そのものを改良したいと考えております。
U.F.O. SA、A10サイクロンSA ＋PLUS（プラス）、バッハスマートに対応としておきながら実機としてU.F.O. SAしか持っていなかった筆者が今回、ROCKET＋1Dの実機を入手したことで色々と思うことがありまして、制御仕様に手を入れたいと考えるに至りました。
現在の仕様でも結構自在に設定を詰めることが出来るようにはなっているのですが、じゃあそれを作った筆者がどんなふうに使っているのか？ というと、実は、Random制御のStepかCompositeでボリュームは1しか使っていない（停止するか1で動かすかのみ）のです。
どういうことかと申しますと、そもそも、オナニー中にそんなに事細かく切り替えなんかしたくないよ、という考えが根底にあります。
皆さん、こんな経験はありませんか？
オカズを選定するのに一所懸命になりすぎると、感度や興奮が落ちる。
オカズ選定に脳が集中してしまって、肝心のオナニーがお留守になってしまうんですね。
しかも、これ、オナニーの方に集中力を戻すのが結構大変だったりします。
脳の疲労や飽きは簡単には回復できませんからね。
グッズのコントロールでも似たようなことが起きます。
あんまり、グッズのコントロールをきっちりやることばかりを考えてしまうと、そちらの方に脳のリソースが取られてしまって肝心のオナニーがプアになってしまうのです。
グッズには良いように動いて欲しいけど、そのための指示をいちいち細かく出したりしたくない。
だから、ランダム制御の仕組みを考えて、アプリを作ったわけなんです。
で、筆者はそれを長いことU.F.O. SAにだけ使用してきて、しかも筆者の場合は乳首メインというわけではないので、常に動かすか停止するかという指示だけでも満足していたわけです。
ボリュームという概念の変更
ところが、同じようにしてROCKET＋1Dを使ってみると、ちょっと物足りなく感じました。
確かに、ほとんどの場面で従来どおりの使い方と同じでも良い。
でも、それじゃあ、フィニッシュに持っていくのはちょっと無理があるなぁ、と。
そこで、思い出したんです。
以前、筆者は「ランダム制御で停止させたくなくて設定を書き換えたけどどうしても停止してしまう」というバグを使用者の方に指摘していただいたことがありまして、そのときは
「あぁ、止めたくない、って人もいるもんなんだなぁ」
と思っていたのですが、ああこれか、と今になって気付いたのです。
場面によってはランダム制御でも停止状態にはしたくない、ってときもあるよね。（特にイクときなんか）
そう思うと、今の制御仕様ではある欠陥が見えてくるのです。
そう、今の仕様では設定をどうイジっても、「ある程度の確率で停止状態になる」か、もしくは「自分で停止させない限り一切停止状態にはできない」か、の二択にしかできないのです。
それって、QoO(Quality of Onani)質の高いオナニー環境を求めるには制御仕様に改善の余地があるのではないか？
そこでもう一つ懐疑的にならざるを得ないのがボリュームのあり方。
実はランダム制御の中核以外の部分では、筆者は一般的な電動グッズの制御仕様を真似て作って来ていました。
（自由に設定できるようにはしたものの、）同じ動きを繰り返すパターンがあって、それをある程度強弱のコントロールができる、という形がそれです。
で、あまり深く考えられていなかったのでしょう、ランダム制御もボリュームという概念を持ち込んで強弱をコントロールできるようにしていました。
でもさあ、多分、本当に欲しいのって強弱のボリュームじゃなくて、モードの変更だよね？
例えば
「止まったり弱い刺激中心の焦らしモード」
「ときどき止まったりときどき強かったりもする通常モード」
「強めの刺激が連続するフィニッシュモード」
これがボリュームの1、2、3じゃない？
必要なのは ランダム値 × ボリューム ＋ オフセット じゃないんだよ！
上でも書きましたがフィニッシュモードに停止状態なんて欲しくないんだよ！
そんな気がしたんです。
そこで、次回の改修では ランダム値 × ボリューム ＋ オフセット という計算式を捨てようと思っています。
従来で言うところのボリューム、今まではここの数値も自由度がありました（極論すると100段階まで設定できた）。
ですが今回、せいぜい使うとしても3モード、と限定させていただきまして、完全停止以外は3段階に決め打ちさせていただこうかと思っています。
そして、3つのモードそれぞれに設定値を設ける。
これは従来と異なり、直接グッズに送信する値となります。
3つの設定を書かなければならなくなる反面、
・停止状態を含んだり含めなかったりすることが可能
・オフセットの概念が不要
・ボリュームを乗じるとグッズが応答できる最大値100を超えてしまうために今まで設定することが不可能だった、「ごく稀に強く動いてくれる」状況など、設定の自由度がさらに広がった
というメリットが生じます。
そう、従来のボリュームという概念をモードに置き換えたことで、
・普段は止まったりすることもあるし、ときどき短時間だけ強くされることがある
という状態とか、
・止まること無く強めの刺激が延々と続く
という状態とを、
一つのパターンの中に織り込むことができるのです。
グッズごとの差
そして、もうひとつ感じたのが、U.F.O. SAとROCKET＋1Dではスイートスポットとなる値が全く異なる、ということ。
U.F.O. SAでは10〜35くらいの範囲で動いてくれれば十分なのですが、ROCKET＋1Dでは最低でも20はないとモーターが唸るだけでローターが動いてくれませんし、強いときは80とかくらいあっても良い（まだ詳細には判別できていませんが）んじゃないかと。
同じようにして、A10サイクロンSA ＋PLUS（プラス）やバッハスマートもスイートスポットが違う可能性が高いんですよね。
それを全て、同じ設定値で制御しようとしていたことは無理があったのではないか？
もっと言うと、劣化や使用状況などにもよる個体差というものがあるのだから、これはもう、少なくとも各グッズごとに設定を分けた方が良いのではないか？
そこで、次回のランダム制御の設定値は各グッズごとに別の値を持つようにし、接続したグッズに応じて採択する設定値を変えるようにしたいと思っております。
なお、任意パターン設定の方では特にグッズごとに別の値を持つことは考えていません。
いちいち（持ってもいない）全グッズ用の値を書くのは大変ですし、そもそも、必要なら各グッズ用の任意パターンを増やして書けば良いだけですので。あくまでも、ランダム制御用だけでの話です。
Gladual変化の多様性と設定記述方式
ここまで仕様が変わってしまうと、せっかくこんなニッチなアプリを使いこなすために苦労して覚えていただいたのに、同じ苦労をまたさせてしまうことになるので、非常に申し訳ないと思っております。
（もちろん、無理に最新版を使っていただく必要は無く、従来仕様の最新版『U.F.O. SA／A10サイクロンSA／バッハスマート／ROCKET +1D 独自制御アプリDual版Ver.1.40』『U.F.O. SA／A10サイクロンSA／バッハスマート／ROCKET +1D 独自制御アプリPro版Ver.2.30』を使える限り使っていく、というのも全くアリだと思います。）
逆に言うと、極力骨子を変えたくない、変えずに済む仕様というものを最初に作り込んでなるべく長く同じ形が維持できるようにするのが、アプリ作成者としての腕の見せ所なんじゃないか、と思っております。（UfoSaCtrlDualの結構でっかいバグに気が付かなかった奴が何を言うてるんや、って言われそうですが）
（世に出ている著名なアプリは何でも良いからとにかくあらゆるところを変更していって、度重なるアップデートで知名度と収益を維持することの方が優先されますが、本当に使えるアプリというのは存在が空気になるほど変わらないものだと思います。）
逆に言うと、それでも仕様変更すべき、となったときにはなるべく仕様の向上策を取り込んでおきたい、という思いがあります。
今回はそのチャンスです。
はっきり言って、現時点でもこのアプリがここまで長寿になるとは思っていませんでしたし、思いの外、類似の制御ができるグッズも種類が増えてきたので、意外とこの先の寿命も長くなるのかもしれません。
ですので、このアプリとしても作成当初に不十分だったところをもうちょっと突っ込んでおきたい。
そんな気がしました。
このアプリではランダム制御という特徴の他に、Gradual変化（漸変）という、いきなり値を飛ばさずに徐々に変化させていく動かし方ができるという特長を持っていました。
これは、単純に時間経過ごとに数値を一定数増やしたり減らしたりしていくだけでして、労力を厭わなければ自力でそういうパターン設定を書くことも可能なわけで、そういう意味では労力低減策の一つでしかなかったかもしれません。
とはいえ、ランダム制御の動き方にバリエーションを持たせてくれていた、という意味もあったので全くの無駄仕様でもありませんでした。
ただ、パターンを定義するときこのGradual変化をするのかしないのかという設定を常に書く必要が生じてしまい、それを筆者は「s」と「g」という英小文字にしていました。
開発当初から悩んでいて、結局は0,1だと後で見て分からなくなるんじゃないだろうか？ という理由でs,gにしていて、それはプログラムとしても決して扱いやすい形ではありませんでした。
しかし、PCで定義を編集する分には別にs,gでも何の不都合も無いのですが、Android上で編集しようとするとちょっと面倒いですよね。
Androidのソフトウェアキーボードはたいてい、数値を打つときには長押しするかキー配列を数値入力モードに変更する必要があります。
数値と英字の混在って入力に時間が掛かるんですよ。（数値付きQWERTY配列にしている人もいるかもしれませんね。）
ですので、（コメント部分は仕方が無いとして）設定値そのものを編集するだけなら全部数値入力モードでやりきれる形にしたいなあ、という思いがあります。
それと同時に、従来のGradual変化は決まったスピードでしか変化できませんでした。
そこにある程度の自由度を持たせたい。速度勾配の自由度ですね。
今までは100msで1つ値が変化する、という変化スピードしかありませんでした。
それを整数もしくは分数で表現するというはどうでしょう？
変化させる値 / 時間（単位：100ms）
時間の方が1になるときは変化させる値だけを整数値で書けば良いことにします。
つまり従来と同じGradual変化なら「1」と書けば良い。
Gradual変化させずにすぐに設定値に変化させるStep変化は「0」と書く。
200msごとに1変化（今までの半分のスピードでゆっくり変化）させるなら「1/2」
300msごとに2変化させるなら「2/3」
600msごとに4変化させるなら「4/6」（約分はしませんので、一行上とは300ms経過時の2変化がすっ飛ばされる、という違いがあります。）
100msごとに2変化させるなら「2」（「2/1」と書いても良い）
200msごとに3変化させるなら「3/2」
100msごとに10変化させるなら「10」（ただし、ここまで速くさせるならStep変化とほぼ変わらないと思います。）
みたいな感じでどうでしょうか？
まだプログラムを組んではいないので、「いやそれちょっと実装には無理があんよ」という可能性も無くはないのですが。(^^ゞ
ランダム制御の方ではこの速度勾配をどうするか？
とりあえず、ここはプログラム内で適度に散らすように組もうかな。（設定は持たずに）
そして、
ランダム制御「Gradual」と「Composite」の統一
このように仕様を変更すると、「Gradual」と「Composite」が別々で存在していた意味が無くなります。
「Gradual」の変化スピードが多種多様になったら、Step変化も含めるかどうかだけの差しかない「Composite」をわざわざ別建てする意味がありません。
というわけで、これを「Normal」モードとして集約しようかなと思います。
従来のランダム「Step」制御はいわゆる「通信頻度を抑えて、送信ミスの機会を減らしたり、バッテリーの持ちを良くする」モードですので「Eco」モードとでもしようかな、なんて考えていたりします。
いや作者さん、こういう考えが抜けてんよ〜
みたいなことがありましたら、コメントをお寄せいただくとありがたいです。
もしかしたら、実装に組み込めるかもしれませんし、あるいは、ごめんなさいするかもしれませんが。(^^ゞ
今のところ、従来仕様よりも手間と利便性の折り合いがバランス高くできているんじゃないかと筆者は考えているのですが、みんながみんな、筆者と同じオナニースタイルを持っているわけではありませんので、筆者の見えていない世界というのも、まだまだあるのではないかと思っていたりもします。
この仕様では設定のしようもない、というような有用なグッズの制御方法なんかがあったりしたら教えていただけると嬉しいな。
あ、AIはやらないっすよ。
興奮度合いとかイキそうになってるとかいう状況が常にセンシングできるならまだ可能性はありますけど、現状ではグッズを動かすことしかできませんから、そういう状況は人間が人の手で機械に知らせるしか手がありません。
それが、今回仕様変更しようとしている、「ボリュームからモードへ」の変更、ですからね。
PWM?制御追加を検討中
2019-11-08追記です。
ちょっと新案が浮かびまして、小刻みに動いては止まる動きを追加しているのはどうだろうか？ と考えています。
アタッチメントの構造によってはまるで意味の無い動きにもなりうるのですが、ヒット率の高い、密度の濃いアタッチメントであれば、ちょっとまた一風変わった感覚が得られるかもしれない。
例えば、強さ20一定で動いている状態があるとします。
これを強さ40で0.5秒動いて0.5秒止まる動きを繰り返していると、平均で見れば強さ20一定で動いているのと同じになります。
が、その中身が激しく動いて止まるの繰り返しなので、ちょっと変わる……よね？
PWM制御って恐らくグッズのモーターの制御が既にこれになっていると思うので、PWM制御で動くモーターに与える指示をさらいPWMでって二重掛けでなんか変な感じもしますが。（なんか良い呼称無いかな……）
ただ、これをどうやって仕様に織り込んでいくか、う〜む、悩ましい。
大改修前に機能改善
2019-11-10再追記です。
次回メジャーバージョンアップと言っておきながら、その前に機能改善しておきたいところが見つかりましたので、一旦、そちらの修正を挟む形にしたいと思います。
ほとんどの方には必要無い機能なのですが、今まで、ボリュームボタンやメディアボタンなどの反応は一番優先度の高いアプリにしか通達されないため、UfoSaCtrlProとUfoSaCtrlDualを同時に実行しているときにこれらのボタンを押しても、どちらか片方しか反応できませんでした。
これを両方とも反応できるようにアプリ側で機能追加をし、UfoSaCtrlシリーズ全てで同時に反応するように改修したいと思っております。
（メジャーバージョンアップ後にアプリ名称を変更するかどうか考え中。現バージョンをずっとメンテナンスしてゆくつもりは無いのですが、名称を分けると同時に実行できるようになるので、例えばProとDualをメジャーバージョンアップ後にNeoとWとかにすると最大で4つのUfoSaCtrlを起動することができ、最大同時6台のBluetooth接続グッズを制御できるようにはなります。そこまでする必要皆無だけど。）
→すみません。これ、リリースしないで葬ろうかと思っております。
次期メジャーバージョンアップ版で3台同時接続を可能としたことで、2つアプリを立ち上げるということそのものの必要性が無くなってしまったのと、次期バージョンでチクニー実践したところかなり出来が良く感じたので、今から旧版に戻る気力が無くなってしまったのと、あと個人的な作業（量等）の問題で、次期メジャーバージョンにリソース集中したく思います。すみませんです。
スクリーンショット
2019-12-06追記、開発中のものです。
上記のものを概ね全て取り込んだ上で3台同時接続制御を可能とし、従来のDualとProを一本化してTrip(le)となる予定です。
通信ビジーはAndroid機のせい？
2019-12-07追記です。
筆者は大変な勘違いをしていたかもしれません。
頻繁に通信するとU.F.O. SAが受けきれなくなる、と以前の記事で書いたことがあり、UfoSaCtrlでも100ms単位で連続して送信することを極力避け、なるべく200ms以上間隔が空くようにと制御ロジックを改修していました。
が、今回のテストでいろいろと試していた結果、もしかしたらビジーになっているのはAndroid側の方なんじゃないかと思い始めています。
（AndroidOSのソースまで読めば最初から分かっていた話かもしれません。すみません、そこまで追いきれてなくて。）
U.F.O. SAを2台同時接続した状態で、2台ともに200ms間隔で連続して通信してみますと、Androidの機種によって、通信エラーが頻発するものと、全くエラーが起こらないものとその中間と、機種によって本当に結果がバラバラになりました。
100ms単位で連続すると通信取りこぼしが頻発するので200ms単位に改修したのに、200ms単位でもエラーが発生する機種は山のようにエラーを起こして、むしろ、正常に通信できるケースの方が少ないくらいです。
なのに、同じプログラムなのに、機種によってはそのエラーが全く起きないし、U.F.O. SAの方の綺麗に追随して動いてくれています。
そして、その機種による差というのは、性能差でもなく、OSの差でもありませんでした。
筆者の所持するAndroid端末でエラーが起きない機種はLeMax2 (Snapdragon820)。
FLEAZ F4 (BCM23550)もかなり意地悪しないとエラーが発生しませんでした。（意地悪するとたまに取りこぼす程度）
LeMax2はカスタムROMのAEXを導入していてAndroid9.0です。
これだけを見るとOSのバージョンが新しくてSoCの性能も良いから、と思いたくなりますが、
FLEAZ F4はAndroid4.4。筆者が『あまりBLE周りの性能が良くない』と言ってきた古いOSです。しかも、Coretex-A7という古いSoC。
筆者がUfoSaCtrlシリーズを長年開発してきて、その過程では確かにFLEAZ F4での動きがいまいちでより新しいAndroid端末での動きの方が良い、という局面ばかりでした。
が、今回のUfoSaCtrlTripで改めて処理の見直しをしたところ、状況が一変。
通信エラーの多い御三家が悪い順に、
goo7 (MTK6750T Android7.0)
HT17Pro (MTK6737 Android6.0)
MAZE ALPHA (MTK6757 HelioP25 Android7.0)
とMediaTekに集中してしまっているのは偶然か否か、この程度の台数では筆者には分かりません。
同じ2.4GHz帯のWi-Fiでの掴みが悪いMAZE ALPHAはこの3機種ではマシな方なので、一概に通信周りの出来に左右されるとも言い切れず。（ただ、掴むまでが悪くても通信そのものは悪くなかったり、なんていうのもBluetoothでも普通に起こることなのでうーん）
筆者混乱中。
とりあえず、連続通信制限のロジックを設定値で可変できるようにしてみるかなぁ？
通信性能の悪い機種はそこで通信間隔を空けるように調整して、問題無い機種は100ms単位でもバンバン通信できるようにしてみようか……
→ 調子に乗って100ms連続送信してみたらFLEAZ F4はほぼ無反応（取りこぼしというか詰まった？）に、LeMax2でも全く応答できなくなってしまったので、やはり少なくともAndroid端末から100ms単位で連続して通信続けるというのは無理があるっぽい。
（LeMax2ではビジーとかエラーのログが出てこないのでAndroidとU.F.O. SAのどっちがアップアップなのか見えてこないのだが、いずれにせよ100ms単位の連続はよっぽど恵まれた環境か、もしくはU.F.O. SAのコントローラーの限界で無理ということに結論付けられそうです）
結局、最小通信間隔は200msに据え置くのが無難、って感じかな？
2019-12-08個人メモ追記：
しかし、LeMax2はカスタムROMのせいかもしれないが、イヤホン端子が無いのでUSBに純正付属品のイヤホン端子変換ケーブルをかませてリモコン付きイヤホンを繋いでみるのだがほとんど正常な動作をしない。
画面を消したら無反応だし、画面が出ていても正しくボタンを判定してくれない。
音楽再生アプリでも同じような反応で、別機種では全く問題が無いため、LeMax2のAEXが悪いか、そもそもイヤホンリモコンは使えないかのどちらか。
FLEAZ F4はAndroidバージョンが古く、UfoSaCtrlがメディアボタン対応していないので（画面付いてるときは反応できるんだけど画面オフ時に反応できなきゃ意味半減だよね）、
通信エラーの少ない機種ではリモコンが使えないという残念な個人環境なのであった。
とちくるってFire7とFireHD10（両方セールのうえに2台買うと\2,000引きだったので、Fire7は\1,280相当という破格値）をポチってみたので、これがどうなるか試してみたい。
どちらもMediaTekだが、どうなるか？
また、これら2台はGPSが付いていないので、（一見UfoSaCtrlに無関係に見えるが、実はBLEデバイスを探索するときに位置情報アクセスの権限が必要とされてしまう（AndroidOSの規制上）ので、若干関係があるのだ）どうなるのか見てみたい。
あ、あと、基本的には動いているのですが、きっちり想定通りに動けているかどうかを判断するのには結構時間が掛かりそうなので、もしかしたらベータ版を一発リリースするかもです。