errorを発して起動しなくなったなんでじゃ。前日には普通に起動してたでしょ。Playerをuninstallして、類似Q&Aの通りに残留物を削除し、再度installしてみたけど、症状は改善せず。Driverおよびその他いくつかのfilesは12.5のものが使われていた。いうことは、Kernel部分とかは特に内容が変わってはいなかったということだろうか。modeでしか起動できない。Toolsもinstallできない。玄人ならこの状態からでもどうにか対処するのだろうけど、私は一時間粘って無理だったので諦めた。......と日記を書いているうちにどうにかできそうな方法を思いついたので、明日はそれを試そう。10のみになるらしいし、今のうちからHyper-VやVirtualBoxに移行しておくべきかもしれない。問題を無事に解決できた。OSをsupportしていないことが判明した。私の目的を達成できそうな仮想環境はVirtualBoxしかなさそうだ。以下の現象はbugや不具合にはあたらないけど、噛み合わせが悪い感じ。areaにUnicode文字列を表示します。Localeに準じて復号されます。textとは無関係の、まったく異なる内容として解釈されます。Localeで符号化されます。Localeが表現できない文字」を用いたBMS図表をBMSON形式に変換するなら、いまのところ以下の手順が安全と思われます。fileを、図表著者が意図したであろうencodingで「開く」(これはWindowsメモ帳とかでは無理です。wxMEditやMeryなどの「encoding変更機能を持つtext-editor」が必要です)。「図表著者が意図したであろうencoding」に関しては、変換者自身が推測しなければなりません。encodingを指定して別名保存する。fileをBmsONEにdropし、encoding選択肢で“UTF-8”を選択する。BOMの有無を問わず、必ず“UTF-8”を選択しなければなりません(“Default”や“Shift-JIS”ではなく)。Number”と書いてあって驚く)や、#DEFEXRANKなどが実装されました。私の環境では、log.txt内にCP932とUTF-8が混在し、その結果として必ず文字化けします。chunksに対して厳しめに警告を出力します。sRGBなどと警告されます(GameData\Skins\default\Evaluation\)。0.2.1をもう少し触ってみる。キーボード24鍵盤】が選択肢に現れなかったり、いろいろ困った。古い版とその設定を消し、再度BmsONEの設定を行った。filesへの関連付けもやり直した。import機能に関して、最初の「テキストエンコーディング」がいきなり難問。Localeのencodingが一致しない状況ではうまくいかない。no.070)や、filenameのみ韓国語の図表などは、文字化け不可避。他のtext-editorsとの併用が必要。Localeが適用される。Localeで復号されてしまう。Localeで符号化されてしまう。「BOMつきGB18030」は解釈されない。932(Windows-31J)ではなく、純粋な(あるいは狭義の)Shift_JIS。半角カナなどのいわゆる機種依存文字は文字化けする。なんか、後日あらためて確認したら半角カナも「∠」も普通に表示された......。いい加減なことを書いてしまい申し訳ございません。三つ目の項目は、「BOMなしUTF-8」専用という感じ。冗長表現への対策も問題なかった。0.5.2μBMSCの改修とともに、Pulsus同梱版もreleaseされました。10に導入できない方は、このμBMSC+Pulsusを試されるとよいでしょう。PulsusはuBMplayよりも導入が簡単であるだけでなく、uBMplayよりもsensitiveなので、図表の基礎的な互換性を検証する目的でも役に立ちます。Pulsusは、#xxx[1-6]7(FREEZONE)に出くわすと強制終了します。Playなどのmaniacなmodeをsupportしていないので、それらの拡張的な図表をpreviewするならPulsus以外のviewerが必要です。私はuBMplayとの併用をおすすめします。PulsusはBMSON用のviewerとしても役立ちます。Notesが実装されました。0.2.1BMS形式の図表fileをdropすると、BMSON形式に変換してくれるようになりました。複雑すぎるrhythmを変換すると、応答なし状態に陥る場合もありますが、「BMSEが扱えるrhythm」を変換する限りでは問題は発生しません。BMSON形式に変換された図表は、以下のような利点を享受できます。新たなpartにKEY音の役割を担わせたくなったときに、図表著者は音声を裁断する必要がありません。(もちろん従来型BMSの方法の通りに実際に音声fileを丁寧に切っても構いません。)同時押しに説得力を与えたくなったときに、図表著者は音声を実際に合成する必要がありません。Noteという仕組みを持っているので。)新たな音声や映像を追加したくなったときに、図表著者は定義数を気にする必要がありません。「分岐(=実行時まで確定できない内容)が存在しないこと」が仕様によって保証されるので、実装次第ではBMSON図表の読み込み時間はBMS形式よりも高速化されうる......かもしれません。#999を超過するような長い図表も表現できます。差異による文字化け」が無くなります。BMSON形式に変換することによる不利益をあえて挙げるなら、BMSON図表はLR2では遊べません。十年前のsoftwareといえど、IRはまだ代替がありません。「複雑なrhythm」の表現精度は、BMS形式よりもやや劣ります(とはいえ実用上問題なさそうではあります)。Long)が撤廃されれば無制限に精度を確保できますが、BmsONEやbeatorajaはその道を選ばないでしょう。editorではありません。そのようなgimmickはBMSE/iBMSC/μBMSCのほうが得意です。#RANDOM分岐・不可視notes・地雷もないので、それらを使いたいならBMS形式を選びましょう。LAYER画像の仕様が多少変わります。BMS形式とBMSON形式で同じresourcesを使いまわし、尚且つ両形式で同じように描画させたい図表著者は、ちょっとややこしい工夫を求められる場合があります。FIELD以降を小文字にしてからBmsONEに投げると、変換結果が変わります。lanesを画面内に収容しきれない場合、水平方向へのscrollingができないようです。Softwareにblockされている状態なので、10分間ほどしか試行錯誤できていません。するとscrollするための方法が用意されていて、それを私が見落としているかもしれません。pathに関する仕様を誤解していた事を懺悔する初見で誤読したまま今日まで勘違いを引き摺っていた。いつもながら私は阿呆そのものだった。specification普通に考えれば「『BMS/BMSON図表が置かれたfolder』から外部への参照を一切許さない」という制限が最も安全なので、引用箇所は「絶対pathも親directoryへの参照も受け入れてはならない」と解釈するのが自然だ。私はなぜだか、もっと面倒くさい実装を想像してしまっていた。filesの"name"に関しても、同様の制約が課せられるものと思われる。pathに関して私が面倒に感じていた問題は9割がた消えてなくなる。ServerがWebDAVに対応しているらしい。私のaccountのpasswordを思い出すか変更する機運が高まり次第、また試してみます。pathを定義する必要性がいまいちわからない。思うことがあって検索すると、やはり「攻撃経路としてのWebDAVの悪用」という話も可能性としてはあるようだ。私の素人codingでは複雑なfilepathに対処しきれないことを思い知ったので、「filepathが期待される値」の先頭が“\\”や“//”なら一律で諦めることにした。“\\?\”はこれを知った今ではむしろ推奨したいくらいだけど、BMSとはご縁がなかったということで。十日かけていろいろ調べた結論がこれかぁ......BMSE非公式Helpを今週中に更新したい。“BGAのススメ”移転・uBMplay20170913・μBMSCなど。machine越しにnanasigrooveで再生できた。Folders”はshare-nameに相当する。host-nameは[RFC3986]に従うとされている。"~"だけが使用を許されている。pathとして解釈する。Directory(cd)として設定される。D:\上のどこかに存在する場合に限り、参照されうる。(32-bit)だそうです。machinesのうち一台に直撃していました......。痛恨の一撃を食らった直後の今回の出来事でした。一回の清掃でC:\の容量が全体の1⁄5ほど空くこともあって、私は未だに現役でお世話になっており、このsoftwareが使えないととても辛い。悪意ある改竄者は惨たらしく爆発してください。Accessibility確認用toolとしては最適という、一部の向きに猛烈に愛されるbrowserです。Headerからencodingを直接指定するしかありませんでした。今後はそのような不毛な作業から解放されます。.この指定に関して訂正します。nanasigrooveほかいくつかの実装は、commandとvalueの分離符として「連続する空白類文字」を許容します。.そして、後者の指定ならnanasigrooveのみならずuBMplayでもLR2でも鳴ります。STOP」をtrimしますが、file-nameやfolder-nameの先頭側の空白はtrimしません。STOPを挿入することができます。それらを以下のようにBMSから参照すると、普通に参照されます。kick.wav”です。以下の指定は参照されません。実際の名前は先程の例と同じです。promptなどを経由しても不可能のようでした。Pathの複雑怪奇な仕様を大雑把に把握できたと思います。Path文字列を正規化する際の方針が定まったので、ようやくcodeの続きが書けそうです。(Windows)自分用備忘録。Pathの拡張として“\\?\”や“\\.\”という接頭辞が定義されている。脱線するけど、「drive名つき相対path」なる代物についても私は初めて知った。separatorとして"\"のみが許容され、"/"は禁止される。STOP’も禁止される("./"や"../"は不正)。APIに自動的に訂正される箇所」が、書かれている文字列の通りに解釈されるようになる。separatorsの連続("\\\"や"///")」も禁止される。MAX_PATHに関する制限が取り払われ、UTF-16換算で32767文字までpath文字列が指定可能になる。(UNC)と併用する場合は“\\?\UNC\”接頭辞を用いる。networkなどで使うらしい。pathは“\\PCname\sharedFolder\bms.bmp”とかになるらしい。device名前空間にaccessする。"\\.\COM10"とか。COM0とLPT0は予約語ではないにもかかわらず、explorer上で件の名前に変更しようとすると「指定されたデバイス名は無効です。devices関連”らしい。Wikipediaにも例あり。日本語解説だとこのへん。D:..\image\layer1.bmp”のような「drive名つき相対path」が指定されたとして、これはどのように解釈するのが妥当なんだろうか。(cd)、Windows日本語版の語彙における「作業フォルダー」とは、そもそもどこを指しているのか。D:\\\\foo.///bar\../..\\..///.\..\.\kick.wav#00111:0102030405前述の例はWindows上ではすべて同一のfileが参照されうるが(訂正:#WAV03は除く)、Unix系OS上ではすべて異なるfilesとして解釈されるはず。OSとの互換性を保つために、filenameを明示的にcase-insensitiveで解釈していた。図表著者の期待通りに図表を再生するために大文字小文字の同一視を要求する、そんな図表はBMS形式が生まれた頃から大量に存在するので、大文字小文字の同一視はほぼ必須要件といっても過言ではない。必要ならどこまで許されるのか?以前の日記で挙げた#BMPの多重定義例に関しても、前述のそれと同様の難しい判断が求められる。すくなくとも文字列の層だけで多重定義だと判定できる箇所に関しては、codeを修正しなければならない。Programmingにおいてfilepathは基本中の基本だと思うけど、いきなり躓いている......後日記事に訂正と追記あり。半透明に対応できないので東方音弾遊戯7の方は若干残念な感じに・・・。layersは元からえいやっと感が目立つ素材でしたし、透過されるべき箇所(RGB:0,0,0)は完璧に透過されていたので、「uBMplay上ではこの見え方が正常」と受け止めました。BMS/BMSONにおいて、透過PNGの減色をためらう理由はもはやなくなりました。Square-”から“ABC”を変換すると、手元版ではこんな感じ。JScriptが出力される。透過PNGへの変換は各自で行う形。現在は図表fileの同位にresourcesが存在する状況しか想定していない。WSHならFileSystem関連関数で解決できる?「自前で」が面倒くさすぎる。oggdec.exe並に軽量な、command-lineから透過色を指定できて透過PNGに変換できるsoftwareがあれば多少はましだけど、ちょっと探した感じではImageMagickとかいかつい感じのやつしか出てこない......現在はWindows以外のOSを想定していない。ExplorerやFirefoxでdirectory関連操作をsupportするのは私には難しすぎる。階層文字列の解析は後でやるとして、画像の変換は各自でお願いします、でいいかな。定義名まで勝手に変えておいて放り投げるというのは行儀が悪すぎるけど。uBMplay>PNGをPNG-8形式に変換すると、uBMplayが強制終了します。ファイルを読み込んだときに強制終了していたようです。修正版を作ってみたのですがいかがでしょうか。問題なさそうならそのままサイトの方で公開しようかなと思います。http://ucn.tokonats.net/imagedll_20170911.zipああ〜そうですね、PNG-8というよりBPPが原因だったようです。微妙に当てにならないmemoで申し訳ございません。BPPに修正されていました。修正版DLLを私が確認した限りでは、問題を二つ見つけました。減色済み透過PNGが正しく描画される場合もありますが、結構な頻度でどこかが変になります。これは私が使用した減色PNGに問題があるのかもしれませんが、私にはよくわかりませんでした。page下部『当素材を使用したBMSはこちら。』)の、動画へのLAYERが映像著者の期待通りには透過されないようです。"keyboard-24k"の仕様を探していて、「#RANDOM分岐やencoding変更にも対応する、BMSからBMSONへの真っ当な変換器」が実装されていたのを見つけました。私のα版を使うのではなく、BmsONEの将来版を通してBmsONEに最適な形で変換することを強く推奨します。Cases”に対処しました。LongNote区間内に長さ0のnotesが紛れ込んでいた場合、変換器がそれらを削除します。"y"座標を基準として、配列要素を昇順で並べるようにしました。filesizeを更にminifyできて良いのではと思いました。いまのところ省略できないのはCircularRhythmだけだし、CircularRhythmは専用の図表しか認識しないので、事実上省略可能と考えてもよさそうではありますが。2017-09-08beatorajaとμBMSCが更新されていたので私も便乗した#RANDOM系には対応しません。分岐構造をBMSON形式で表現するのは難しそう。“∂○ν○ゞ<俺が衆議院に襲来だ!!!!”など、変換後BmsONEで編集できない図表もあります。↑の図表は#WAV01で未定義の番号を参照しています。0.5でも期待通りに音声が再生されます。“BlackCity”のように一部の画像がBASE部とLAYER部で共有される場合、本来は変換時に、1LAYER用にそれらを新たにcopyして、2copiesをPNGに変換し、3それらにalpha-channelを与え、4それらを新たな"id"に別名で定義し、5参照しなおす必要があります。notesの種類が一括指定されます。不可視notesや地雷に関しても、構文解析して選り分けるところまでは一応やっています。[以下、2017年9月9日追記]不可視や地雷を含む図表の変換に失敗していたのを修正。450FLANの値を取得できていなかったのを修正。これはcharatbeatHDX拡張の「Float型を明示するoption」を実装しようとしてやめた名残でした。座標の最小間隔がPulse単位量1を下回らないように、縮小率の下限を再設定しました。今までもそのようにしていたつもりでしたがそうなっておらず、結果として前述の450FLAN図表などを変換した際に"duration"の意図せざる重なりが発生していました。2017-09-06BMSONの"bga"に関して画像によるanimationを、BMS図表とBMSON図表で同じように表示させるのは、予想外に難しいようです。0.5.1で再生した結果は以下の通り。BASEとLAYERの画像が合成されて描画されること」を我々は期待しますが、BMSON版ではLAYERの黒色部分が透過されないまま映像が進んでいきます。映像は作者が意図したものにならず、全編を通してほぼ真っ黒の状態になってしまっています。)BMSON仕様はalpha-channel以外の透過処理をもはや規定しません。BMS形式の図表だけをBMSONに変換しても、#xxx07(LAYER)は著者の期待通りには描画されないかもしれません。Pulsusやraindropは、「BMS形式の“BlackCity”」であればLR2やbeatorajaと同じように映像を表示します。前述の動画の表示例は、Pulsusが各書式仕様に準拠した結果ともいえます。このBMSON図表をBmsONEで編集する際、拡大率が変なら最初にCtrl+0を実行するとうまくいきます。拍分解能を24000以下に抑えた図表ならBmsONEが扱える可能性がありますが、“∂○ν○ゞ<俺が衆議院に襲来だ!!!!”は"resolution":14512まで肌理(きめ)を粗くしても無理でした。LAYER用の画像はすべてPNG化したうえでalpha-channelを指定する必要があります。それだけではまだうまくいかないかもしれません。DREAM”をBMSON化して検証した際に発生した現象がこちらです。skin特有の現象で、BMSONとは無関係でした。元のBMS図表とBMP画像の組み合わせでも同じ表示になりました。表示内容の互換性について最善を尽くすなら、BGA基底部やPOOR部に用いられる画像のsizeも均す(ならす)必要があります。fileが複数の"id"を持つ場合、playerは後方の"id"を採用し、警告してもよい」。40_MiB.webm#00104:01#01604:02#03204:03Resourcesを無駄に読み込みうる書き方はmobile激おこ、ということかも。Wizard的な定義整理が求められるでしょう。あと、暗転用の未定義#BMPはBMSON仕様では禁止されているし、未定義の"id"を参照するBMSON図表はbeatorajaを強制終了させます。前述の透過処理に関する仕様も考慮すると、#xxx04および#xxx06から参照される「未定義の#BMP番号」は、ひとつに集約されなければならない。その番号に対して、「暗転用の画像(alpha-channelなし)」をあてがう必要がある。#xxx07から参照される「未定義の#BMP番号」は、ひとつに集約されなければならない。その番号は#xxx04・06用のそれとは別でなければならない。集約される番号に対して、「暗転用の画像(alpha-channelあり)」をあてがう必要がある。いう感じなので、特にこだわりがないなら動画に変換するのが面倒がなくてよいと思います。複数枚の画像によるanimation形式を維持したまま見栄えをBMSON図表に移植するには、これまで述べたような多少込み入った手間と注意深さが要求されます。複数枚の画像によって映像を構成することに関して著者が特にこだわる理由を持たないなら、変換対象たるBMS図表の映像は事前に一本の動画にまとめておくのが手軽でよいと私は思います。「未定義"id"の参照がBMSON仕様で禁止されている」と書きましたが、それは私の勘違いでした。透過PNG作成さんなどでfolderと色番号を指定すれば、画像素材は透過PNG形式に一括変換できます。LAYER以外の画像まで透過すると、環境次第では悲しい見栄えになります。透過部分や透過率を任意に指定したい場合は、もう一手間(ひとてま)必要です。PNGをPNG-8形式に変換すると、uBMplayが強制終了します。20170911版以降のuBMplayは強制終了しません。今後は減色された透過PNGもがんがん使っていけます。PNGを過度に最適化すると、描画がうまくいかなくなる場合があります。Chunksを一括削除すると、互換性がやや向上します。flag}BMSON仕様によれば"x"はany型なので、FREEZONEを"x":-1や"x":"FREEZONE"などに隔離しても問題ないはずですが、実際に-1に変換するとやっぱりPulsusが強制終了します。2017-09-02BMSONの巨大な座標に関して“∂○ν○ゞ<俺が衆議院に襲来だ!!!!”のBeginner図表(syugiin_89_B.bms)を、scrolling関連要素のみBMSON形式に変換してみました。試行錯誤する過程で得た知見をmemoしておきます。書庫も含め訂正があります。複雑なrhythm#084–#106、および#122は、いわゆる「BMSEで編集できないrhythm」を含んでいます。384BMSON型の大域分解能方式ではなく、小節単位で座標をparseしていく方式の場合は、#087の296822738051520を処理できる精度があれば良さそうです。ない場合は次節を参照。大きすぎる数値(BMSON仕様違反)拍分解能649204422624492997583698071949318733307465961776128654502095560800総小節長125.984375最大座標327158453726330439969834847132959809166131128112557833828149781670650小節分解能と総小節長の積を、BMSON図表内"y"座標の最大値と仮定しています。野球君さんのこの図表におけるそれは約3.2715845372633043e68(三無量大数)、仕様違反です。座標を受け入れてくれるようです。40000を完全に忘れていました......。正しくは以下の通り、「最後の小節線の座標」よりも停止時間のほうが大きくなります。拍分解能649204422624492997583698071949318733307465961776128654502095560800総小節長125.984375最大座標327158453726330439969834847132959809166131128112557833828149781670650停止時間541003685520410831319748393291098944422888301480107212085079634000000後述のいくつかの誤りは、停止時間のpulse換算値を考慮していなかったのが原因でした。引用符で括られた数値(BMSON仕様違反)JavaScriptは大きすぎる整数を正しく扱えません。数値型のままだと入出力の際に誤差が生じうるので、私は暫定的に数値を文字列化して出力しています。型が異なる値は仕様違反です。BMSON仕様に準拠する図表が期待通りに再生されるとは限らないChart-editorsが巨大な座標を管理するのは、見るからに難しそうです。仕様に準拠する図表が正しく再生されない状況は他にもあります。前述の書庫内の最小の図表は、元の座標を59桁shiftして、さらに4で割って丸めたものです。59桁shiftするだけでは、beatorajaでは再生されませんでした[Note]。これは、桁shift時に前述の停止時間が4294967295を超えていたこと(それを私が見落としていたこと)が原因だったようです。beatorajaは仕様通りでした。Pulsusが桁移動するだけで再生された件が謎。そんな事実はなく、Pulsusも仕様通りでした。私が寝ぼけていただけでした。↓:BmsONE実装ごとに許容される座標の上限が異なるので、gimmickyなBMS図表の完全移植は諦めるしかなさそうです。巨大な数値も引用符で括られた数値も受け入れてくれるBemuseに私は賭けたい。普通に仕様に従って4294967295を上限とすれば、「だいたい合ってる」水準までは達成できそう。0.4.3において、上限は4294967295ではなく、2147483647でした[Note]。BananaBeatsも、座標2147483648を読むと、result画面が出なくなります。CircularRhythmはPromise関連のerrorが出ていますが、よくわかりません。座標を縮めた結果、#106の"stop_events"の予期せぬ合体が発生しています("y":695189736と"y":697353751が複数ある)。縮小による改竄を避けたいけれど、よい方法を思いつきません。これは私が座標算出時に小節長を考慮し忘れていたからでした。そもそも縮小によるmoiréを抑えるようにcodeを書いたはずなので、こんな現象が発生する時点で他の原因を疑うべきでした。あと、変換された"bpm_events"を眺めていて疑問に思ったことがあります。charatbeatHDXのようにBPM変更を視覚化する機種において、図表を彩るとか、そういう発想かしら。Properties。