doubledepth

BMS vs Screensaver pt2

手元ですぐに調べられる範囲のみ・Windows 10環境のみの簡易的な調査。

• nanasigroove1でScreensaverが発動すると強制終了する。
• Angolmois, BananaBeats, IIDXView/HDX, LR2, Pulsus, QMSは、Screensaverが発動しない。
• unofficial nazobmplayの場合、Screensaver発動時点で一時停止し、復帰時に一時停止状態が解除される。復帰後も正しくscrollingし、音声も破綻しない模様。
• BM98kでScreensaverが発動すると、選曲画面でも演奏画面でも「yGetKeyStateに失敗！」というmessageが表示され、強制終了する。
• ruv-it!の演奏画面でScreensaverが発動すると、音声は再生され続けるが、復帰後も描画が真っ黒の状態から更新されなくなる。
• Bemuse, raindropは、演奏画面でScreensaverが発動しても音声は停止せず、復帰後も演奏画面が音声と同期している。
• Feeling Pomu 2ndでScreensaverが発動すると、音声は停止する。復帰後は画面の描画が更新されず、しばらくすると強制終了する。
• Delight Delight Reduplicationの場合、演奏画面でScreensaverが発動すると実際にその時点でPause状態になる。復帰後も0 keyを押下するまではPause状態が維持される。

Delight Delight Reduplicationは当時からEvent modeを想定されていただけあって、一時停止まわりの実装にも抜かりがない感じで凄い。

尾籠なの

就寝中に股間に熱が籠ると高確率で悪夢を見る。横になって数時間で碌に眠れないまま飛び起きる日々に疲れ、自分なりに頭寒足熱の発展形を模索した。まず試したのがこう。

1. 肩から下腹部までをcomforterなどで覆う。
2. 男性器を露出する。
3. 太股半ばから足の爪先までを別のcomforterなどで覆う。
4. 眠る。
5. 数時間後、心臓に痛みを感じて飛び起きた。

これはおそらくあやうく死ぬところだった。男性器を露出したまま眠ると睾丸だけでなく足の付け根まで冷やされて、一晩中オナクール状態に陥る。OnaCoolとは鼠蹊部を冷やしながら行う自慰の本邦における俗称であり、一説によると最高に気持ちが良いらしいが、普通に考えて心不全一直線では？

1. 肩から太股半ばまでをcomforterなどで覆う。
2. 太股半ばから足の爪先までを別のcomforterなどで覆う。
3. 眠る。

これはうまくいった。男性器を丸ごと曝け出すのではなく、上半身用comforterと下半身用comforterの間の僅かな隙間から冷たい外気が流れ込む程度に按配したのが良かったようだ。

適度な寝返りは健康の証拠といわれているが、私は寝返りを打つ前に目が覚めてしまう。普通なら寝返りを打つことで筋肉の緊張をほぐしつつ「腹部を暖め睾丸を冷却する体勢」を自動的に維持しているものと思われるが、そのような高度な能力を持っていない私は一年中腹巻きを標準装備している。

BMS vs Screensaver

Windows 8以降でuBMplay実行中にscreensaverが起動すると、screensaverから通常の画面に復帰してもuBMplayの描画が更新されなくなる。uBMplayを再起動すれば直る。これはWindows側ではなくGraphics DriversやGraphics Cardsとの相性の問題かもしれないが、私はそれについて詳しく知らない。

Windows 10でしか確認していないが、Toy Musical 3（nanasigroove2）もscreensaverを挟むと描画が更新されなくなる。STANDARD MODEのSTAGE 4まで到達して次でグリークミソロジーREMIXが出現する……なんてときに選曲画面をactiveにしたまま💩に出かけてはいけない（戒め）

mBMplayはscreensaverを挟んでも問題なく描画される。Viewer apps実行中にscreensaverが起動しうることそのものが、しいていえば問題といえば問題かもしれない。

nanasigroove2やmBMplay以外のplayable BMS appsについて、私は後日調べるつもり。

BGM行数

“浮遊城 -Living City #E6BBAD-”の#105–#107小節区間のBGM列136–140行目に未定義notesがある。このBMSをBMSEで開くと前述のお遊び要素は削ぎ落とされるが、曲自体はBMSEを通しても変わらない。

小節あたりのBGM行数が33本より多いBMS（BMSEで開くとBGM情報の一部が確実に欠損するBMS）は、BOFXVでは80枚以上存在したようだ。PABAT!だと“Wild! West! Showdown!”が100行、“Into the CORE”が97行。G2R2018の“Antinomy”が99行。

小数っていうか分数ならわかるやで

BMSの小節長と#STOP sequenceに関しては、値を分数で表記する形が本来的だと思うんですよね。

• #xxx02:7/4は「4分の7拍子」に相当する小節長さ。
• #STOP01 1/4は「4分音符1個分」に相当する停止時間。

みたいな感じで。分数は五線譜由来の拍子記号の延長としても読めるし、拍子分母がbeat indicatorへの参考情報となるなら「拍の見立て」の問題を解決する糸口になるかもしれないし、分数はおおむね整数のまま計算できるから計算機のよくわからない事情に付き合わずに済むし。

#STOPから#SCROLLへの変換を考える

停止時間（音符単位）を実際の距離（音符単位）に置き換えて引き伸ばせば変換できる。ものぐさな私は_wsh_bms2bmson.jsを流用して手元で_wsh_stop2scroll.jsをでっちあげたが、この方法は賢くない。BMS形式のまま#STOPを#SCROLLに変換すれば、誤差が小節外に出ないので、Blackcityとかは私の変換結果よりは美しく正確に変換できるだろう。（というか#SCROLLなら疑似停止中も音声や映像を再生できるのだから、Blackcityの元譜面のように#STOPの金太郎飴を仕込む必要性がそもそもない。Blackcityを#SCROLL化するなら、現状の元譜面の#STOPを愚直に#SCROLLに置き換えていくよりも、planeplain譜面に#SCROLLを足していくほうが、簡単かつ正確に仕上がるに違いない）

#STOPを#SCROLLに置き換えることの利点は可搬性が高まること。#SCROLL譜面は#STOP/#SCROLL非対応機種上でも曲が破綻しないので、BmsONEとかに持っていきやすく便利。LR2だって小数値#STOPの金太郎飴とか駄目じゃん。

小数値#STOPもよくわからない。必要ではあるんだろう、とは考えを改めたけど。

nanasigroove2

I need drag-and-drop

DraggableなBMS appsは、Chart editer appsやFiler appsと連携することができる。複数のsoftwareを気分や用途によって使い分ける私にとって、Drag-and-Dropは真っ先に有無を確認したい特徴。

（私が試すと強制終了するけど）nanasigroove2も一応draggableではある。私がToy Musical 3を遊ぶ理由は元々はPlayers一覧やEvents一覧の調査のためだった。フロシュトランスの譜面がTM2から変更されていないなら#EXRANKはsupportされている可能性が高いし、リンカネーションEXのn2s filesizeを見る限りでは#RANDOMもsupportされていそう（未確認）。でも実際のところは不明。

余談ですが「BMS毎に完全に独自の個別の設定を持つことができる」方式を支持します。

ToyMusical3 KeyConfig

Toy Musical 3 Ver.2.93用の非公式GUI KeyConfig。将来的には公式からもkeyConfig用のappsが公開される可能性はありますが、当座を凌ぐには十分以上に役立ちます。XMLを編集してkeycodeをごちゃごちゃ指定するよりは遥かにわかりやすいと思います。既定のZSXDCFVGB配置とASDF␣JKL;を軽率に行き来できるようになり大変ありがたいです。

ウチらもそろそろhttpsオンリーにしますかね

ネコ将の迅速な対応によってHTTPS化されて既に6年は経つはずですし、ありがたいことです。というか常時HTTPS化せざるをえない圧もありますけどね……。外部からいまだにHTTPで参照されがちなのが気にはなりますが、HTTPSにredirectされるようになればそのへんも時間の問題でしょうし。

Webpage管理者としてはContent Security Policyが悩ましいんですよね……、2010年代の当site配下の文書は既におおむね作業を終わらせたはずですが、それ以前の文書についてCSP要件を自力で満たすのは精神的にかなりきつい……

めちゃくちゃ寝たのに一日中眠い

寝すぎて後頭部の奥のほうに鈍痛さえあるのに眠い。なんだこれ怖……

http://www.bmsoffighters.net/*およびhttp://bmsoffighters.net/*がhttpsにredirectされるようになったので、当siteからの参照先をどちらもhttps://bmsoffighters.net/*に変更しました。当日記がPHPを使いだす以前の文書に関しては例によって触ってないといいますか触る覚悟がないといいますか、なので例によって変更が及んでおりませんが悪しからずご了承ください。

あっあとBMSE非公式Help関連も前述のURLへの参照を持ちますが、それらについては他のいくつかの修正点と併せて後日改めて更新します。

続・BMSのText Encodingに関して（BMX2WAV v2）

BMS fileの中身はほぼASCII文字だけで構成されているので、いわゆるLegacy Encodingを高い精度で自動判別するのは難しいのではないかと考えます。実際、ああああ氏の“Green Greens -ﾄﾘｵｼﾞｬｽﾞﾊﾟｰﾃｨｲmix!!-”をText Editor appsで開いたら半角カナゆえか韓国語判定された経験があります。

一方で2010年代にreleaseされたBMS関連appsの多くが「Byte-order-markつきのUTF-8 encoding」をsupportしています。BMS形式のままで穏便に多言語化する方法はこれしかないんじゃないかな〜と思われるので、従来のANSI CodePageに加えて「BOMつきUTF-8」だけでもsupportしていただけると、あとはuser側で対処することも難しくなくなりそうなのでありがたいです。「System Localeが何であれ、BOMがあればBOMに従う」で大丈夫ではないでしょうか。「UTF-8のBOMがついたShift_JIS BMS」とかも見かけた記憶がありますが、それはさすがにBMS側の責任ですし。

Toy Musical 3の「とある楽曲が出現しなくなる現象」、ちらっと調べたら“AVALON”っぽい。music folderを覗いたところ、攻略wikiの楽曲解禁に載ってない曲が8曲見つかった。BOF2009関連っぽいけどBOF2010の曲もあり、よくわからない。いまのところwikiの分と合わせると全239曲？

BMSのText Encodingに関して

“AND•OR•XOR•NOT”はBMS filesのpathだけが問題でしたが、音声や画像がNon-ASCII filenamesだった場合はBMSのText encodingまで判別しなきゃ駄目でした。Pathだけでいけるものと早合点して無茶な要望を投げてしまいました……🙇

日記を書きながら寝落ちしかけているので続きは後日に……

Rhythmの丸めに関して思い出したこと

div192	div160

BM98k330r42でHI-SPEED optionを適用しないとき、4分の4拍子小節は160 pixelsの長さで描画される。

この160 pixelsの小節上に、「Notesを192分音符間隔で192個敷き詰めた4拍子小節」を表示すると、「Rhythm座標が(6n+1)/192のnotes」は「Rhythm座標が6n/192のnotes」と同一のy座標に描画される。画像左でいうと鍵盤1とScratchは同時押しに見える。実際は同時押しではないので、DJ AUTO氏はきちんと192分音符1個分ずらして演奏してくれるが、鍵盤1とScratchのどちらが先でどちらが後なのかを人間が見分けることはできない。

では小節を160等分するrhythmは1 pixel間隔で描画されるのかというと、そんなことはなく当然のように座標が丸められmoiréが発生する。この場合は見た目のみならず曲の鳴り方まで丸められてしまう。

BMSのみならず五鍵盤beatmaniaにも、たしかFrame rate関連で同じような話があったはず。Bossa Novaだったかの譜面で微妙に曲と異なる表示上のズレが生じるんだっけ？　いま眠すぎてどこで見かけた話なのか思い出せないけど……

Toy Musical 3 v2.93

Computerの新調に手間取っていた私はBOFXVをまるっと見逃し、今回初めてユーフォリックハードスタイルを遊んでめちゃめちゃ感動した。曲も譜面も最高だった。なんの音を同時押ししているのかよくわからないまま叩かされる状況は個人的にとても苦手なんだけど、この曲に限っては5 buttons譜面から順に追っていけばなんとなく許せてしまう感じ。あとvocalを高域成分だけ叩かせているのは元からなのか差分屋の仕事なのかよくわからないが、それやっちゃっていいんだ……みたいな驚きがあった。いや〜これ遊べたから今日はもういいやって感じ。すごい満足。超楽しい。最高。

あとトラッピーハードコアのANOTHER MIXだったか、8分音符だったかで継ぎ目なしのLongNotesで左端から右端まで二重階段で駆け上がるやつ、あれも楽しかった。あれってたぶんぽっぽん専用controllerだと「左手→右手→左手→右手→左手」って北斗強制されるやつでしょ。ユーフォリックハードスタイルのHYPER/EXも腕移動が楽しそうな感じだったし最高。

BMX2WAV v2 Core TEST ( 2020/05/04 )

BMSのdrop起動によってpathが自動入力されるようになり、BMX2WAV Searcherなどのfiler appsとのsynergyが高まった。ありがたや。

依然NeedFix扱いではありながらも、小数値#STOPも値通りの停止時間が反映されるようになった。たとえば“Gérard”の変換結果は、2020/05/01版の変換結果よりも16分音符15個分ほど長くなる。

分解能については、最終的に44100個/秒の要素に丸めることが決定されている状況なら、仰る通り「丸めた結果として重なってしまう要素はエキストラチャンネルに追い出す」くらいしか思いつかないかな……。「丸める前の段階で既に重なる要素」さえ潰せていれば普通に解決できそうな気もするけど、私は何か勘違いしているかもしれません。

AND•OR•XOR•NOT\INSANE 20\AND•OR•XOR•NOT_Insane.bmsなどのUnicode pathも扱えると（ことにWORLD WARが控えている最近は）嬉しい。BMX2WAV 1.3.3はWindows 98以降で動作するいわばANSI版だから、Windows 7以降専用っぽいBMX2WAV 2系がUnicode版になってほしい……　と思ったけどWindows 10ならSystem LocaleをUTF-8に変更すれば普通に変換できるのだった。

画像を眺めていて、ランダム構文選択ダイアログにもResizerがついていても良いかも、と思った。

BMX2WAV v2 Core TEST ( 2020/05/01 ) その2

以下、所感や、書くだけ書いてみた要望など。

• Tree Viewを眺めている時間さえも「変換時間」に加算されている気がする。
• 「対応する ENFIF が存在しません。」
• BMS fileをbmx2wav_x64.exeにdropして起動したとき、INPUT/OUTPUT欄に適切なpathが自動補完されると嬉しい。

BMX2WAV v2 Core TEST ( 2020/05/01 )

GUIが整備され、変換状況やErrorsの有無が視覚的に分かりやすくなった。BMX2WAV v2がerrorなく変換できるBMSは、高水準の互換性が保証されている。また、#RANDOM分岐構造も可視化された。

「BGA チャンネルの行は読み込みを無視する」が有効なら、Blackcity_spa.bmeは余裕で変換できる。（「BGA チャンネルの行は読み込みを無視する」が無効の場合、bmx2wav_x64.iniにUsableMemoryMegaByteSize=22528（22 GiB）以上を指定しておく必要はある）

Memory制限値22 GiBでもどうにもならなかったのが“Widow’s kiss”で、変換できたfileはwk_unique1truc.bmeのみ。他はMemory制限を軽々と突破する。一番やばい小節は#071で、BMX2WAV v2でいうところの小節分解能としては理論上207903035340とか585439446900とかが要求されるはず。しかし、bmx2wav_x64.ini内のBarResolutionMaxにそれらの値を指定して保存し、bmx2wav_x64.exeを起動して、何もせずにBMX2WAVを閉じると、BarResolutionMaxの値が1323894644に変更される。2桁足りない😢

さらに、前述の“Widow’s kiss”は、#STOP sequenceの値として小数値1.5を用いている。小数値の停止時間はDelight Delight Reduplicationの#STOP sequence仕様に違反しており、LR2は小数部分を切り捨てるはず。つまりLR2上では#155は図表著者の意図した経過時間よりもわずかに短くなるはず。BMX2WAV v2の場合は以下のようになるはず（当環境では到達できない処理工程だけど）。

NeedFix : 指定されたストップシーケンスの表記が不正です。ヘッダ名 STOP05
Warning : STOP05 は指定されなかったとします。
NeedFix : ストップシーケンスでヘッダに未設定のオブジェクトが使用されました。 小節番号 : 155  オブジェクト : 05
Warning : ストップシーケンスはなかったとします。 小節番号 : 155  オブジェクト : 05

同作者氏の“Gérard”も小数値#STOPを用いる。“Widow’s kiss”と異なりWAVへの変換は難なく行えるが、小数値#STOPが無視されることによる影響はこちらのほうが大きそうだ。

“スーパーイザナギオブジェクト”の[Sran Happy Decoration]差分（『第9回』からdownload可能）、LR2でS-RANDOM optionを適用して演奏するとあちこちで可視notesが増殖するという互換性をかなぐり捨てたgimmick。たとえばこんな感じ：

#08311:0M0000000000000000000000000000000U000000000000000N000000000000000Q0000000000000000000000000000000O000000000000000P000000000000000V000000000000000O000000000000000000000000000000000000000000000000000000000000000V000000000000000W000000000000000O00000000000000
#08311:0M0000000000000000000000000000000U000000000000000N000000000000000Q0000000000000000000000000000000O000000000000000P000000000000000V000000000000000O000000000000000M00000000000000000000000000000000000000000000000V0000000000000000000000000000000000000000000000
#08311:0M0000000000000000000000000000000U000000000000000N000000000000000Q0000000000000000000000000000000O000000000000000P000000000000000V000000000000000O000000000000000M0000000000000000000000000000000Q000000000000000V000000000000000W000000000000000O00000000000000

あと未定義の#WAV1BでのびのびとKARAOKE LongNoteしていたり、変換器向けではない感じ。

十年前の拙作例（100層の入れ子の分岐）を、BMX2WAVでerrorが発生しないように修正した。当時は「最初からBMSEで上書き保存された状態のほうが、迂闊な自分にとっては気が楽だなあ」とか思って、#WAVや#BMPの定義群を意図的にglobalに放り出したような記憶がある。でも演奏時にmemoryを無駄に消費しない作りのほうがusersに友好的であることはいうまでもなかった。

_wsh_bms2bmson.js v0.2.5

• ImageMagickのversionを検証する関数がpreReleaseVersionを誤判定していたのを修正。