BMS apps:
このドキュメントは便宜的に以下の略称を使用します。 (公称とは異なる可能性があります。)
BMS command memo (JP)
- latest update:
written by hitkey
- web: https://hitkey.nekokan.dyndns.info/
- mail: hitkey0801[at]hotmail.com
references:
about BMS: https://en.wikipedia.org/wiki/Be-Music_Source This report referred to: https://web.archive.org/web/*/http://wiki.bms.ms/Bms:Spec BMS Format Specification: http://bm98.yaneu.com/bm98/bmsformat.html () Basic specification of BML: https://nvyu.net/rdm/rby_ex.php BMS extensions proposed by Sonorous: https://cosmic.mearie.org/f/sonorous/bmsexts ( から) (参考資料として) DTX file format specifications: http://dtxmania.net/wiki.cgi?page=qa_dtx_spec_e (参考資料として) Guide to understand BMS format: https://cosmic.mearie.org/2005/03/bmsguide/ () (参考資料として) Angolmois Internals: https://github.com/lifthrasiir/angolmois/blob/master/INTERNALS.md () (参考資料として) about obsolete MGQ notation: https://web.archive.org/web/*/http://ivy.pr.co.kr/rdm/jp/extension.htm () (参考資料として) LR2beta3 スキンcsv仕様書 第五版: http://right-stick.sub.jp/lr2skinhelp.html () (参考資料として) caution:
- これは仕様書を翻訳したものではありません。これはただの私のメモです。
- 私はオンライン翻訳サービスを 100% 使用しました。
- 私は英語を理解できないので、自動翻訳の結果が正しいか判断できません。
- 翻訳がややオフでありうるので、内容は誤読されるかもしれません。
- さらに、私のリサーチは正確でないかもしれません。 (もちろん、私は誤りを書かないよう努めました。しかし内容の正しさは保証できません。)
- 上記の理由から、私はこの文書に責任を負いません。 許してね。
- 何か疑問があれば、ご自由に私に連絡してください。 誤りが指摘されれば、私は喜んで修正するでしょう。
- Font test: Segoe UI, Helvetica, Helvetica Neue, Verdana, Lucida Sans Unicode, Lucida, Arial,
update history:
- : DTXCreator 026
/ 私は
#VOLWAVをサポートするアプリケーションについて加筆した。 - : Sonorous 0.1.0-pre (2014-07-08)
- : HDX v1.05
- : BGAEncAdv v0.034
- : BGAEncAdv v0.033 / TechnicalGroove 更新停止
- : HDX v1.04
- : Mid2BMS / lr2_pmsview_helper
- : PMSee-V v2.2.2
- : HDX v1.03
- : Feeling Pomu 2nd had
#BGA,#POORBGA,#xxx0A(LAYER2) - : Angolmois Rust Edition () / nanasigroove2 beta (Toy Musical 3 Ver.2.2) / PMSee-V v2.2.1′
- : Extended BPM / STOP Sequence
- : RLE へ更に加筆 (bmpfmt.htm) / 大きなビデオについて加筆
- : 私はダウンロード可能な MacBeat を発見した。
- : 以下の項目に加筆: RLE
/ ファイル名によるグループ化 (
*.lr) /#BGAの互換性 (bemaniaDX) - : [old] mainori-se.sakura.ne.jp/dtxmania/ -> [new] dtxmania.net/
- : Angolmois Rust Edition (2014-01-26) / Sonorous 0.1.0-pre (2014-01-31)
- : HDX v1.02
- : HDX v1.01 / bms diff tool
- : リンク切れを修正 (BMS Viewer, in_bm) / LR2SkinHELP
- : Sonorous 0.1.0-pre (2013-11-18)
- : Sonorous 0.1.0-pre (2013-11-13) / iBMSC 3.0.5
- : Sonorous 0.1.0-pre (2013-10-13)
/ multi
#SUBTITLE/ multi#COMMENT - : Sonorous 0.1.0-pre (2013-10-09)
- :
私は
#DEFEXRANK nに TechnicalGroove カラムを加筆した。 / 私は PMSee-V v2.1.5a () を見逃していた (すまぬ…すまぬ…) - : 私は ビデオの巻き戻し について加筆した。
- : Be-Music Helper (beta 4′) / woslicerIII (2013-09-22)
- : Be-Music Helper (beta 4) / Sonorous 0.1.0-pre (2013-09-17)
/
#OPTIONの全ての値の列挙 (option.htm) - :
Angolmois 2.0 e5cea53a2cbd (SDL 2.0.*) (fixed:
#BGAの互換性) - :
#DEFEXRANK 0/ 副題によるグループ化 / multi#SUBARTIST/ fractional#STOP/ multi#LNOBJ/#BGAの互換性 - : [old] bit.sparcs.org/%7Etokigun/article/bmsguide.php -> [new] cosmic.mearie.org/2005/03/bmsguide/
- : HDX v1.00 / Sonorous 0.1.0-pre / BGAEncAdv v0.032 / TechnicalGroove
- : 私は HDX / IIDXv が 広がるキャンバス をサポートしていたことに気がついた。
- : 私は HDX / IIDXv の Indent style が強化されていたことに気がついた。(U+3000)
- :
私は 間違いの実例 に
＃ENDIF(U+FF03) を加えた。 - : uBMplay 1.5.2 / 広がるキャンバス に BM98 を追加
- : 私は
#PATH_WAVに uBMplay を加えた。 - : uBMplay 1.5.1
/ 私は woslicerII の URI を修正した。(remove “soft/index.html”)
/ uBMplay 1.5.0 は
#OCT/FPを知っていた。 - : 私は BmDx を追加し、bemaniaDX の略称を変更した。
- : Angolmois Rust Edition
- : woslicerIII / 広がるキャンバス に追記
- :
<hgroup>is gone - : IIDXv 2.14, PMSee-V 2.1.3a
- : HDX 0.99 /
#99902:1/ multiple#xxxA6/#RANK nの既定値に関する誤った記述を修正 - : PMSee-V 2.1.3
- : uBMplay 1.5.0
- : Angolmois 2.0 77ce3b6e2761
/ 私は
#ExtChrの誤りを修正した。 - : Angolmois 2.0 798422870970
(fixed:
#LNTYPE 2) - : Angolmois 2.0 alpha 2 9880e98d15f8
- : Angolmois got alpha-blending
- : 私は文字列のエスケープについて Comment syntax に加筆した。
- : HDX 0.98, PMSee-V 2.1.2, nanasi2 1.0, IIDXv 2.13, PMChr-V 4.0.2, Angolmois 2.0 alpha 2 pre
- : HDX 0.97, PMSee-V 2.0.2, nanasi2 0.4, いくつかのデッドリンクを修正
- : HDX 0.96, PMSee-V 2.0.1a, PMChr-V 4.0.0
- : nanasi2 0.3
- : iBMSC 3.0.4
- : HDX 0.94, iBMSC 3.0.3 / 私は「FREE ZONE」へ BMSV と nBMplay を加えた。
- : HDX 0.93
- : PMSV 1.10.5, nanasi2 0.2, IIDXv 2.12, HDX 0.92,
#ELSEIF, Indent style, Comment syntax, Keyup-sounding - : PMSV 1.10.4, PMCV 3.1.0, nanasi2 0.1, SMB 1.03
- : ruv-it! 2.0 b5p7 test #7
- : Be-Music Helper (beta 3)
- :
私はこの文書の HTML に関する大量のバグを修正した。
- :
私は
#TOTALの項目を修正した。 (thanks to kisama) - : 私は iBMSC 3.0 の最新版を反映することを忘れていた。 私はそれに関して付け加えた。
- : 私はすべての見出しにパーマリンクをセットし、さらにいくつかのアイテムを追記した。
- : 私はこの文書をアップデートした。 修正箇所が多すぎて、私はそれらを思い出せない。
- : 私はこの文書を日本語化した。 私のゲシュタルトは崩壊した。
- : 私はこの文書を HTML 化した。 ファイルサイズは 4 倍になった。
- : 私はこの文書を書き終えた。 私はプレーンテキストを単に <pre> タグで括った。
- : 私はこの文書を書く気分になった。 私は書き始めた。
- : DTXCreator 026
/ 私は
BMS Format Specification に関するメモ
示されている最小限の要求仕様について:
仕様の要約:
- このファイルフォーマットは、1998 年に、Urao Yane と NBK によって考案されました。
- 誰でもこのフォーマットを自由に使用することができます。
#から始まる行はコマンド行です。 残りは全て無視されます (コメント用)。- コマンド行は大文字小文字を問いません。
- コマンド行にはヘッダー文とチャンネル文の 2 種類があります。
この BMS ファイルは実行時にコンパイルされます。したがって、私たちはいかなる行も自由に命じることができます。
- 引用者注: つまり、ヘッダ文は BMS のどこにでも記述できます。
- 引用者注: ヘッダ文は必ずしもチャンネル文の前に記述されるとは限りません。
しかし、仕様の詳細は実装に依存します。
- 例えばいくつかの実装は、特殊なケースにおいて大文字小文字を区別します。
e.g.,
#LNOBJ XX - 小文字の <HEADER> をまったく認識できない実装も存在します。(O2play)
- 例えばいくつかの実装は、特殊なケースにおいて大文字小文字を区別します。
e.g.,
仕様が示さない詳細な実装について:
ヘッダ文は、コマンドと値を分割するデリミタとして、1 個の半角空白を使用します。
#header value=#+header+␣+value- いくつかの実装は、デリミタとしてタブ文字も使用できます。
- いくつかの実装は、連続するホワイトスペースを、デリミタとして許します。
- いくつかの実装は、ホワイトスペースによるインデントを許します。
- それらの特徴をサポートしないいくつかの実装は、BMS の解析を誤るかもしれません。
チャンネル文は、コマンドと値を分割するデリミタとして、1 個の半角コロンを使用します。
#xxxCH:00112233=#+xxx+CH+:+00+11+22+33xxx: 小節番号 [000-999]CH: チャンネル番号00,11,22,33: 2 文字の英数字のペアから成る、各オブジェクトに対応するインデックス。初期: 16 進数 16*16 (256) [0-9A-Fa-f][0-9A-Fa-f] 中期: 限定 36 進数 16*36 (576) [0-9A-Fa-f][0-9A-Za-z] 現在: 36 進数 36*36 (1296) [0-9A-Za-z][0-9A-Za-z] - いくつかの「インデックス」から成る値は、等間隔で小節を分割します。
- 4 つのインデックスが記述されれば、小節は 4 等分されます。それは「4 つの四分音符」というリズムを指定したことを意味します。
00は休符です。00以外のインデックスが指すものは、各チャンネルに依存します。 それは#WAVxxか#BMPxx、あるいはそれ以外かもしれません。
譜面ファイルは本質的にプレーンテキストです。 拡張子
TXTがBMSに変更されれば、BMS アプリケーションは譜面を認識するでしょう。- BMS ファイルのエンコードを仕様は示していません。 この事実は、DBCS が改竄される問題を引き起こします。 (mojibake)
- ほとんどの日本の BMS ファイルは Shift_JIS で書かれています。 https://en.wikipedia.org/wiki/Shift_JIS
多くの日本の BMS アプリケーションは多言語のエンコードをサポートしていません。
BMS コマンドの値が DBCS を含んでいる場合、 値は改竄されるかもしれません (mojibake)。
しかしながら、OS が日本語版 Windows である場合、 Shift_JIS で書かれた DBCS はたまたま正しく表示されます。
- ファイル名やディレクトリ名が DBCS を含んでいる場合、 BMS アプリケーションは誤動作するかもしれません。 しかし日本語版 Windows では、Shift_JIS で書かれた DBCS のパスは、たまたまうまくいきます。
- 日本語版 Windows では、JIS (ISO-2022-JP) や EUC-KR で書かれた BMS が、LR2 や BMX2WAV に不具合をもたらした例が知られています。
- すべての実装にとって安全な文字集合は ASCII (ANSI) だけです。 私たちは、少なくともファイル名とディレクトリ名に対しては、DBCS を使用するべきではありません。
ruvit, iBMSC, IIDXv (2.13+), HDX (0.98+), Sonorous, BGAEncAdv, TechnicalGroove は多言語のエンコードをサポートしています。
- しかしながら、それは、文字列が正確に表示されることを保証するわけではありません。
UTF-16 が BMS の主流になるまでは、文字が改竄されうる問題は避けられないでしょう。UTF-16 が普及したとしても、この問題は完全には解決されません。- YEN-SIGN problem, WAVE-DASH problem, WON-SIGN problem, GB_18030, etc...
一般的な実装の挙動:
同一のヘッダが重複する場合、EOF に近い側が採用されます:
remarks sample BMS code (line number 100) #TITLE ABC(line number 200) #TITLE DEFこの BMS の
#TITLEの値は “DEF” です。- このルールは、
#ExtChr,#STP,#WAVCMD,#OPTION, および制御構文を除く、あらゆるヘッダに適用されます。 - このルールは、
#SUBTITLE,#SUBARTIST,#COMMENT, および#LNOBJに適用されないかもしれません。 - このルールは、チャンネル
#xxx02(小節長) にも適用されます。 - ただし
#xxx02が重複した場合、ruvit (b5p3 以前) は最初の行を採用します。 (b5p4 にて修正済み)
- このルールは、
しかしながら、以下のコマンドは例外であり、多少複雑な処理が要求されます。
これらは同一のコマンドを複数行記述することができます:
#ExtChr: [BM98] Extended Character#STP: [bemaniaDX] ストップシーケンス#WAVCMD: [MacBeat] MOD もどき (MOD とは: https://en.wikipedia.org/wiki/MOD_%28file_format%29)#OPTION: [nanasigroove] 強制オプション#SUBTITLE: [nanasigroove] 明示的な副題 / [Sonorous に限り、多重定義可能]#SUBARTIST: [LunaticRave] 助力者情報 / [TechnicalGroove と Sonorous に限り、多重定義可能]#COMMENT: [feelingPomu] 選曲画面上の字幕 / [Sonorous に限り、多重定義可能]#LNOBJ: [Rhythm-it] ロングノート終端定義 / [TechnicalGroove に限り、LN 終端音声を複数定義可能]
制御構文はさらに特別です。BMS の記法では、以下に示すコマンド群だけが、ブロック構造を構成します。
#RANDOMor#SETRANDOM#IF#ELSEIF#ELSE#ENDIF
#ENDRANDOM#SWITCHor#SETSWITCH#CASE#SKIP#DEF
#ENDSW
同一の小節で同一のチャンネルが重複する場合、両方が合成されます。
- しかしながら、この挙動は
#xxx01(BGM channel),#xxx02(小節長),#xxxA6(#CHANGEOPTION) には適用されません。 - 複数行の BGM は、複数行の BGM として解釈されなければなりません。それらは合成されてはなりません。
- 複数の
#xxx02チャンネル行が競合する場合、EOF に最も近い行が採用されます。 - 動的オプション変更チャンネルは、複数のオプションを同時に変更可能にするために、BGM チャンネルと同じ性質を持ちます。
- しかしながら、この挙動は
行番号が大きい側が優先されます。 しかし、
00は古い場所を上書きしません:remarks sample BMS code comment (行番号 100) #00113:11111111// 1100110011001100(行番号 200) #00113:0022332255224400// #001のチャンネル13が重複(行番号 300) #00113:0066// #001のチャンネル13が重複構文解析の結果: #00113:1122332266224400// 3 行分がすべて合成される これは複雑なリズムを書きやすくするために用意された、BM98k の挙動です。
- (最終的に合成される前提で) 行を分割して記述するテクニック は、とても興味深い表現を可能にします。
- 最も徹底的にそれを成し遂げた作品は オートメーション工場 (http://www.comeup.info/bofoon2007/automation.zip) です。
- 最も控えめにそれを成し遂げた作品は Netzwerkgenen (http://manbow.nothing.sh/event/event.cgi?action=More_def&num=39&event=76) です。
しかしあいにく、実装の約半数はこの仕様を満たしていません。 ( ... そもそもこれは 「要求仕様」 なのでしょうか ? )
- チャンネル行の重複を考慮しない実装は、オブジェの数を正確には数えられないかもしれません。
pomu2 にはオブジェの配列を自動的に変更する機能があります。
しかし、チャンネル行が重複する場合、この機能は正常に動作しません。
(元の譜面を 5 回重複させた例: https://hitkey.nekokan.dyndns.info/100418_duplicate_channel_pomu2.png)
- LR2 には pomu2 に似た機能があり、それは同様のバグを持っています。 LR2 は、重複した地雷チャンネルをうまく処理できません。
BMS パーザは、3 種類の改行コードが混在するファイルを読まなければならないかもしれません。 (CRLF, CR, LF)
- For example: Sofa $15 -> $1
BMS パーザは、改行を間に挟まない EOF を読まなければならないかもしれません。
- For example:
#08401:ZZ[EOF]
私たちは、予想よりも多くのインライン EOF を見つけるでしょう。
- For example:
不正な値が与えられたチャンネル行を、どのように解釈するべきか、仕様は定めていません。
sample BMS code remarks #00111:0011文字2233// DBCS の混入 #00112:0011223// 2 の倍数でないデータ長 #00113:+-;$%&'()/// #WAVのインデックスに使用できない特殊文字#00114:1100...(over 500000 characters)...011// 長すぎるデータ長 #00115:11 ;comment// DTX のインラインコメント (GDAC2 は正しく解釈できない) #00102:12.375f// IIDXv と HDX の float 型明示オプション #00121: FFFFFF OOOOOO OOOOOO NNNNNN #00122: FF OO OO OO OO NN NN #00123: FFFFFF OO OO OO OO NN NN #00124: FF OO OO OO OO NN NN #00125: FF OOOOOO OOOOOO NN NN// アスキーアート (https://en.wikipedia.org/wiki/Shift_JIS_art) いくつかの実装 (nazo, uBMplay, LR2, etc) は、これらの解釈を試みます。 その方法は不明です。 「適切な解釈」の定義も不明です。
BMS パーザは、以下のようなヘッダ文を読まなければならないかもしれません。
sample BMS code remarks #stopA 192// 定義番号のゼロサプレス #stop11 -192// 負数の値 #stop22␣// 空の定義スロット (デリミタつき) #stop33// 空の定義スロット (デリミタ無し) #if⇥ 4// タブ文字のデリミタ #bpm 2.147484e+0.9// 指数表記の値 #bpm99 12.375f// IIDXv と HDX の float 型明示オプション (BMSE は強制終了する) #WAV60 ura_63.wav// 実際のファイル名は
ura_63..wav(http://www.comeup.info/bofoon2007/automation.zip)
#bga01⇥ fz␣512␣␣256␣␣768␣␣384␣␣0␣␣␣64␣␣big.bmp// 複数のタブ文字や半角スペースによる値レイアウト #bmp字 big.bmp// 定義番号が DBCS #random 10 ⇥ #if 1 ⇥ ⇥ #wavZZ foo.wav ⇥ #else ⇥ ⇥ #wavZZ bar.wav ⇥ #endif #endrandom// 複数のタブ文字や半角スペースによるインデント いくつかの実装は、有効な値として上記を許します。
しかしながら別の実装は、これらを無効値とみなします。
モダンな実装は、1295 (1296) 種類のスロットをサポートしています。
各ヘッダの値は [01-ZZ] (あるいは [00-ZZ]) のインデックスに定義されます。
- 小節は 3 桁の数字で表されます。
一般的な実装は [
#000-#999] をサポートしています。 いくつかの例外と注意点:
apps remarks BMSV [000-511] DDR [000-998] bemaniaDX [000-399] GALLI [000-399] BGAenc [000-249] BMEV BMEV は #000にしか内容が無い譜面を開くと強制終了します。RDM RDM は #000にしか内容が無い譜面をスクロールすることができません。GDAC2 GDAC2 は #170以降で「貼り付け」を行うと強制終了します。 (Ver.0.20 にて修正済み)LR2 可視オブジェまたはロングノートオブジェが
#000の先頭に存在するなら、 LR2 は#000の直前に、#000と同じ長さの空小節を挿入します。(これは、ゲームスタート時にユーザを当惑させないようにする方法のひとつです。)
この機能は便利ですが、もしオブジェクトが
#000と#999に存在する場合、譜面は正常に終了しません。pomu2 キー音が鳴っている間は、pomu2 は譜面を終了させません。
しかし、譜面が
#999を過ぎてもまだキー音が鳴っていた場合、pomu2 は強制終了するでしょう。otama otama のドキュメント (https://www.asahi-net.or.jp/~VG5M-OBT/otamadoc.html) によれば:
小節の最大数は 1024 です。
しかし、この記述は奇妙です。
#1024xxはバグを引き起こすでしょう。MyO2 382. [ニコニコ動画] 組曲 は、譜面が完走する前に強制終了します。 これは小節数とは関係がないのでしょうか？
下記はエラーメッセージの引用です。文字化けした部分は省略しました。
TypeError: Error #1010: A term is undefined and has no properties. at ::scorenum/()[E:\popstage_5key\com\scorenum.as:44] at ::scorenum/setNum() at ::o2jam/()[E:\popstage_5key\com\o2jam.as:2951] at ::o2jam/()[E:\popstage_5key\com\o2jam.as:2630] at ::o2jam/()[E:\popstage_5key\com\o2jam.as:3056]
BMS フォーマットの譜面のファイル拡張子について
大要:
典型的な拡張子は次の通りです。
注意: これらの拡張子の由来については様々な見解があるので、私は責任を持つことができません。 これらは略称というよりむしろ通称です。
- 近年、これらの拡張子は単にほとんど後方互換性のために存在します。
- 譜面が必要とするチャンネルを持たない実装は、拡張子によってフィルタされます。
- モダンな実装はこれらをすべてサポートしているので、フィルタリングの必要性は衰えました。
モダンな実装なら、私たちはすべての譜面の拡張子を BMS に変更しても構わないのです。
(ただし 9KEYS では、私たちは拡張子を PMS (*.pms) に変更しなければなりません。
そうしなければ、fgt++/fgt# は BMS-DP (10KEYS) として譜面を表示するでしょう。 LR2 は、BME-SP 型の 9KEYS を単に BME-SP として表示するでしょう。)
しかしながら、Windows エクスプローラで譜面を探す場合などに、拡張子は有用です。
- “5K is BMS.”
- “7K is BME.”
- “LN is BML.”
- “9K is PMS.”
BMS の文脈を知っている人々にとって、この命名を理解するのは簡単です。
(これらは、誤解を含んでいますが、分かりやすい要約です。)
これらに加えて、BMS 由来のフォーマットが存在します。 詳細は http://itkhps.web.fc2.com/bmsk.html を参照してください。
- MGQ: ロングノートチャンネルを使用する 24KEYS BMS。 “Music Game Quest” は KEYBOARDMANIA もどきを考案しました。
- MBM: MacBeat MOD.
#WAVCMDを使用した BMS 譜面は、拡張子を MBM に変更しなければなりません。 - EMS: AngelicPianizm タイプの 24KEYS BMS。 KbMediaPlayer (bmse.kpi) は今なおこのフォーマットをサポートしています。
- KMS: KeyMani タイプの 24KEYS BMS。
- BAS: BMS-2 Format (BM-A4 & beat arranger 拡張)
- PHX: PHOENIX タイプ (詳細不明)
- MGF: beatmaster [standard] タイプ (詳細不明)
- BMB: beatmaster [bms] タイプ (詳細不明)
- PMB: beatmaster [ドレミマニアタイプの PMS] (詳細不明)
- D2B: beatmaster [D2R] タイプ (詳細不明)
- DEE: (詳細不明)
近年これらはほぼ見かけません。しかしながら、以下のフォーマットはオリジナルの発展を遂げ、そして今なお発展の過程にあります。
- DTX: DTXMania (DrumMania の高度な発展形)
- GDA: BandJam (GuitarFreaks & DrumMania に似たタイプ)
- G2D: SessionStream (GDA 拡張)
- GFS: Guitar Friends 98
DTX シリーズの詳細は公式サイトを参照してください: http://dtxmania.net/wiki.cgi?page=qa_dtx_spec_e
- 譜面ファイルの典型的な拡張子については、次のセクションで詳述します。
BMS:
BMS は beatmania の模倣をその起源とするものです。 (https://en.wikipedia.org/wiki/Beatmania)
それは 5 つの鍵盤 (x2) と 1 つのターンテーブル (x2) を持ちます。
- 歴史的経緯:
-
: beatmania が稼働しました。
: Urao Yane は 「Be-Music Data Format」 草案を NBK に提示しました。 これが今日の BMS フォーマットの基礎です。
: NBK は、Urao Yane の草案に基づいてハウスミュージックの譜面ファイルを作成し、 それを Urao Yane に提出しました。
: ゲームセンター 「チルコポルト」 で開催されたオフ会において、Urao Yane は BM98 ver 1.00 を示しました。
: Urao Yane は 彼自身のホームページ を作成し、BM98 ver 1.03 をネット上で公開しました。
: Kazutoshi Takata は BMS Viewer Version0.8 を公開しました。
: Urao Yane は BM98 の公開を一時的に停止しました。
- この経緯について Urao Yane 自身が書いた文書: ゲームラボ (発売の書籍) にて公開された原稿
- 様々な理由が混乱を引き起こしたので、Urao Yane は 1999 年に BM98 の公開を永久に停止しました: “今後のＢＭ９８活動のあり方について”
: TIX は BMS Creator v0.02.02 を公開しました (改版履歴)。 ...私たちは、ついにテキストエディタから解放されました。
: Urao Yane は BMS Format Specification を示しました。
| origin | BM98 |
|---|---|
| support | BMS の全実装 |
| header |
#PLAYER n,
#GENRE string,
#TITLE string,
#ARTIST string,
#BPM n,
#MIDIFILE midiFilename,
#PLAYLEVEL n,
#RANK n,
#VOLWAV n,
#WAVxx audioFilename,
#BMPxx imageFilename,
#TOTAL n,
#RANDOM n,
#IF n,
#ENDIF,
#ExtChr SpriteNum BMPNum startX startY endX endY [offsetX offsetY [x y]]
|
| channel |
#xxx01-06,
#xxx11-17,
#xxx21-27,
#xxx31-36,
#xxx41-46
|
各ヘッダの詳細は別項にて。
| number | object to change | remarks | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#xxx01 |
BGM | #WAVxx に定義したファイルを、自動的に鳴るべき音声オブジェクトとして配置します。 |
||||||||||||||||
#xxx02 |
小節長 |
|
||||||||||||||||
#xxx03 |
BPM | オブジェクトとして配置した [01-FF] は、[1-255] の整数 BPM として解釈されます。 00 は休符です。 |
||||||||||||||||
#xxx04 |
BGA-BASE | #BMPxx に定義したファイルを、正常なプレイ中に表示されるイメージオブジェクトとして配置します。 |
||||||||||||||||
#xxx05 |
Extended Object | #ExtChr に定義したオブジェクトを配置します。 BM98 だけがこれをサポートします。 |
||||||||||||||||
#xxx06 |
BGA-POOR | #BMPxx に定義したファイルを、ノート見過ごし時に表示されるイメージオブジェクトとして配置します。 |
||||||||||||||||
#xxx11 |
1P-side KEY1 | #WAVxx に定義したファイルを、プレイヤーが演奏するべき音声オブジェクトとして配置します。 |
||||||||||||||||
#xxx12 |
1P-side KEY2 | 同上。 つまり #xxx1n は、演奏するべき音符のためのレーンです。 |
||||||||||||||||
#xxx13 |
1P-side KEY3 | 同上。 1P 用の譜面は、スクリーンの左側に表示されます。 | ||||||||||||||||
#xxx14 |
1P-side KEY4 | 同上。 KEYs は、鍵盤型デバイスが持つ、5 個のボタンです。 | ||||||||||||||||
#xxx15 |
1P-side KEY5 | 同上。 プレイヤーは譜面の指示に対応する KEY を打たなければなりません。 | ||||||||||||||||
#xxx16 |
1P-side SCRATCH | 同上。 #xxx16 はターンテーブルを回すことにより演奏されるべきノート用のレーンです。 |
||||||||||||||||
#xxx17 |
1P-side FREE-ZONE |
|
||||||||||||||||
#xxx21-27 |
2P-side Visible object | 右側のプレイヤーが演奏するべきオブジェ。
|
||||||||||||||||
#xxx31-36 |
1P-side Invisible object | 不可視オブジェは表示されず、判定されず、スコアに計上されません。 これはキーに割り当てられた音を別の音に変更するために存在します。
|
||||||||||||||||
#xxx41-46 |
2P-side Invisible object |
|
BME:
beatmaniaIIDX は、7 個の鍵盤 (x2) と 1 つのターンテーブル (x2) を持っていました。 (https://en.wikipedia.org/wiki/Beatmania_IIDX)
- 歴史的経緯:
-
: beatmaniaIIDX が稼働しました。
7KEYS をサポートするため、BMS の拡張フォーマット Project2DX が、Urami によって提案されました。
- このフォーマットは、チャンネル
#xxx21を「7KEYS mode における 1P 側 KEY6」として使用します。 - このフォーマットは、チャンネル
#xxx22を「7KEYS mode における 1P 側 KEY7」として使用します。 #ExtChrを用いることによって、譜面は、BM98 の視覚的なアイテムを直接的に変更します。 つまり、 5K-DP を 7K-SP のように表示します。- これは、譜面側が本体側の表示を変更する、7KEYS もどきです。 本質的に、それは完全に BMS と同じものです。
Project2DX には多くの問題がありました。
#ExtChrは BM98 の独自拡張です。 BM98 以外の BMS アプリケーションが次々に現われた時、このフォーマットは可搬性の問題に直面しました。- Sevenize 用の情報を、譜面それぞれが持つ必要がありました。 この形態はカスタマイズには適していますが、一時しのぎに過ぎません。
#ExtChrの仕様は最低限のメモだけでした。Sevenize への道はプログラマにのみ拓かれました。このフォーマットは、7KEYS のダブルプレイ用の譜面をサポートすることができません。DP がサポートされたのは事実ですが、私はそれに関する詳細を見つけることに失敗しました。
BMS の拡張フォーマット FlashTerminal が、Tomohiro Fujii によって提案されました。
- 7KEYS 用に、BMS の予約チャンネルを使用する方法が考案されました。(
#xxx18-19,#xxx28-29) - 私は、このフォーマットに関するこれ以上の詳細を知りません。
7KEYSを完全にサポートするために、BMSの拡張フォーマット BME が、TIX によって提案されました。
- BME は、FlashTerminal のチャンネルと BMS のチャンネルを統合し、BMSC で編集できるようにしたフォーマットです。
- 従来の実装が拡張チャンネルをサポートする場合、新しく設計を変更することが必要になります。
- 設計を変更しない実装が「拡張チャンネルを使用している譜面ファイル」を読まないよう、拡張子を BME に変更する規則が定められました。
- このフォーマットは、チャンネル
- もともとは:
-
厳格な BME は、BMSC がサポートしない特徴を含みません。 (via http://nekomimi.name/66_log2006.html#06/02/14)
BMSC で編集できないコマンドを譜面が含んでいる場合、拡張子 BME を使用することは不適切です。
For example:
#STOPxx n,#BPMxx n,#WAV01-FZ,#BMP00-FZ,#BGA00-ZZ,#xxx51-69, etc.しかしながら、拡張子を BMS にするよりは BME にしたほうがましでしょう。 なぜなら前述のコマンドは広義の「拡張」ではあるからです。
- 引用者補足:
-
前述のコラムの結論は: 「BMS と BME を峻別する意味はもはやありません。」
私は彼の見解に同意します。 拡張コマンドは既に自然なものだからです。
また、拡張コマンドをサポートしない実装はもはや使用されないからです。
さらに、BMSC は基本的なコマンドである
#RANDOMをサポートしませんでした。「厳格な BME」は、BMS の完全な上位互換ではありません。 私は、起源や辞書的な意味へのこだわりは無意味であると判断しました。
ところで、私は 7KEYS の代名詞として BME を適切に使用することに反対ではありません。それは厳密ではありませんが、「厳格な BME」より有用です。
| origin | BMSC | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| support | BM98, BM98k, BMSV 以外のすべて | ||||||||||||||||||||||||||||
| header | BMS のコマンドに加えて、ほとんどの実装は以下の拡張コマンドをサポートしています。 (これらがサポートされていることは、BME のレギュレーションとは無関係です)
多くの実装が |
||||||||||||||||||||||||||||
| channel | BMS のチャンネルに加えて、ほとんどの実装は KEY6 と KEY7 をサポートしています。
多くの実装が |
BML:
EZ2DJ は、5 個の鍵盤 (x2), 1 つのターンテーブル (x2), 2 個のエフェクタボタン (x2), 1 個のフットペダル (x2), およびロングノートという特徴を持っていました。 (https://en.wikipedia.org/wiki/EZ2DJ)
- ロングノートについて:
-
日本の BMS シーンにおいて、一般的にロングノートは LN と省略されます。 この文書もその習慣に倣います。
LN は、指定された一定時間が経過する間、入力状態を維持する必要のあるノートです。例えば、キーを押した状態を維持します。
各 LN には始点と終点がセットされます。 多くのゲームで、各 LN は可変長ノートとして、ちょうど長い棒のように表示されます。
プレイヤーに要求される動作は、譜面が倣うゲームの文脈に依存します。
LN は入力状態を保持する操作ですが、別のゲームは高速に入力を繰り返す操作を要求するかもしれません。
本家のゲームでは、LN に対して別の名前や特徴が与えられるかもしれません。 いくつかの典型的な種類は以下のとおりです:
formal name the first appearance remarks ロングノート : Ez2DJ THE 1st TRACKS 始点で keydown して、それを保持してください。
ロングノート : KEYBOARDMANIA 始点で keydown して、それを保持してください。終点での Keyup が必要です。 キープ君 : pop'n music MICKEY TUNES 可変長ノートではなく固定長ノートが表示されます。
押されたノートは、プログレスバーのように表示されます。これは時間ゲージです。
: 太鼓の達人 長さを持つオブジェクトはすべて、連打されるべきオブジェクトです。
これは一挙動を keydown - keep - keyup に分割するシンボルではありません。
無数の keydown 動作のシンボルです。これは金太郎飴に似ています。
(おそらくこれ以降、長いオブジェの名は体を表すようになりました。)
フリーズアロー : DDRMAX -DDR 6thMIX- パネルを踏み続けてください。 終点で足を上げる必要はありません。
ステップを変更しても、四分音符未満である間は、アローは途切れません。
恐らく、「踏む」という操作を考慮して、押下判定が緩和されています。
(ある意味では、これは長押しと連打のコンビネーションです。)
一回転スクラッチ : beatmania 7thMIX 終点に達するまでに、ターンテーブルを 360°回転させなければなりません。
区間内で回された角度が 360°に近いほど、スコアは高くなります。
終点ぴったりで回転を止める必要はありません。
アナログノート : DJMAX Portable PSP のアナログパッドを回し続けてください。
入力中はコンボが増加します。 終点まで入力を継続することが必要です。
ホールドロングノート : DJMAX TECHNICA 丸い部分を終点まで押し続けてください。 途中で離すと BREAK になります。 ドラッグロングノート : DJMAX TECHNICA 指示線通りにノートをなぞってください。 軌跡が離れすぎると BREAK になります。 チェーンノート : DJMAX TECHNICA 指示線通りの軌跡とタイミングでノートをなぞってください。 リピートノート : DJMAX TECHNICA ノートの先頭部分を繰り返しタッチしてください。 チャージノート : beatmaniaIIDX 17 SIRIUS 始点で keydown して、それを保持してください。終点での Keyup が必要です。 Backspin Scratch : beatmaniaIIDX 17 SIRIUS 始点で回し始めて、それを保持してください。終点での逆回転が必要です。 ---- タッチ系 調査中 nanasi, HDX, Angolmois 以外の BMS アプリケーションは、LN の終点を判定しません。すなわち、終点での keyup は不要です。
- しかしながら、私は、この振る舞いは「点としてリズムを示し、動作に点を関連づける」という UI に適さないと思っています。
- 私見ですが、ゲームシステムが keyup を強要しない場合、LN は終点を明示するべきではありません --- なぜなら外観が直観に反するからです。
LN は、ノートの数え方に混乱をもたらします。これはプログラマおよびノーターおよび譜面コレクタにとって面倒です。
- いくつかのゲームで、LN は 1 つのノートとして数えられます。すなわち、LN のセクション (始点と終点のペアから成る) は、1 つのノートです。
- いくつかのゲームで、始点と終点はそれぞれ別個のノートとみなされます。
- 歴史的経緯:
-
: beatmania が稼働しました。 (https://en.wikipedia.org/wiki/Beatmania)
: pop'n music が稼働しました。 (https://en.wikipedia.org/wiki/Pop'n_Music)
: Dance Dance Revolution Internet Ranking Version が稼働しました。 (https://en.wikipedia.org/wiki/Dance_Dance_Revolution)
: GUITARFREAKS が稼働しました。 (https://en.wikipedia.org/wiki/Guitar_Freaks)
: beatmaniaIIDX が稼働しました。 (https://en.wikipedia.org/wiki/Beatmania_IIDX)
: Ez2DJ THE 1st TRACKS -R U Ready to Insida DJ Box?- が稼働しました。 (https://en.wikipedia.org/wiki/EZ2DJ)
: drummania が稼働しました。 (https://en.wikipedia.org/wiki/DrumMania_XG)
: pop'n stage が稼働しました。 (https://ja.wikipedia.org/wiki/Pop'n_stage)
: KEYBOARDMANIA が稼働しました。 (https://en.wikipedia.org/wiki/Keyboardmania)
: Dance Maniax が稼働しました。 (https://en.wikipedia.org/wiki/Dance_Maniax)
: ParaParaParadise が稼働しました。 (https://en.wikipedia.org/wiki/Para_Para_Paradise)
: 太鼓の達人 が稼働しました。 (https://en.wikipedia.org/wiki/Taiko_no_Tatsujin)
多くの BMS 由来フォーマットが、この時期に現われては消えました。おそらくは、LN に倣うアイディアもいくつかには含まれていたでしょう。
上記の全ゲームの譜面を包括的に表現するために、BMS の拡張フォーマット MGQ が、 2001 年に quest によって提案されました。
- このフォーマットは、チャンネル番号を 16 進数に拡張しました。 なぜなら KEYBOARDMANIA が 24KEYS (x2) を持っていたからです。
- このフォーマットは、新しく LN のためにチャンネルを確保しました。なぜならいくつかのゲームが LN を特色としたからです。
- このフォーマットは、LN の記法を定義しました。しかしながら、MGQ 形式の LN 記法は直観的でなく、書くのが困難でした。
: MGQ の問題点を解決するために、NvyU は RDM 形式の LN を提案しました。 さらに、それは RDM 1.21 に実装されました。
- これは現在の LN のデファクト・スタンダードになりました。これは MGQ を単純化した記法です。
- この記法は、MGQ が提案したチャンネルのうち、
#xxx51-69を使用します。 - LN をサポートする BMS 実装はすべて、この記法を実装しています。
- 当時の RDM は、RDM-LN および MGQ-LN の記法を識別するために、
#LNTYPEに 1 もしくは 2 を指定する必要がありました。
: RDM 1.61 は、さらに RDM type #2 として
#LNOBJ xxをサポートしました。#LNOBJ xxは、RDM 形式の LN をさらに単純化した記法です。#LNOBJ xxは、チャンネル#xxx51-69をもはや必要としません。#LNOBJとして指定された#WAVインデックスのオブジェクトは、LN の終点シンボルとして定義されます。- チャンネル
#xxx11-29に終点を配置することにより、その直前にあるオブジェクトは、LN 始点として解釈されます。 #LNOBJ xxをサポートしない実装は、この LN 終点を通常の可視オブジェとして解釈してしまいます。#LNOBJ xxをサポートしない実装が譜面を誤解釈しないように、拡張子 BML はフィルタとして準備されました。#LNOBJ xxを使用する譜面は、拡張子を BML に変更することが推奨されます。厳格な BML は、LN として
#LNOBJ xxだけを含んでいる譜面を意味します。RDM 記法のチャンネル
#xxx51-69の LN は、BML の定義には含まれていません。厳格な BML は、拡張子を BMS または BME に変更すれば、BMSC で編集することができます。 (全インデックスが 16 進数なら。)
元来、BML は BMSC で LN を編集するために定義されたフォーマットです。 したがって、厳格な BML は、BME のサブセットであることができます。
: RDM 1.7 は、
#LNTYPE 1をデフォルト値として定義しました。- このため、
#LNTYPE宣言はもはや不要になりました。 MGQ-LN を使用する場合のみ、#LNTYPE 2が必要です。 MGQ-LN と RDM-LN の両方をサポートする実装だけが、本来の意味で
#LNTYPEコマンドを必要とします。(いまのところ: RDM,
MGQ,WAview, in_bm2, ruvit, Angolmois)ruv-it! | support page から引用 (引用者意訳):
RDM と ruvit は、2 つの理由で MGQ-LN のサポートを継続しています。
- MGQ が LN のパイオニアであるため。
- RDM (1.2 以前) が一時的に MGQ-LN を使用していたため。
ほとんどの実装は、もはや MGQ-LN をサポートしていません。 できれば MGQ-LN はもう使わないでください。
#LNOBJ xxをサポートしない実装のうちいくつかは、拡張子が BML である譜面を認識します。- これは厳密にいえば BML の仕様に違反していますが、チャンネル
#xxx51-69を知らない実装に対しては有用です。 #LNOBJis BML --- それは厳密な意味で正しい。 しかしながらその正しさは、最近もはやそれほど有用ではありません。- LN is BML --- それは誤解です。 しかし、それはシンプルで、分かりやすく、実際的です。
| origin | RDM | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| support | RDM, nazo, nazoZZ, bme2wav, LR2, nanasi, ruvit, fgt++, fgt#, pomu2, uBMplay, PMSee-V, bmx2wav, iBMSC (3.0 or later), Angolmois | ||||||||
| channel | BME と同じ | ||||||||
| header |
|
| origin | WAview | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| support | RDM, nazo, nazoZZ, bme2wav, LR2, nanasi, ruvit, fgt++, fgt#, pomu2, uBMplay, PMSee-V, bmx2wav, iBMSC, Angolmois
|
||||||||||||
| channel | BME のチャンネルに加えて...
|
||||||||||||
| header | BME と同じ |
PMS:
pop'n music は、9 個のカラフルなボタンおよび踊るキャラクターを持っていました。 (https://en.wikipedia.org/wiki/Pop'n_Music)
- 歴史的経緯:
-
: pop'n music が稼働しました。
: KEYBOARDMANIA に倣ったトレーナーとして、doremimania が Koutaro Izumi によってリリースされました。
- このソフトウェアは、独自拡張として接尾辞 PMS を提案し実装しました。
- 私の推測では、この PMS は Piano-Music-Script の略です。この記法は BMS とはまったく異なります。それらは別個のフォーマットです。
- したがって、「doremimania がサポートする PMS」と、「BMS のサブセットである PMS」との間に、互換性はありません。
- 本稿では doremimania-PMS について触れません。 (doremimania の代理配布: https://web.archive.org/web/*/http://www.geocities.co.jp/Athlete-Athene/7809/frojectd.html)
: 9 ボタン (9KEYS) をサポートするため、Nekomi は feeling pomu 1.41 Test5 (ふぃーりんぐぽみゅ) をリリースしました。
- このソフトウェアは、9BUTTONS 専門です。BMS または BME の譜面は、ゲーム開始時に自動的に 9 つのラインに広げられます。
- このソフトウェアは、BMS フォーマットのサブセットである PMS を提案し、実装しました。 PMS は 9BUTTONS 専用の譜面です。
- PMS は、BMS のチャンネル
#xxx11-15と#xxx22-25を、pop'n music もどきとして表示させるための拡張子です。 - doremimania の独自拡張子として、接尾辞 PMS が既に存在していましたが、それは pomu-PMS とは無関係です。
: feeling pomu second Ver 0.60 が、feeling pomu のアップデート版としてリリースされました。 (ふぃーりんぐぽみゅせかんど)
- 公式ページ上で、Nekomi は “feeling pomu” を “ぽみゅ” と略し、 “feeling pomu second” を “みゅに” と略しています。
- pomu2 は、RDM 記法
#xxx51-69と#LNOBJ xxの両方をサポートし、拡張子 BML をサポートしました。 PMS は、フィルタとして以上に、9BUTTONS モードを強制するために必要とされます。 なぜなら 9KEYS は本質的に BMS-DP だからです。
- BMS-DP と 9KEYS を区別する方法は、拡張子以外に存在しません。
- したがって、9KEYS 専用の譜面は、拡張子を PMS に変更しなければなりません。
- さらに、PMS をサポートする実装は、拡張子が BML でなくても LN を解釈できなければなりません。
pomu2 は、18BUTTONS (PMS-DP) も提案し、実装しました。これはアーケードに存在しない、独自の特徴です。
- 18KEYS は、演奏されるべきオブジェクトとして、チャンネル
#xxx11-29のすべてを使用します。 18KEYS は本質的に BME-DP です。 - したがって、18KEYS 専用の譜面は、拡張子を PMS に変更しなければなりません。
- 18KEYS は、演奏されるべきオブジェクトとして、チャンネル
: LR2 beta3 090916 は、「譜面の拡張子が PMS である場合、解釈されるべきチャンネル」を拡張しました。
- 要するに LR2 は、BMS-DP だけでなく BME-SP も適切な PMS として解釈します。
- pomu2 は当初からこのキーマップをサポートしています。 nanasi はこのキーマップをフットペダルモードとして解釈します。
このバージョン以降、LR2 はエディタから呼べるようになりました。 しかし、編集中の 9KEYS 楽譜をプレビューしたとき、LR2 は 9KEYS 表示を適用しません。
: この問題を解決する方法が、Misty.ls04 によって提案されました。 (https://twitter.com/misty_ls04/status/431288455231193088)
: この問題を解決するために “lr2_pmsview_helper” が Misty.ls04 によって公開されました。私の記事を参照してください。
| origin | pomu | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| support |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
| header | 互換性のために、PMS は #PLAYER 3 を指定することが推奨されます。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
| channel |
|
コマンドの使用傾向
メジャーな拡張:
| command line | remarks | origin |
|---|---|---|
| channel | ||
#xxx07 | BGA-LAYER | BM98k |
#xxx08 | BPM 変更 « #BPMxx n | bemaniaDX |
#xxx09 | STOP シーケンス « #STOPxx n | DDR |
#xxx51- |
1P-side LN (RDM 記法) « #LNTYPE 1 (O2mania 以外は省略可) | MGQ |
#xxx61- |
2P-side LN (RDM 記法) « #LNTYPE 1 (O2mania 以外は省略可) | MGQ |
| header | ||
#BPMxx n | 実数 BPM 定義 » #xxx08 | bemaniaDX |
#STOPxx n |
STOP シーケンス定義 (1 は 4/4 拍子小節の 1/192 に相当) » #xxx09 | DDR |
#LNOBJ xx |
LN 終点シンボルの定義 (RDM-type #2) « #WAVxx filename | RDM |
#WAV[01-ZZ] filename | 定義番号の 36 進数化 | bemaniaDX |
#BMP[00-ZZ] filename | 定義番号の 36 進数化 | nanasi |
#WAVxx oggfilename |
#WAVxx への Ogg 定義、拡張子だけが異なる同名ファイルの代替探索 | DDR |
#BMPxx videofilename |
#BMPxx へのビデオ定義、ファイルの拡張子を除外した代替探索 | LR |
#SUBTITLE string |
註: これは「暗黙の副題 (bemaniaDX 拡張)」とは異なるコマンドです | nanasi |
#SUBARTIST string | 音スライサ、映像メーカー、ノーターなど | LR |
#DIFFICULTY [1-5] | 譜面の難易度種別 | nanasi |
#STAGEFILE imagefilename | ロード時のスプラッシュスクリーン | BM98k |
#BANNER imagefilename | バナー表示 | nanasi |
ときどき使われる拡張:
| command line | remarks | origin |
|---|---|---|
| channel | ||
#xxx99 | テキスト変更 « TEXTxx "string" | pomu |
#xxxA0 | 判定変更 « #EXRANKxx n | nanasi |
#xxxD1-D9 | 1P-side 地雷 « #WAV00 soundfilename | nanasi |
#xxxE1-E9 | 2P-side 地雷 « #WAV00 soundfilename | nanasi |
| header | ||
#WAV00 soundfilename | 地雷の爆発音の定義 » #xxxD1-E9 | nanasi |
#BACKBMP imagefilename | 譜面の背景画像の定義 | DDR |
#EXRANKxx n | 判定幅の定義 » #xxxA0 | nanasi |
#CHARFILE charfilename | pop'n music に倣ったキャラクター | pomu |
#COMMENT "string" | 選曲リストに表示するテキスト | pomu |
#TEXTxx "string" | プレイ中に表示するテキスト | pomu |
#LNTYPE 1 | RDM 記法の LN (O2mania は宣言必須) » #xxx51-69 | RDM |
%URL string | BMSC が自動的に加える | BMSManager |
%EMAIL string | BMSC が自動的に加える | BMSManager |
テストプレイで有用な拡張:
| command line | remarks | origin |
|---|---|---|
| header | ||
#PATH_WAV path | ファイル参照元ディレクトリのパスを定義 | |
#SETRANDOM n | 定数を生成 | pomu2 |
#SETSWITCH n | 定数を生成 | nanasi |
<HEADER>
#PLAYER [1-4]
| origin: | BM98 |
|---|---|
| support: | ほぼすべて |
- プレイヤーの数を定義します。
- コマンド省略時、デフォルト値として
1が適用されます。
実のところ、この値はプレイヤーの数ではなく、ゲームモードの選択です。 対応関係は以下のとおりです:
command summary gauges abbreviated name remarks #PLAYER 11P 1 guage Single Play, 1P, SP default #PLAYER 21P + 2P 2 guages Couple Play, 2P 近年、このモードはほとんどサポートされません。 #PLAYER 31P + 2P for 1P 1 guage Double Play, DP モダンなアプリケーションはセンターダブルを実装しています。 #PLAYER 41P vs 2P 2 guages Battle Play BM98 (BM98k) だけがサポートしています。 #PLAYER 2は、ダブルプレイ用の譜面を、二人のプレイヤーが同時に演奏するモードです。 これは合奏もしくはデュエットに似ています。- “Couple Play” は beatmaniaIIDX 19 Lincle () にて削除されました。
- 代わりに、「シングルプレイ用の楽譜 2 枚」を二人のプレイヤーが同時に演奏する “FREE PLUS” モードが新設されました。
- たとえば、左側のプレイヤーは “DIAVOLO (SP-HYPER)” を演奏し、右側のプレイヤーは “DIAVOLO (SP-ANOTHER)” を演奏します。
“Battle Play” は 2 つの “Single Play” を同時に行います。
- これは、二人のプレイヤーが、同一の SP 譜面を同時に演奏し、スコアを競うモードです。
したがって、
#PLAYER 1の楽譜がある場合、それはクライアント側によってプレイ・オプションでカバーすることができます。“Battle Play” のためにわざわざ特別な楽譜を用意する必要はありません。
- 仕様が無意味だったので、BM98 以降のソフトウェアはすべて、
#PLAYER 4のサポートを中止しました。 - 同様に、
#PLAYER 2はクライアント側によってカバーすることができるモードです。
beatmania の “Single Play” のプレイスクリーンは、3 カラムの静的なレイアウトです。
+--------+ +--------+ +--------+ |1P side | |movie | |2P side | |notes | |display | |notes | +--------+ +--------+ +--------+
- 左カラム: 1P 側の譜面を表示するスクリーン
- 中カラム: ムービースクリーン
- 右カラム: 2P 側の譜面を表示するスクリーン
アーケードの beatmania に関しては、この表示レイアウトは、デバイスの物理的なデザインの帰結として採用されています。
しかしながら、BMS では、必ずしもこのレイアウトでなければならないというわけではありません。
- なぜなら、PC キーボードは 2 人が同時に操作することができるようには設計されていないからです。
- 2 人が 1 台の PC キーボードを同時に使用するプレイスタイルは、もはや歓迎されません。
- つまり、“Couple Play” および “Battle Play” はもはや歓迎されません。 かわりにオンライン対戦が普及しはじめています。
BM98, BM98de, DDR, bemaniaDX, DDR, および fgt++ は、この静的な 3 カラムレイアウトをそのまま採用しています。 LR2 のいくつかのスキンも同様です。
しかし、このレイアウトは、他の実装ではほとんど見られないでしょう。
これらの理由から、
#PLAYER 2および#PLAYER 4は実装依存となっています。- たとえば、bemaniaDX は
#PLAYER 2および#PLAYER 4を#PLAYER 3として解釈します。
- たとえば、bemaniaDX は
beatmania ベースのアプリケーションは、“Double Play” を確実に実装しています。
#PLAYER 3です。- なぜなら beatmania において、DP は非常にポピュラーなゲームモードだからです。
1P 側譜面と 2P 側譜面が隣接しない DP のレイアウトは、俗に “TWIN MIX PLAY (TMP)” と呼ばれるかもしれません。
- 初期の beatmania シリーズは “CENTER DOUBLE” をサポートしていなかったので、DP は非常に困難でした。
“CENTER DOUBLE” のプレイスクリーンは、1P 側譜面と 2P 側譜面が隣接するレイアウトです。
+--------+ +--------+ +--------+ ┌┐+--------+ +--------+┌┐ |1P side | |2P side | |movie | └┘|1P side | |2P side |└┘ |notes | |notes | |display | or ┌┐|notes | |notes |┌┐ +--------+ +--------+ +--------+ └┘+--------+ +--------+└┘
ムービースクリーンは、譜面以外のスペースに表示されます。
いくつかの実装は、ムービーを複眼的に表示することができます。 (https://www.youtube.com/watch?v=FtQ8woowZiM)
“CENTER DOUBLE” は beatmania complete MIX 2 で初登場しました。 ()
したがって、いくつかの古い実装は “CENTER DOUBLE” をサポートしていません。
#PLAYERはチャンネルを束縛しないので、#PLAYER 1と#xxx21-29は併記することができてしまいます。for example: in nazobmplay: remarks #PLAYER 1 #00111:1100000000000000 #00121:2100000000000000 #00122:0022000000000000 #00123:0000230000000000 #00124:0000002400000000 #00125:0000000025000000 #00128:0000000000260000 #00129:0000000000002700 #00126:000000000000002S
レンダリングを
#PLAYERコマンドに依存する実装では、問題が生じます。#PLAYER 1なので、ゲームモードは “Single Play” が適用されます。しかしナイーブな実装は、2P 側のオブジェクトも表示してしまいます。
このバグは、いくつかのユーモラスな譜面によって、故意に引き起こされます。
このとき、プレイヤーが叩くオブジェクトの数え方は実装依存です。
モダンな実装は
#PLAYERをもはや信用しません。- LR2, nanasi, ruvit, および pomu2 は
#PLAYERを無視して、解析されたチャンネルから実際のプレイモードを推測します。 - この方法は素朴な誤りを犯さないぶん、
#PLAYERに依存するよりはましといえます。 しかしながら、この方法が常にうまくいくわけではありません。
チャンネル
#xxx16だけを使用している譜面は、以下のいずれでもありえます:5KEYS, 7KEYS, 10KEYS, 14KEYS, 9KEYS (もし拡張子が PMS なら), 18KEYS...
どれがノーターが望むモードなのか、アプリケーションは判断することができません。
チャンネル
#xxx21-29が使われないが、#xxx41-49または#xxx61-69だけが使われる場合:可視オブジェはこの譜面の 2P 側に存在しませんが、ノーターはこの譜面が DP としてレンダリングされることを望んでいます。
しかし、旧 ruvit はこの譜面を SP として解釈していました。 (b5p6 にて修正済み)
さしあたり、BMS フォーマットはこれらの問題を理論上解決する方法を持ちません。
- したがって、LR2 と ruvit は、ハードコーディングによって、例外的な譜面を個別に処理しています。
- 次世代フォーマットは、この問題を理論上解決するために、プレイモードを詳細に指定できる記法を採用するでしょう。
- それはフラグとして
#OCT/FPコマンドのような識別子を使用するでしょう。
- LR2, nanasi, ruvit, および pomu2 は
- 近年、
#PLAYERは単に後方互換性のために存在します。
#RANK [0-3]
| origin: | BM98 |
|---|---|
| support: | ほぼすべて |
- 判定のレベルの定義。
省略時は
3がデフォルト値として適用されます。適用しない: BMSC, HDX ( #RANK非対応),0を適用:nBMplay, GDAC2, 2を適用:BM98, BM98de, MW, nazo, DDR, nanasi, LR2, ruvit, Angolmois, uBMplay, TechnicalGroove, 3を適用:BMSE, iBMSC, 値に対応するラベルは、仕様によって定義されています。
name & value label range in LR2 remarks #RANK 0VERY HARD +- 8ms &-(
#RANK 1HARD +-15ms :-(
#RANK 2NORMAL +-18ms :-)
#RANK 3EASY +-21ms :-D
判定幅は各実装に依存します。判定方式も実装に依存します。
judment system support remarks ピクセル判定 初期の実装 判定幅は譜面のスクロール速度に依存します。
BPM が上がるにつれ、判定は厳しくなります。 BPM が下がるにつれ、判定は緩くなります。
時間判定 DDR, uBMplay, pomu2, LR2, ... BPM が何であれ、判定幅は常に不変です。 変動ピクセル判定 nanasi, ruvit, fgt++, ... BPM が変更される場合は常に、適切な判定幅が再計算されます。 一部の実装は
#RANKを無視します。D3beat は譜面の
#RANK指定を無視し、各ユーザが設定した判定難易度を強制的に適用します。これはおそらく、
#RANKがタッチデバイスにそのまま適用されると都合が悪いためです。O2mania
は譜面の#RANK指定を無視し、各ユーザが設定した判定難易度を強制的に適用します。判定レベルは 3 種類のみが存在するようです (Easy, Normal, Hard)。“Very Hard” は見当たりません。
#RANK 4
| origin: | nanasi |
|---|---|
| support: | nanasi, |
- ナナシグルーヴ仕様は、値
4に VERY EASY と呼ばれるラベルを与えました。 #RANK 4は#RANK 3よりもさらに緩い判定です。ruvit は
#DEFEXRANKと#EXRANKはサポートしていますが、#RANK 4はサポートしていません。- 選曲リストにおいて、
#RANK 3や#DEFEXRANKの場合と、#RANK 4の場合を比べてみれば、それは明らかです。 - ruvit は、無効な値の
#RANKを読み込んだとき、NORMAL 判定 (#RANK 2) をデフォルト値として適用するようです。
- 選曲リストにおいて、
相対的な #RANK
| origin: | fgt |
|---|---|
| support: | fgt, Angolmois, TechnicalGroove |
- forgetalia のヘルプ・ファイルによれば、判定レベルの初期値は “
#RANKの値プラス 2” です。 (?) - さらに、
#RANK 6あるいは#RANK -1のような指定が可能であることが書かれています。 (??) しかしながら、私はこの仕様を理解することができませんでした。 forgetalia ヘルプファイルから引用:
#EXRANKと#RANKの区別はしていません。 ジャッジの値でどちらかを決めています。また、通常時の判定幅は (
#RANK+2) となっています。 つまり、#RANK 6とも#RANK -1ともできるわけです…。この不可思議な日本語を英語に翻訳することは、私にとって困難でした。
Angolmois 2.0 alpha 2 の相対的な
#RANKは、forgetalia と異なる実装です。 INTERNALS.md から引用:±{BAD:144, GOOD:84, GREAT:48, COOL:14.4} / (1.5 - #RANK-value * 0.25)millisecondsしかし、
Angolmois
#RANKsystem is certainly ill-designed however, so it may change without a notice.TechnicalGroove の
#RANKは#EXRANKのエイリアスであり、単に後方互換性のために存在します。#EXRANKの値として “25 * #RANK-value + 50” が適用されます。小数可、上限なし。- JUST の範囲は
#DEFEXRANK 100で±16msです (1上がるごとに0.16ms広がります)。
#DEFEXRANK n
| origin: | nanasi |
|---|---|
| support: | nanasi, ruvit (2.0b3+), fgt++, iBMSC (3.0 / #DEFEXRANK でなく #EXRANK),
Sonorous, TechnicalGroove, |
- 判定の難易度を、
#RANK [0-3]よりも詳細に指定することができます。 - 判定の初期値をパーセンテージで指定します。 値
100は#RANK 2(ラベル: NORMAL) に相当します。 - 小数も指定できます。
- 複数の
#RANKおよび#DEFEXRANKが見つかる場合、EOF に最も近い行が採用されます。 - 省略時は
#RANKが適用されます。 #DEFEXRANKと#RANKの両方が省略される場合、#RANK 2が適用されます。nanasi では、値の範囲およびラベルが以下のように関連づけられます。また、対応するアイコンが選曲リストに表示されます:
label 標準 nanasi の場合 fgt++ の場合 TechnicalGroove の場合 remarks 
OVER HARD - #DEFEXRANK ↑#DEFEXRANK ↑#DEFEXRANK ↑nanasi のみが持つラベル 
VERY HARD #RANK 0#DEFEXRANK 48#DEFEXRANK 60#DEFEXRANK 50
MORE HARD - #DEFEXRANK ↕#DEFEXRANK ↕#DEFEXRANK ↕nanasi のみが持つラベル 
HARD #RANK 1#DEFEXRANK 64#DEFEXRANK 80#DEFEXRANK 75
LITTLE HARD - #DEFEXRANK ↕#DEFEXRANK ↕#DEFEXRANK ↕nanasi のみが持つラベル 
NORMAL #RANK 2#DEFEXRANK 100#DEFEXRANK 100#DEFEXRANK 100基準値 (= 100%) 
LITTLE EASY - #DEFEXRANK ↕#DEFEXRANK ↕#DEFEXRANK ↕nanasi のみが持つラベル 
EASY #RANK 3#DEFEXRANK 120#DEFEXRANK 120#DEFEXRANK 125判定が指定されなかった場合のデフォルト値
MORE EASY - #DEFEXRANK ↕#DEFEXRANK ↕#DEFEXRANK ↕nanasi のみが持つラベル 
VERY EASY #RANK 4#DEFEXRANK 160#DEFEXRANK 140#DEFEXRANK 150nanasi と ruvitと fgt++ だけがサポートするラベル
OVER EASY - #DEFEXRANK ↓#DEFEXRANK ↓#DEFEXRANK ↓nanasi のみが持つラベル 
RANDOM - #EXRANKxx n#EXRANKxx n#EXRANKxx n動的な判定変更が存在する場合 - fgt++ には HI-SPEED オプションが存在しないので、判定は緩めに定められているものと思われます。
- ruvit サポートページでは、私は詳細を見つけられませんでしたが、以下の記述を発見しました:
nanasi-groove とは少し差があります。
- たとえば、
#DefExRank 199.97を指定した場合、譜面は NORMAL 判定 (#RANK 2) の 199.97% の判定幅でスタートします。 iBMSC 3.0 には
#EXRANKのテキストボックスがありますが、これは実際は#DEFEXRANKです。私たちがこれを使う場合、出力された BMS ファイルをテキストエディタで開き、
#EXRANKを#DEFEXRANKに書き換えなければなりません。
#DEFEXRANK 0
| origin: | TechnicalGroove |
|---|---|
| support: |
- スクラッチ以外の演奏レーンの判定を、“All or Nothing” にします。
- [Perfect GREAT, GREAT, GOOD, BAD, POOR] の 5 種類の判定ランクが存在するシステムなら、[Perfect GREAT, BAD, POOR] しか出現しなくなります。
- さらに、鍵盤レーンの Perfect GREAT 判定は、1 フレーム分の幅しか持ちません。
- これは beatmaniaIIDX の GAMBOL (Another) と同じ判定モードです。
#EXRANK[01-ZZ] 0も同上。
#EXRANK[01-ZZ] n
| channel: | #xxxA0 |
|---|---|
| origin: | nanasi |
| support: | nanasi, ruvit (2.0b3+), fgt++, Sonorous, TechnicalGroove |
- 判定幅の動的な変更。
- コマンドが省略される場合、あるいは定義が空の場合、判定には影響しません。
for example remarks #RANK 2 #EXRANKaa 48 #EXRANKcc 100 #114a0:aa0000cc#114では、判定は nanasi 基準での “VERY HARD” と同じ幅に変化します。#114の 4 拍目で、判定は “NORMAL” と同じ幅に変化します。nanasi では、
#EXRANKが記述された譜面に対し、判定難易度のラベルとして “RANDOM” が与えられます。また、選曲リストに専用のアイコンが表示されます。
#TOTAL n
| origin: | BM98 |
|---|---|
| support: | mostly |
- オブジェクトすべてが最良の判定で演奏された場合、ゲージ総量は
n% まで増加します。 - ゲージの増加率は、この値から計算されます。
- ほとんどの実装は小数の値をサポートしているはずですが、私は詳細を確認していません。
このコマンドは英語版 BMS 仕様書には書かれていませんが、BM98 のヘルプファイルには書かれています。
- これは暗黙の要求仕様でしょうか？ そうではないのでしょうか？
- 私はそれを判断できませんが、日本の BMS プレイアブルソフトウェアは、ほぼすべて
#TOTALを実装しています。(HDX を除く)
たとえば
#TOTAL 200が指定された場合、ゲージは最大で 200% まで増加します。
- もしゲージ初期値が 20% なら、ゲージは 220% まで増加するでしょう。
- 演奏オブジェクト総数が 400 なら、最良判定 1 個につきゲージは 0.5% 増加するでしょう。(200 / 400 は 0.5)
- あくまでこれはゲージの上昇率なので、もちろん実際のゲージは 100% を超過しません。
#TOTALを省略した場合、それがどのように作用しなければならないのか、仕様は規定していません。- BM98 では、可視オブジェクト数に 200 を足した値が、デフォルト値として適用されます。
この振る舞いが 「BMS フォーマットの仕様」 なのか 「BM98 の独自解釈」 なのか、定かではありません。
大部分の実装は BM98 の解釈に基づきますが、すべての実装がそうであるわけではありません。 例えば:
body default bm98 200+NOTESbemaniaDX 200LR2 160? (註: NORMAL Gauge)ruvit 160? (註: NORMAL Gauge)nanasi 350fgt++ 100+NOTES/8(min:#TOTAL 125)nazo 100+NOTES? (min:#TOTAL 130?)TechnicalGroove 0- 当てはまるデフォルト値はソフトウェアによって異なるため、
#TOTALの省略は推奨されません。
適切な算出式についての議論もあります。
- beatmaniaIIDX のゲージ増加率は 「
7.605*NOTES/(0.01*NOTES+6.5)」 であるといわれています。 - (ただし IIDX は、
#TOTALが260未満になる場合、260が適用されるようです。 ) - しかしながら、別の意見もありますし、DJMAX や O2Jam はまた別の議論になるでしょう。
- beatmaniaIIDX のゲージ増加率は 「
一部の実装において、
#TOTALの値として負数が指定される時、ノートが正確に打たれれば、グルーヴゲージは減少するでしょう。- nazo, nazoZZ, PMSee-V, ... (これら以外にも同種の実装は存在するかもしれませんが、私はそれについて調査していません。)
このセクションでは 「beatmania / beatmaniaIIDX でいう NORMAL ゲージ」 について記述してきました。 しかし、
name the first appearance remarks NORMAL gauge : beatmania 1 ステージ (楽曲) 終了時、このゲージが一定量に達していれば、ステージクリア。 EXPERT gauge : beatmania 3rdMIX ゲージ 100% から開始し、ステージ終了時に目盛が残っていればステージクリア。 いわゆる ライフバー。 (EXPERT モードは初代から存在したが、EXPERT ゲージ導入は 3rdMIX から) HARD gauge : beatmaniaIIDX 6th style プレイヤーが任意に適用するオプションのひとつ。 減少率が大きいライフバー。 EXPERT モードでは、通常よりゲージが減りやすく増えづらい。 EX-HARD gauge : beatmaniallDX 19 Lincle 同上、しかしもっと減る。 生き残るプレイヤーには勲章が与えられる。 HAZARD gauge : beatmaniaIIDX 16 EMPRESS コンボが切れたら即 STAGE FAILED。 Grade gauge : beatmaniaIIDX 7th style 段位認定用に特別に調整されたライフバー。 EX-Grade gauge : beatmaniallDX 19 Lincle 同上、 しかしもっと減る。 このオプションは特定のコマンドの入力により適用される。 これらはそれぞれ異なる文脈です。
#TOTALは に実装されたコマンドです。 ライフバー型のゲージはまだこの時期に存在しません。
#VOLWAV n
| origin: | BM98 |
|---|---|
| support: | BM98k, DDR, WAview, bemaniaDX, Mac, Aqua, KbMedia, PMSee-V, BMSC, BMSE, TechnicalGroove |
- 譜面が使用する音はすべて、オリジナルの
n% の音量で鳴らされます。 - オリジナルの音量は
#VOLWAV 100と等価です。 - 省略時は
100がデフォルト値として適用されます。 #VOLWAVは各実装やハードウェアに非常に依存するので、私たちはこれを信頼するべきではありません。- いまのところ、このコマンドは非推奨とされています。
#VOLWAV 200- 譜面が使用する音は、オリジナルの 200% の音量で鳴らされます。
BGM volume 変更
| channel: | #xxx97 |
|---|---|
| range: | [01-FF] |
| origin: | fgt |
| support: | fgt (fgt++/fgt# 削除済み。Obsolete? ) |
- BGM の音量を、255 のレベルで動的に変更します。
[1-255] の整数値を 16 進数で指定することができます。
00は休符です。For example remarks #00197:003C #00497:FFBGM の音量は
#001の半ばで 60 に変更されます。 (3C = 60)BGM の音量は
#004の先頭で原音に戻ります。 (FF = 255)
KEY volume 変更
| channel: | #xxx98 |
|---|---|
| range: | [01-FF] |
| origin: | fgt |
| support: | fgt (fgt++/fgt# 削除済み。Obsolete? ) |
- プレイヤーが演奏する KEY SOUND の音量を、255 段階で動的に変更します。
[1-255] の整数値を 16 進数で指定することができます。
00は休符です。For example remarks #00198:003C #00498:FFKEY の音量は
#001の半ばで 60 に変更されます。 (3C = 60)KEY の音量は
#004の先頭で原音に戻ります。 (FF = 255)
#STAGEFILE imagefilename
| origin: | BM98k |
|---|---|
| support: | ほぼすべて |
- ロード中に表示される、640x480 の画像ファイルを定義します。 要はスプラッシュスクリーンです。
- 省略できます。
省略時は、各実装が備えるデフォルトのロード画面が表示されることが期待されます。
in nazobmplay: #STAGEFILE指定時:https://hitkey.nekokan.dyndns.info/bmse_help_full/Capture/bmse_header_stagefile1.gif #STAGEFILE未指定:https://hitkey.nekokan.dyndns.info/bmse_help_full/Capture/bmse_header_stagefile2.gif
#BANNER imagefilename
| origin: | nanasi |
|---|---|
| support: | nanasi, pomu2, LR2, fgt++, iBMSC (3.0+), PMSee-V (2.0.0+), Sonorous, TechnicalGroove(parsing-only), |
300x80
- 選曲画面やリザルト画面などに表示する、300x80 の画像ファイルを指定します。
- 「BMS ファイルが存在するディレクトリ」からの相対パス (下位パスのみ) も指定できます。
MATERIALS (<path>filename) も指定可能。nanasi は MATERIALS のサポートを打ち切りました。- パス全長は 260 byte までとします。
コマンド省略時、nanasi は 「BMS の同位または下位のディレクトリ」から「banner.bmp」を検索し、もし存在すればこれを適用します。(そんなことはありませんでした。 それは既に削除されたように見えます。)
#BACKBMP imagefilename
| origin: | DDR |
|---|---|
| support: | DDR, nanasi, LR2 (条件つきで), pomu2 (条件つきで), iBMSC (3.0+), Sonorous(parsing-only), TechnicalGroove(parsing-only), |
本来の仕様では、プレイ画面の背景として表示する 640x480 の画像を指定します。
- DDR および nanasi は、本来の仕様に準拠しています。
もし本体側のスキンの中で定義が与えられたなら、LR2 および pomu2 はこのコマンドを使用できます。
- LR2 用スキン “OVER ACTiVE DX+” では、多くの場合、タイトル画像として使用されます。
- e.g. https://www.youtube.com/watch?v=5Q8pAA9O8Aw
#STAGEFILEに加えて、プレイ前に画面中央に表示される曲情報が、#BACKBMPです。- このコマンドによって、曲情報は、任意のフォントおよび任意のレイアウトで譜面を装飾することを可能にします。
- しかし、これは仕様にない振る舞いであり、画像ファイルのサイズは各スキンに依存します。
- “OVER ACTiVE DX+” の
#BACKBMP仕様
#CHARFILE characterfilename.chp
| origin: | pomu |
|---|---|
| support: | pomu2, PMChr-V, Sonorous(parsing-only), TechnicalGroove(parsing-only), |
- pop'n music を真似たキャラクターファイル。
- すみません、私はこの仕様について詳しくありません。
- いまのところ、
#CHARFILEは pomu2 の独自拡張です。 しかし、LunaticRave の次世代版は、#CHARFILEをサポートするかもしれません。
| For example: | https://www.youtube.com/watch?v=14skmXXCjOQ |
|---|---|
| sample download: | https://pmcc.nekokan.dyndns.info/pmcc2/download.html |
| official guidance: | https://web.archive.org/web/*/http://m-nekomi.cool.ne.jp/newpage/mu2/Make2.htm |
| unofficial guidance: | https://web.archive.org/web/20140103231405/http://storyof.namidaame.com/yy_pce.htm |
| charfile viewer: | PMChr-V.zip: https://sakukoba.ninja-x.jp/ponila/ |
#PLAYLEVEL n
| origin: | BM98 |
|---|---|
| support: | ほぼすべて |
- 選曲リストに表示されるべき難易度の定義。
難易度がどのように表示されるかは実装依存です。以下は例です。
- beatmania ベースのいくつかの実装では、難易度はいくつかの星マークで表現されます。 (★★★★☆☆☆)
- 最近の beatmaniaIIDX に基づいたいくつかの実装では、難易度は 12 段階の棒グラフとして表現されます。
DrumMania に基づいたいくつかの実装では、難易度は 99 段階の整数で表現されます。
(註: 現在は
xx.yy型の 1000 段階)
- 通常は整数を指定します。
BM98 では、省略時は
3がデフォルト値として適用されます。これは仕様で指定された振る舞いではありませんが、実装の大部分はこれを踏襲しました。
- 各レベルが示すべき難易度の基準は、仕様で示されません。それは文脈に依存するようです。
#PLAYLEVEL 0
| origin: | BM98 |
|---|---|
| support: | そこそこ |
- いくつかのアプリケーションで、値
0は特別な難易度として表示されます。 - たとえば BM98 は、星マークのかわりにクエスチョンマークを表示します。
#RANDOMや#SWITCHが仕組まれた BMS で、難易度が急激に変化するため、 値0が指定された、という例も存在します。- 値
0は、ある種のシンボルとして指定されるかもしれません。
#PLAYLEVEL string
| origin: | nanasi |
|---|---|
| support: | nanasi, iBMSC (3.0+), TechnicalGroove, (調査中) |
#PLAYLEVELの値に文字列を指定できます。 e.g.#PLAYLEVEL 安心#PLAYLEVEL 12.4のように、難易度の分類を詳述することもできます。
#DIFFICULTY [1-5]
| origin: | nanasi |
|---|---|
| support: | nanasi, LR2, iBMSC (3.0+), Sonorous, TechnicalGroove, |
- 私たちはこのメタ情報を使用して、譜面をソートしフィルタリングすることができます。
- このコマンドをサポートする実装では、「譜面の難易度種別による、選曲リストのフィルタリング」が可能になることが期待されます。
- 省略可。
- このコマンドが省略される場合、譜面の難易度種別によるフィルタリングは望めない場合があります。
- フィルタリングが機能しなくても、プレイレベル順あるいは ABC 順による単純なソートは可能かもしれません。
For example:
filename add description remarks himiko_1p_beginner.bms #DIFFICULTY 1低難度の譜面 (EASY/BEGINNER/LIGHT/etc.) himiko_1p_normal.bms #DIFFICULTY 2標準難易度の譜面 (NORMAL/STANDARD/etc.) himiko_1p_hyper.bms #DIFFICULTY 3高難度の譜面 (HARD/HYPER/etc.) himiko_1p_another.bms #DIFFICULTY 4さらに高難度の譜面 (EX/ANOTHER/etc.) himiko_1p_blackanother.bms #DIFFICULTY 5いわゆる 糞譜面や、 発狂など Another example:
filename add description remarks astro_EZ.bms #DIFFICULTY 1EASY astro_NM.bms #DIFFICULTY 2NORMAL astro_HD.bms #DIFFICULTY 3HARD astro_MX.bms #DIFFICULTY 4MAXIMUM astro_SC.bms #DIFFICULTY 5SUPER-CRAZY 日本では、kusofumen は特別のジャンルを形成しています。
演奏ノートの密度を上げる方向性。 INSANE (発狂) と呼ばれます。
bms難易度表 (BMS difficulties review) はこの種の典型例であり、とてもポピュラーです。
これは、多くのユーザの活発な議論によって分類された、譜面たちの巨大なデータベースです。
様々な譜面が提案され、議論され、分類されます。
噂では、この表に載った譜面の IR プレイ回数は、通常の 100 倍になるといわれています。
- 難易度表を由来とするサイトも多くあります。 LN 難易度表、 ターンテーブル難易度表、 DP 難易度表、 Overjoy など。
- ストップシーケンス、BPM 変更、ポップン風味の強制オプション、などのトリックを好むプレイヤーもいます。
BMS フォーマットの仕様の穴を突くタイプもあります。
ある種類のユーモアや冗談といった方向性も含まれます。 kusofumen lovers はその典型例のひとつです。
#DIFFICULTYは、主にパッケージなどに収録された BMS の形式を統一するために、頻繁に使用されます:BMS Starter Pack 2009 http://www.yamajet.com/bmssp/ Toy Musical シリーズ http://toymusical.net/ Colorful Canvas & Colorful Channel https://pmcc.nekokan.dyndns.info/pmcc2/download.html - 私の調査によれば、 BMS イベント 『戦[sen-goku]國 〜甲午の乱〜』 において、登録作品の過半数がこのコマンドを使用しました。
ファイル名によるグループ化
| origin: | pomu2 |
|---|---|
| support: | pomu2 |
定められた規則に従ってファイル名を指定することによって、実行ファイルは、難易度のグループを認識します。
[ハイフンマイナスと既定の小文字キーワードによる、基底名に対する接尾辞] filename 以下の難易度と一致: group pmsname-n.pms
#DIFFICULTY 2NORMAL pmsname-h.pms
#DIFFICULTY 3HYPER pmsname-ex.pms
#DIFFICULTY 4EXTRA pmsname-p.pms
#DIFFICULTY 5PLUS 私の記憶が確かなら、これに似た機能を持つアプリケーションは pomu2 以外にも存在します。
しかし、私は今それを思い出すことができません。それはもしかすると、Lunatic Rave の
*.lrファイルかもしれません。 私はそれについて詳しく知りませんが、詳細を転載しているページは発見できました。
副題によるグループ化
| origin: | TechnicalGroove |
|---|---|
| support: |
以下の条件がすべて満たされる場合、仮想的な
#DIFFICULTY値が自動的にセットされます。Grouping Keywords #DIFFICULTY 1“Easy”, “Beginner”, “Light”, “Simple”, “5Button”, “[B]”, “(B)” #DIFFICULTY 2“Normal”, “Standard”, “[N]”, “(N)” #DIFFICULTY 3“Hyper”, “Hard”, “Extend”, “[H]”, “(H)” #DIFFICULTY 4“Maniac”, “Extra”, “EX” #DIFFICULTY 5“Insane”, “Another”, “Plus”, “[A]”, “(A)” - TechnicalGroove は
#DIFFICULTY 6またはそれ以上の正の整数値もサポートしています (ただし非推奨)。 - TechnicalGroove は
#DIFFICULTY 0もサポートしていますが、0が何を意味するのかは明らかにされていません。
#TITLE string
| origin: | BM98 |
|---|---|
| support: | ほぼすべて |
- 曲のタイトルの定義。
このコマンドが省略される場合、実装がどのように振る舞うべきか、仕様は規定していません。
- 例えば、このコマンドが省略された BMS が実行ファイルにドロップされれば、nanasi は強制終了を行うでしょう。
仕様は、文字列長の上限を定めていません。
- 長すぎるタイトルの例: http://dee.manbow.org/event/event.cgi?action=More_def&num=127&event=60
BMSEでは、少なくとも 10000 文字以上入力することができます。しかし、他のアプリケーションは必ずしもこれを表示することができません。
https://hitkey.nekokan.dyndns.info/bmse_help_full/Capture/textlength43679.txt
- DDR は、500 バイトを超過すれば強制終了を行うでしょう。(ドキュメントに示されています。)
いくつかの実装は、テキストをトリムします。 (nanasi, LR2, etc..)
- たとえば “
#TITLE ABC” は “ABC” として表示されるでしょう。 - BMSE はテキストをトリムしません。 ノーターが意図しない変更を行なわないエディタは望ましいものです。
- たとえば “
テキストが多バイト文字を含んでいる場合、文字符号化の問題が生じるかもしれません。
- ruvit, iBMSC, IIDXv, HDX, Sonorous, BGAEncAdv, TechnicalGroove は、ASCII 以外のいくつかの文字セットをサポートしています。
- さらに LR2 の次世代バージョンは、デフォルトの文字セットとして ASCII ではなく BOM つき UTF-16LE を採用しました。
- そのようなアプリケーションは、たとえば
#TITLE LOVE♡SHINEのような値を指定できます。 - 私は他のアプリケーションの多言語サポート状況に関して知識が豊富ではありません。
HTML5 仕様草案では、UTF-7 および UTF-32 の文字セットのサポートは削除されました。 (https://www.w3.org/TR/2008/WD-html5-20080122/)
Authors should not use JIS_X0212-1990, x-JIS0208, and encodings based on EBCDIC.
Authors should not use UTF-32. Authors must not use the CESU-8, UTF-7, BOCU-1 and SCSU encodings. [CESU8] [UTF7] [BOCU1] [SCSU]
BMS ファイルが Web アプリケーション中で使用される場合を想定したとき、UTF-7 および UTF-32 は障害になるかもしれません。
暗黙の部分文字列 (#TITLE)
| origin: | DDR |
|---|---|
| support: | DDR |
#TITLEの値、あるいは#GENREの値に特有の文字列が見つかる場合、それぞれに対応するラベルが、選曲リストおよびプレイ画面に表示されます。
- プレイ画面へのラベル表示は、Arrow-mode でのみ行われます。
値は大文字小文字を問いません。
探される文字列: label: Basic, Light Basic Another, Trick, Standard Another Maniac, SSR, Heavy SSR - 曲名がこれらの単語を含む場合、この機能がうまくいかないことは明らかです。
- キーワード重複時は、ラベル “Basic” が適用されます。
暗黙の副題:
| origin: | bemaniaDX |
|---|---|
| support: | bemaniaDX, nazo, nazoZZ, LR2, TechnicalGroove |
#TITLEの値として指定されたテキストが、デリミタ文字を含んでいる場合、その部分は副題として解釈されます。選曲リスト、ロード画面などの中で、副題はメインタイトルと異なる形式で表示されるであろうことが期待されます。
example remarks #TITLE main-sub-ハイフンマイナス (https://www.fileformat.info/info/unicode/char/002d/index.htm) #TITLE main～sub～波ダッシュ (https://en.wikipedia.org/wiki/Wave_dash)全角チルダ (https://en.wikipedia.org/wiki/Tilde#Japanese)?#TITLE main(sub)括弧 (bemaniaDX は全角括弧もサポート ??) #TITLE main[sub]ブラケット #TITLE main<sub>不等号 #TITLE main␣␣sub半角スペース 2 個以上 (bemaniaDX のみ ?) #TITLE main"sub"ダブルクオート (LR2 と TechnicalGroove のみ) - 問題は、この仕様がデリミタの優先順位を規定していないということです。
複数種類のデリミタが混合される場合、解釈は実装依存です。
For example: #TITLE while(1) { LOVE -- }implementation maintitle subtitle bemaniaDX while(1) { LOVE -- }nazo / nazoZZ while(1) { LOVE-- }LR2 while(1) { LOVE -- }(empty) - 解釈が難しいテキストの問題に、仕様はヒントを与えません。
- さらに、この面倒な振る舞いを防止する方法は存在しません。
#SUBTITLEコマンドは、おそらくこれらの問題を解決するために提案されました。
#SUBTITLE string
| origin: | nanasi |
|---|---|
| support: | nanasi, LR2, iBMSC (3.0+), Sonorous, TechnicalGroove, diff |
#TITLEの暗黙の副題は、多くの場合、うまく働きませんでした。- そのような場合、明示的に
#SUBTITLEを定義すれば、それはうまくいくでしょう。 #SUBTITLEを使わないなら、省略して構いません。- LR2 と TechnicalGroove
では、
#SUBTITLEが省略される場合、#TITLEの暗黙の副題が採用されます。 - LR2 で
#SUBTITLEと暗黙の副題が競合する場合、暗黙の副題文字列は表示されません。
#SUBTITLE の多重定義
| origin: | Sonorous |
|---|---|
| support: | Sonorous |
複数の副題を定義できます。構文解析結果の比較例を以下に示します:
BMS code Sonorous LR2, nanasi, iBMSC #TITLE title #SUBTITLE (5keys) #SUBTITLE [Beginner] #ARTIST artisttitle (5keys) [Beginner] artisttitle [Beginner] artist
#ARTIST string
| origin: | BM98 |
|---|---|
| support: | ほぼすべて |
- アーティストの定義。
- 「アーティスト」とは何か？ 仕様はそれを示しません。
#SUBARTIST string
| origin: | LR2 |
|---|---|
| support: | LR2, nanasi, iBMSC (3.0+), Sonorous, TechnicalGroove, diff |
- 私たちは BGA クリエイター、ノーター、およびその他の協力者を表示するために、このコマンドを使用しても構いません。
- このコマンドをサポートする実装では、
#SUBARTISTは#ARTISTとは異なる形で表示されることが期待されます。 - このコマンドが省略される場合、単に
#ARTISTが採用されます。
#SUBARTIST の多重定義
| origin: | TechnicalGroove |
|---|---|
| support: | TechnicalGroove, Sonorous |
複数の助力者名を定義できます。構文解析結果の比較例を以下に示します:
BMS code TechnicalGroove LR2, nanasi, iBMSC #TITLE title #ARTIST artist #SUBARTIST MOVIE: m #SUBARTIST NOTER: n #SUBARTIST TESTR: ttitle artist MOVIE: m NOTER: n TESTR: ttitle artist TESTR: t
#MAKER string
| origin: | bemaniaDX |
|---|---|
| support: | bemaniaDX, Sonorous(parsing-only), TechnicalGroove(parsing-only) |
- 音楽作曲家が BMS 製作者と異なる場合、私たちは BMS 製作者名を定義しても構いません。この値はメタ情報です。
- この値は、ゲームの最初から最後まで表示されません。
#GENRE string
| origin: | BM98 |
|---|---|
| support: | ほぼすべて |
- 音楽のジャンルを定義します。
- 省略時は空の値がセットされます。
#GENLE string
| origin: | uBMplay |
|---|---|
| support: | uBMplay, Sonorous, TechnicalGroove |
- 誤字に対処するために。
暗黙の部分文字列 (#GENRE)
| origin: | DDR |
|---|---|
| support: | DDR |
#TITLEの値、あるいは#GENREの値に特有の文字列が見つかる場合、それぞれに対応するラベルが、選曲リストおよびプレイ画面に表示されます。
- プレイ画面へのラベル表示は、Arrow-mode でのみ行われます。
値は大文字小文字を問いません。
探される文字列: label: Basic, Light Basic Another, Trick, Standard Another Maniac, SSR, Heavy SSR - キーワード重複時は、ラベル “Basic” が適用されます。
#COMMENT "string"
| origin: | pomu |
|---|---|
| support: | pomu2, nanasi, PMSee-V, BM-A4, beat arranger, iBMSC (3.0+), Sonorous, TechnicalGroove(parsing-only) |
- このテキストは選曲リストに表示されます。
- ダブルクオートは「空文字列」を表現するために必要です。
- しかし、ダブルクオートのない譜面が、古い BMS の一部に存在します。 (e.g. はーとのしっぽ: http://necoco.2-d.jp/bms/nm28_nm07.zip)
- したがって、開発者はダブルクオートを前提に解析を行うべきではありません。
- 省略可。
#COMMENT の多重定義
| origin: | Sonorous |
|---|---|
| support: | Sonorous |
複数のコメントを定義できます。構文解析結果の比較例を以下に示します:
BMS code Sonorous nanasi, iBMSC #TITLE title #COMMENT Legacy comment #COMMENT "Current comment"title Legacy comment Current commenttitle Current comment
#TEXT[00-ZZ] "string"
| channel: | #xxx99 |
|---|---|
| origin: | pomu |
| support: | pomu2, nanasi, Sonorous(parsing-only),
|
- 任意のタイミングで表示される任意のテキストを定義します。
nanasi では、ミスしたときに
#TEXT00の内容が表示されます。 (pomu2 は#TEXT00をサポートしていません。)For example remarks #TEXT00 "MISS!!" #TEXTaa "SIROMARU eats only the bread crust" #TEXTbb "" #10099:aabbaabb#100でテキストが点滅します。実際は、
#TEXTbb ""の一行を削除しても、同じ結果がもたらされます。
#SONG[01-ZZ] "string"
| channel: | #xxx99 |
|---|---|
| origin: | pomu |
| support: | pomu2, Sonorous(parsing-only),
|
| caution: | このコマンドは旧式です。 私たちはこのコマンドをもはや使用するべきではありません。 |
#TEXT[01-ZZ]と等価なコマンドですが、時代遅れです。#SONG[01-ZZ]は旧式です。 現在は#TEXT[01-ZZ]の使用が推奨されます。#TEXT[01-ZZ]と#SONG[01-ZZ]が競合した場合、#TEXT[01-ZZ]の内容が優先されます。- Sonorous
と TechnicalGrooveは、#TEXTと#SONGを区別しません。 インデックスが重複した場合は、EOF に近い行を優先します。
地雷
| header: | #WAV00 soundfilename |
|---|---|
| channel: | #xxxD1-E9 |
| origin: | nanasi |
| support: | nanasi, LR2, fgt++, GDAC2+774gsc, PMSee-V (v1.11.0+), Angolmois, uBMplay (1.5.0+), Sonorous, TechnicalGroove |
触れるとゲージが減るオブジェクト。
- e.g. ガバディ (GABBAR-D): https://www.youtube.com/watch?v=fnkWsyvvOrw
- 聴き取りづらいですが、赤いとげとげのオブジェクトに触れたとき、「dosukoi」 が鳴らされます。
- Dosukoi は相撲絶叫です。 【doθkói】
地雷が爆発するとき、
#WAV00に定義されたファイルが鳴らされます。- PMSee-V で地雷は爆発しません。
#WAV00へファイルを割り当てずに#xxxD1-E9が使われた場合、:- nanasi と LR2 と uBMplay では、各実装が持つデフォルトの爆発音が鳴らされます。
- fgt++ と Angolmois はデフォルトの爆発音を持ちません。 したがって、地雷が触れられれば、ゲージは爆発音なしで減少するでしょう。
ゲージの減少量は
[01-ZZ]で定義されます。- 値/2 のゲージが減少します。
ZZは強制ゲームオーバーです。
For example remarks #WAV00 explode.wav #001D3:0000001Eゲージを 25% 奪う地雷が配置されます。 // 1E (36 進) = 50 (10 進) - 日本の BMS シーンのデファクト・スタンダードである LR2 が、地雷をサポートしたので、それは静かに流行しています。
- 地雷の特徴は、プレイヤーに keyup を強要する能力です。 これは LN や特徴的なパターンと組み合わせることによって、凶悪な威力を発揮するでしょう。
通常は、地雷の爆発音は変更できません。ただし:
For example remarks #wav00 bomb.wav #wav11 visible.wav #wav33 invisible.wav #00111:00000011 #00131:33 #001D1:1E- 不可視オブジェクトを重ねると、擬似的に別の音を再生できるかもしれません。
- ただしこの挙動は実装依存であり、互換性も確実性もありません。
- Angolmois と LR2 では、タイミング次第ですが、可能です。
- nanasi は不可視オブジェクトと爆発音の両方を再生します。
#PATH_WAV path
| origin: | |
|---|---|
| support: |
WAVファイルが存在するディレクトリのパスを定義することができます。- (相対パスはおそらく指定することができません。)
テストプレイで使用される用途を想定しています。
For example remarks #PATH_WAV C:\WINDOWS\Media #WAV01 onestop.mid #WAV02 chimes.wav #WAV03 chord.wav #BMP01 ..\..\img\koala.bmpパスの接頭辞を指定。
#WAV01が参照するファイルは、“C:\WINDOWS\Media\onestop.mid”#WAV02が参照するファイルは、“C:\WINDOWS\Media\chimes.wav”#WAV03が参照するファイルは、“C:\WINDOWS\Media\chord.wav”#BMP01が参照するファイルは、“C:\img\koala.bmp”- 私たちは、BMS をリリースする際に、
#PATH_WAVをコメントアウトするべきです。 WAview, in_bm2, uBMplay (1.5.1 およびそれ以前) では、値の接尾辞としてデリミタが必要です。たとえば：
#PATH_WAV C:\WINDOWS\Media\
#BPM n
| origin: | BM98 |
|---|---|
| support: | ほぼすべて |
- 曲の Beats-Per-Minute の定義。 これは譜面のスクロール速度の初期値として使われます。
コマンド省略時は
130がデフォルト値として適用されます。 しかし、まともな譜面なら#BPMは省略するべきではありません。- BMS 仕様は
130をデフォルト値として定めていますが、いくつかの実装はこの仕様を満たしていません。 - nanasi は
150を適用します。 - fgt++ は
30を適用します。 - nazo, nazoZZ, BMSC, BMSE, iBMSC, および BMSV は
120を適用します。 - fgt#, pomu2, nBMplay, および o2play は
0を適用します。 つまり、譜面はスクロールしません。 - LR2 の場合、BPM 表示欄はスロットが高速で回転し続けます。 つまり、譜面はスクロールしません。
- BMS 仕様は
ほとんどのソフトでは、値
nに整数だけでなく小数も指定できます。- ただし、以下のソフトは小数値を反映しません ： BMSV, BMS2WAV, otama, Galli, KbMediaPlayer (bmse.kpi), fgt
BPM 変更 (基本形式)
| channel: | #xxx03 |
|---|---|
| range: | [01-FF] |
| origin: | BM98 |
| support: | ほぼすべて |
[1-255] の整数値を 16 進数で指定することができます。
00は 休符 です。For example remarks #00103:00FEBPM は #001の半ばで 254 に変更されます。 (FE = 254)BMSE では、チャンネル
#xxx03のオブジェが置かれた場所にチャンネル#xxx08のオブジェが積まれる場合、両方が保存されます。For example remarks #BPM01 256 #00103:00FF #00108:0001これがどのように解釈されるかは実装依存です。 - iBMSC では、両方が保存されますが、親切に警告してくれます:
#BPM[01-ZZ] n
| channel: | #xxx08 |
|---|---|
| origin: | bemaniaDX version 0.72.0768 () |
| index range: | |
[01-99]: |
bemaniaDX (origin) // 10進数インデックスのみ、ただし #xxx08:[01-2R] |
[01-73]: |
BGAEnc (origin) // 36進数インデックス 255 個、ただし #xxx08:[01-FF] |
[01-FF]: |
MGQ (origin), BM98de (#BPM01 はバグる), DDR, RDM, MW (#BPMFF はバグる),
nazo, Mac?, |
[01-FZ]: | BMEV (origin) |
[01-ZZ]: |
nanasi (origin), LR2, fgt++, fgt#, ruvit, pomu2, uBMplay, PMSee-V, BMSE, iBMSC, DTXC, bme2wav, bmx2wav, Aqua (?), IIDXv, HDX, Angolmois, Sonorous, BGAEncAdv, TechnicalGroove, diff, in_bm2, O2play, |
- BPM は任意の位置で変更されます。 (今後、私はこの文書中で、この「拡張された BPM 変更コマンド」 を 「exBPM」 と略します。)
このコマンドは、主に小数の値、あるいは over255BPM の値を定義します。 つまり、実数 BPM が定義されます。
For example #BPMII 256 #BPMzz 155.5 #00108:IIzzIIzzBMSE は、定義を与えられたスクロール・オブジェクトを再利用できません。もし BMSE で保存すれば、前の例は以下のように書き直されるでしょう。
For example #BPM01 256 #BPM02 155.5 #BPM03 256 #BPM04 155.5 #00108:01020304- したがって、BMSE では、exBPM オブジェクトは最高でも 1295 個しか読み書きすることができません。
- 1295 種類の値を無限にセットする場合、私たちは BMSE でない手段を使用しなければなりません。
- (値は 255 種類に制限されますが、チャンネル
#xxx03のオブジェクトは無限に読み書きすることができます。)
BMSE は、
[01-FF],[01-FZ],[01-ZZ]のいずれの実装も、可能な限りサポートすることを試みます。- 使用された実数 BPM オブジェクトが 255 個未満である場合、BMSE は
#BPMxxのインデックスを[01-FF]で定義します。 - 使用された実数 BPM オブジェクトが 256 個以上である場合、BMSE は
#BPMxxのインデックスを[01-ZZ]で定義します。
- 使用された実数 BPM オブジェクトが 255 個未満である場合、BMSE は
iBMSC の定義スロットは
255 個に制限されます設定から 1295 個に変更可能。また、iBMSC は、定義を与えられたスクロール・オブジェクトを再利用することができます。
- 負数が値として定義される場合、いくつかの実装は、スクロール方向を逆転します。 (https://www.youtube.com/watch?v=R4S7BKEB0vs)
値の範囲は仕様で定義されないので、負の BPM の解釈は実装依存です。
逆流: bemaniaDX, BM98de, RDM, nazo, nazoZZ, O2mania, LR2, ruvit, fgt++, fgt#, uBMplay, PMSee-V, IIDXv, Angolmois, Sonorous独自解釈: bme2wav, bmx2wav 無視: KbMedia, GALLI (負符号のみ無視), LR2 (partial), nanasi, pomu2130を適用:DDR, WAview, in_bm2 0を適用:iBMSC, DTXC 編集可能: BMSE その場で終了: BGAEncAdv , TechnicalGroove(負数 BPM オブジェクトの後方に存在する音声オブジェクトは、すべて同時に再生されます)- 負数 BPM は、
nazobemaniaDX のバグを起源とする演出に過ぎず、要求仕様ではありません。 - ruvit, fgt++, Angolmois, Sonorous では、スクロールが逆流しても、通常通りリザルト画面に移ることができます。
- それ以外の「負数 BPM をサポートする実装」では、ESC キーを押す必要があるかもしれません。 (譜面から抜けられないため)
LR2 は、負数 BPM を基本的にサポートしませんが、有名な kusofumen は例外的にハードコーディングされているようです。(e.g. Sofa $15 -> $1, U9, etc. )
- 逆スクロールを実装する義務はありませんが、負数の値が指定される可能性は考慮されるべきです。
- 負数 BPM は、
- 関連文書: Extended BPM - BMS Command
#EXBPM[01-ZZ] n
| channel: | #xxx08 |
|---|---|
| origin: | nanasi |
| support: | nanasi, pomu2, PMSee-V, Sonorous, BGAEncAdv, TechnicalGroove, HDX |
#BPMxx nと等価。- これは、BMSC のバグを回避するためのエイリアスです。
- BMSC は
#BPMxx nと#BPM nを混同し、解析を誤るでしょう。
#BASEBPM n
| origin: | LR |
|---|---|
| support: | LR (LR2 は #BASEBPM のサポートが打ち切られた ?) |
- スクロール速度の標準値として使われる BPM を定義します。
スクロール速度は、「BPM 変更オブジェクト中の最大値」 もしくは
#BASEBPMの値から決定されます。- LR2 は適切な HI-SPEED オプションを自動的に設定する機能を持っています。
- この機能を使用する場合、通常、HI-SPEED オプションは「BPM 変更オブジェクト中の最大値」に基づいて決定されます。
- しかしながら、例えば「非常に短い区間だけ急加速する譜面」では、この機能はがっかりさせる結果を引き起こすでしょう。
- その場合、
#BASEBPMは「便宜的な代替標準値」を定義することができます。
#STOP[01-ZZ] n
| channel: | #xxx09 |
|---|---|
| origin: | DDR Ver.0.50 beta2 |
| index range: | |
[01-99]: |
pomu2 (origin) // 10進数インデックスのみ、ただし #xxx09:[01-2R] |
[01-73]: |
RDM (origin) // 36進数インデックス 255 個、ただし #xxx09:[01-FF] |
[01-73]: |
fgt (origin) // 36進数インデックス 255 個、ただし [41, 45-4F, 4H] はバグあり |
[01-FF]: |
DDR (origin), nazo, nazoZZ, GALLI, WAview, PMSee-V, |
[01-ZZ]: |
nanasi (origin), LR2, ruvit, fgt++, fgt#, BMSE, uBMplay, in_bm2, bme2wav, BGAenc, bmx2wav, iBMSC, IIDXv, HDX, Angolmois, Sonorous, BGAEncAdv, TechnicalGroove, diff |
- DDR タイプのストップシーケンスが定義されます。
- ストップシーケンスは、一定時間、譜面のスクロールを停止するオブジェクトです。
- 定義された時間が経過すれば、譜面のスクロールは再開されるでしょう。
一般的な実装の分解能を、単位 1 としてください。つまり、4/4 拍子における 「全音符の 1/192 の音符」 を、単位 1 としてください。- つまり、
192nd note * 1 === #STOPxx 1 この値は、チャンネル
#xxx02(小節長変更) の値に左右されてはなりません。なぜなら、「音符」は小節の長さとは無関係な単位だからです。
For example remarks #STOP11 96 #STOP22 96 #00109:0011 #00202:0.5 #00209:0022値
96は192nd note * 96です。#001と#002では、停止すべき時間は同じです。古い WAview と古い pomu には、停止時間がチャンネル
#xxx02に依存するバグがありました。音符を基準とするので、停止時間は「停止時の BPM の値」に依存します。
1 秒間停止: 0.5 秒間停止: 0.25 秒間停止: #BPM 60 #STOP33 48 #00109:33#BPM 120 #STOP44 48 #00109:44#BPM 240 #STOP55 48 #00109:55複数のオブジェクトが同じタイムライン上に位置する場合、STOP オブジェクトを最も遅く評価する必要があります。
- STOP オブジェクトと音声オブジェクトが同一タイミングにある場合、最初に音が鳴らされ、次にスクロールが止められます。
- STOPオブジェクトと BPM オブジェクトが同一タイミングにある場合、最初に BPM が変更され、次にスクロールが止められます。
- ほとんどすべての実装はこの振る舞いに従いますが、
pomu2 だけいくつかの実装は他と異なる結果をもたらすかもしれません。 理論上、小さな BPM と大きな STOP が組み合わせられる場合、停止時間は無限に拡張可能です。
BPM 1.250001+ STOP2147483647
停止時間: 約 // (しかし、uBMplay 以外のアプリケーションは強制終了するでしょう。)負数の値が定義される場合、いくつかの実装は、譜面のスクロールをスキップします。
スキップ: RDM, nazo, nazoZZ, fgt, fgt++, fgt#, pomu2, uBMplay, IIDXv, HDX, Angolmois (Rust), BGAEnc警告: PMSee-V スライド: bme2wav, bmx2wav -1を適用:LR2 (わずかなスキップ), RDM 0を適用:DDR, iBMSC 0.1を適用:nanasi 無視: LR2, nanasi,WAview, in_bm2, ruvit, Angolmois (C), Sonorous強制終了: ruvit絶対値を適用: BGAEncAdv, TechnicalGroove いくつかの実装は、小数の値を解釈します。
小数値を適用: RDM,ruvit, nanasi, fgt#, iBMSC, IIDXv, HDX, BGAEncAdv, TechnicalGroove整数化 (小数を切り捨て): DDR, WAview, in_bm2, bme2wav, LR2, fgt++, Angolmois, Sonorous, RDM, BGAEnc, GALLI, pomu2, PMSee-V 整数化 (小数を四捨五入): nazo, nazoZZ, uBMplay, BMSE 大幅に狂う: GALLI, pomu2, PMSee-V変換中止: bmx2wav - 本質的に、
#STOPは負数も小数も受け付けるべきではありません。 [註: 私見] - 不正な値の入力を禁止する BMSE & iBMSC はスマートです。
- 本質的に、
BMSE は、定義を与えられたスクロール・オブジェクトを再利用できません。iBMSC はできます。
- したがって、BMSE では、STOP オブジェクトは最高でもわずか 1295 個しか読み書きすることができません。
- 1295 種類の値を無限にセットする場合、私たちは BMSE でない手段を使用しなければなりません。
- 使用された STOP オブジェクトが 255 個未満である場合、BMSE は
[01-FF]によって#STOPxxのインデックスを定義します。 - 使用された STOP オブジェクトが 256 個以上である場合、BMSE は
[01-ZZ]によって#STOPxxのインデックスを定義します。 - 関連文書: STOP Sequence - BMS Command
#STP xxx.yyy zzzz
| origin: | bemaniaDX |
|---|---|
| support: | bemaniaDX, Angolmois, Sonorous |
bemaniaDX タイプの STP シーケンスを定義します。
xxx[000-399]小節 (Angolmois & Sonorous: [000-999])yyy[000-999]小節内の位置 (yyy/1000) zzzz停止時間 (ms) 次の例は、合計で 4500ms の間、スクロールを停止します。
For example remarks #STP 001.500 500 #STP 001.500 4000#001の中央位置で、500ms 停止。定義を同じ場所に重複できます。停止時間を 4000ms 加えます。
- bemaniaDX タイプの STP シーケンスを使わないなら、これを記述する必要はありません。
仕様に書かれていませんが、詳細は以下のとおりです。
xxxとyyyは、3 桁の数で記述する必要があります。0の省略は許されません。xxxとyyyのデリミタとして、ピリオドを記述する必要があります。yyyとzzzzのデリミタとして、全角/半角空白、またはタブ文字を記述する必要があります。このデリミタは、1 文字以上 7 文字未満でなければなりません。
- ピリオドと
yyyが省略される場合、#STP xxx.000 zzzzとして解釈されます。 私たちは
zzzzの後に数字以外を記述しても構いません。 解析時にコメントアウトされます。しかしながら、内部処理が明らかではないので、コメントとして捨てられることを期待はできないでしょう。
「位置」
yyyは1000等分されるように見えますが、960以上の値は事実上無視されます。このバグはフリーズする可能性すらあります。
bemaniaDX は
#400以上の小節をサポートしていません。他の実装と同様の方法で譜面を書こうとすると、バグが増えるでしょう。
#STP文が大量に重複した場合、それらは無視されるでしょう。しかし、どこまで重複できるのかは仕様に書かれていません。
- Angolmois & Sonorous の STP シーケンスは、bemaniaDX のそれよりも期待通りに動作します。
#LNTYPE 1
| channel: | #xxx51-69 |
|---|---|
| origin: | RDM |
| support: | RDM (1.3+), WAview, in_BM2, ruvit, Angolmois, Sonorous, o2mania |
| omissible: |
RDM (1.7+), DDR (Arrow mode only), nazo, nazoZZ, WAview, in_BM2, bme2wav, Aqua (?), LR2, nanasi, ruvit, fgt++, fgt#, pomu2, BMSE, iBMSC, uBMplay, PMSee-V (1.1.6+), IIDXv, bmx2wav, o2play, HDX, Angolmois, Sonorous, TechnicalGroove, diff |
#LNTYPEは、譜面が準拠する LN の記法を宣言します。#LNTYPEの値が1である場合、LN チャンネル#xxx51-69は、RDM タイプと MGQ タイプのうち RDM タイプが選ばれます。このコマンドが省略される場合、RDM タイプが暗黙的に適用されます。
- MGQ.exe は除きます。MGQ.exe は RDM の仕様と無関係だからです。
- RDM タイプおよび MGQ タイプの両方を実装したアプリケーションでは、この宣言は明瞭な意味を持っています。
- MGQ タイプを実装してしないアプリケーションでは、この宣言は無意味です。
- MGQ タイプは既に衰退しました。
- LN をサポートするアプリケーションはすべて RDM タイプを実装しています。
- したがって、
#LNTYPE 1を明示的に記述する必要性はもはや存在しません。 - この宣言は後方互換性のためにのみ残されています。
RDM タイプの
#xxx51-69と#LNOBJが競合した場合の優先順位は、仕様で定められていません。- pomu2 では、
#xxx51-69と#LNOBJが競合した場合、#xxx51-69のオブジェがすべて#xxx11-29に化けるバグがあります。 - LR2 で
#xxx51-69と#LNOBJが競合する場合、#LNTYPEの有無によって、解析結果が微妙に異なるかもしれません。
- pomu2 では、
- DDRでは、終点シンボルが見つからない間に譜面が終了に達する場合、コンパイルエラーが返されます。
- BMSE では、チャンネル
#xxx51-69のオブジェクトを BGM に移動すると、BMSE が強制終了します。 - iBMSC は、
#LNTYPE 1ではなく#LNTYPE 01を自動的に記述します。 - o2mania は、
#LNTYPE 1を省略できません。1および01は有効値として受け取られます。001は無効値です。
- details:
-
RDM 記法は、MGQ 記法のシンタックスシュガーと見なすことができます。
#LNTYPE 1は RDM-type #1 LN です。LN は
00以外のノートが現れる位置から開始されます。 (LN 始点シンボル)LN は
00以外のノートが次に現れる位置で閉じられます。 (LN 終点シンボル)For example remarks #LNTYPE 1 #00151:00220000 #06451:000000000033O2mania 以外の実装は、この宣言を省略できます。
LN 区間は
#001の中で開始されます。終点以外のオブジェクトが、LN 区間の間に現れなかったなら、この LN は
#064で閉じられます。この例は、
#001-064の長さの、1 つの LN セクションを形成します。1 つの LN セクションは、「1 つのオブジェクト」として数えられるかもしれないし、「2 つのオブジェクト」として数えられるかもしれません。 それは実装依存です。ほとんどの実装は、1 つのオブジェクトとしてそれを数えます。
ファイルが
#WAV22に定義されれば、音は開始位置で鳴らされるでしょう。ファイルが
#WAV33に定義される場合でも、終点の音は鳴らされません。#LNTYPE 1では、終了位置の音は常に無視されます。開始位置および終了位置の
#WAVインデックスは、必ずしも同じとは限りません。 しかし BMS エディタを使うなら、ほぼすべての場合に同じになるでしょう。
LN 終端で別の音を鳴らす
| channel: | #xxx51-69 |
|---|---|
| origin: | HDX |
| support: | HDX, IIDXv, TechnicalGroove |
ロングノートの始端と終端に異なるインデックスを配置すると、それぞれ別の音を鳴らすことができます。 例 ：
For example remarks #WAVaa onkeydown.wav #WAVbb onkeyup.wav #00151:00aa00bbLN 始端用の音
LN 終端用の音
LN 始端では onkeydown.wav が再生され、LN 終端では onkeyup.wav が再生されます。
- LN 終端を判定するゲームシステムと組み合わせれば、beatmania IIDX の「バックスピンスクラッチ」も擬似的に再現できるでしょう。
#LNTYPE 2
| channel: | #xxx51- |
|---|---|
| origin: | RDM |
| support: | RDM (1.3+), WAview, in_BM2, ruvit, Angolmois, Sonorous |
| caution: | このコマンドは旧式です。私たちはこのコマンドをもはや使用するべきではありません。 |
#LNTYPEは、譜面が準拠する LN の記法を宣言します。#LNTYPEの値が2である場合、LN チャンネル#xxx51-69は、RDM タイプと MGQ タイプのうち MGQ タイプが選ばれます。このコマンドが省略される場合、RDM タイプが暗黙的に適用されます。
- MGQ.exe は除きます。MGQ.exe は RDM の仕様と無関係だからです。
- したがって、MGQ.exe は
#LNTYPEを無視します。 MGQ.exe は常に、#xxx51-8Cを MGQ 記法の LN として解釈します。
MGQ フォーマットは BMS の亜種 (部分集合) であり、KEYBOARDMANIA の譜面をエミュレートできます。 24KEYS *2 が準備されています。
1P-side LN: channel#xxx51-5Cand#xxx61-6C2P-side LN: channel#xxx71-7Cand#xxx81-8C
MGQ フォーマットは旧式です。私たちはもはや MGQ-LN を使用するべきではありません。
- KEYBOARDMANIA のようなゲームのために、MGQ よりも適切なフォーマットがいくつか考案されています。
- たとえば Synthesia は、「MIDI からの直接の譜面化」 と、87KEYS をサポートしています。 https://www.youtube.com/watch?v=euadl2uWy_g
- WAview と in_bm2 は、MGQ-LN を正しく解析しません。すくなくとも RDM の仕様の通りには解釈しません。
- RDM と ruvit では、最後のノートが MGQ-LN である場合、それは正しく解析されません。(たぶんバグ)
- details:
-
#LNTYPE 2は MGQ 記法 LN です。LN は、
00以外のノートが現われる位置から開かれます。LN は、
00以外のノートが連続する間、繋がります。LN は、
00が現れたとき閉じられます。「前の小節の最後のノート」が
00でなく、「現在の小節の最初のノート」も00でない場合、MGQ-LN は小節線を超えて繋がります。For example remarks #LNTYPE 2 #00151:0022zzzz #00251:zz #00351:zz ... #06351:zz #06451:zzzzzzzz3300 #06551:00 #06511:0011宣言は省略できません。
LN の開始 & LN の持続。
LN の継続シンボルは省略できません。
LN の継続シンボルは省略できません。
LN の継続シンボルは省略できません...
LN の継続シンボルは省略できません...
最後のノートが
33である必要はありません。33は他のインデックスでも構いません。明示的な終点シンボル
00(省略可能)« RDM/ruvit のバグ回避用 ... 各レーンの最後のオブジェを MGQ-LN にしない
この例は、
#LNTYPE 1の例と同じ譜面を表現します。 (#06511:0011は除く。)RDM と ruvit では、開始位置および終了位置における音の鳴り方は、
#LNTYPE 1の場合と同じです。(WAview と in_bm2 の MGQ-LN はバグってるので、私には判断できません。)
MGQ-LN を使用する場合、私たちは非常に忍耐強いに違いありません。
- バージョン 798422870970 () 以前の Angolmois に関する注記:
-
ruvit の実装 は上記の通りですが、Guide to understand BMS format が解説する MGQ 仕様はもっと複雑です。
MGQ.exe を持たない私は、これらの解説の妥当性を検証できません。
すくなくとも、ruvit と 版以前の Angolmois の両方で同一の解析結果を得るために、私たちは次のように記述しなければなりません。
For example remarks #LNTYPE 2 #00151:00222222 #00251:22 #00351:22 ... #06351:22 #06451:222222222200 #06551:00 #06511:0011宣言は省略できません。
LN の開始 & LN の持続。 すべて同じインデックスでなければなりません。
LN の継続シンボルは省略できません。
LN の継続シンボルは省略できません。
LN の継続シンボルは省略できません...
LN の継続シンボルは省略できません...
最後のインデックスも最初のインデックスと同一でなければなりません。
明示的な終点シンボル
00(省略可能)« RDM/ruvit のバグ回避用 ... 各レーンの最後のオブジェを MGQ-LN にしない
- 版以降の Angolmois は、異なるインデックスの連続であっても ruvit と同一の解析結果が得られるように変更されています。
#LNOBJ xx
| channel: | #xxx11-29 |
|---|---|
| origin: | RDM |
| support: | RDM (1.61+), nazo, nazoZZ, LR2, nanasi, ruvit, fgt++, fgt#, pomu2, BMSE, uBMplay, PMSee-V, bmx2wav, iBMSC (3.0+), Angolmois, Sonorous, TechnicalGroove |
| sound or not: | bmx2wav (設定から挙動を変更可能) |
| sound as BGM: | RDM (1.61+), ruvit, |
| sound as KEY: | TechnicalGroove (Keyup sounding) |
multiple #LNOBJ: | TechnicalGroove |
- このコマンドが記述される場合、RDM-type #2 の LN が適用されます。
#WAVのインデックスのうちの1つを XX に指定します。 任意の#WAVインデックスは LN 終了マークとして使われます。#WAVインデックスの 1 つを消費することで、通常の#xxx11-29と区別することなく LN を編集できます。- したがって、BMSC 以外のエディタが存在しなかった時代に、
#LNOBJは頻繁に使用されました。 - BMSE のバグを回避するために、このコマンドは今もまだ頻繁に使用されています。
(
#xxx51-69の LN を BGM に移動すると BMSE が落ちるバグ) #LNOBJをサポートしない実装では、LN は通常の#xxx11-29のオブジェになります。- ノーターの意図に反する譜面にならないようにするために、拡張子を BML に変更することが推奨されます。
#LNOBJをサポートしない実装が拡張子 BML をサポートすることは、厳密にいえば間違いです。#xxx51-69はサポートするが、#LNOBJをサポートしないので、拡張子 BML をサポートしない実装: DDR#LNOBJをサポートしないが、拡張子 BML はサポートする、緩いグループ: WAview, in_bm2, IIDXv, HDX,iBMSC,O2play
- BMSE は
#LNOBJを明示的にはサポートしませんが、#LNOBJは「拡張命令」タブ内で編集することができます。
#LNOBJにおいて、nanasi と fgt++ は小文字の#WAVインデックスを認識しないバグを持つため、大文字で指定するほうがよいでしょう。
- details:
-
#LNOBJは、RDM-type #1 のシンタックスシュガーであり、RDM-type #2 LN です。#LNOBJに定義された#WAVインデックスのノートは、LN の終了マーク (閉鎖シンボル) として使用されます。終了マークが見つかる場合、その前の可視オブジェクトは LN 始点として解釈されます。
#LNOBJを使用する譜面は、#LNTYPE宣言を必要としません。終了マークが判定ラインを通過するとき、
#LNOBJとして定義された#WAVインデックスのファイルは、BGM として鳴らされます。- これは RDM 仕様に準拠する振る舞いですが、終了マークを鳴らさない実装
も存在しますが殆どです。 - 「空の
#WAV」のインデックスを#LNOBJに定義すれば、互換性は保たれるでしょう。
For example remarks #LNOBJ ZZ #00111:00220000 #06411:0000000000zznanasi と fgt++ のバグを回避するため、
#WAVインデックスを大文字で指定しています。この例は、
#LNTYPE 1の例と同じ譜面を表現しています。しかしながら、
#WAVzzにファイルが定義されている場合、終了マークは鳴らされるかもしれません。 (実装依存) - これは RDM 仕様に準拠する振る舞いですが、終了マークを鳴らさない実装
LN 終端で別の音を鳴らす (#LNOBJ)
| channel: | #xxx11-29 |
|---|---|
| origin: | TechnicalGroove |
| support: | TechnicalGroove |
HDX 拡張 の
#LNOBJ実装です。 例:For example remarks #WAVaa onkeydown1.wav #WAVbb onkeyup1.wav #WAVcc onkeydown2.wav #WAVdd onkeyup2.wav #LNOBJ BB #LNOBJ DD #00111:00aa00bb #00213:00cc00ddLN 始端用の音 (1)
LN 終端用の音 (1)
LN 始端用の音 (2)
LN 終端用の音 (2)
LN 終端の定義 (1)
LN 終端の定義 (2) (multiple LNOBJ)
LN 始端では onkeydown1.wav が再生され、LN 終端では onkeyup1.wav が再生されます。
LN 始端では onkeydown2.wav が再生され、LN 終端では onkeyup2.wav が再生されます。
#OCT/FP
| origin: | nanasi |
|---|---|
| support: | nanasi (, BMSE, Angolmois, Sonorous), uBMplay (1.5.0+), TechnicalGroove |
- このコマンドが書かれた BMS は、OCTAVE MODE として解釈されます。
- このコマンドは値を持ちません。
- OCT/FP とは: https://web.archive.org/web/*/http://www.diana.dti.ne.jp/~idee/octave.html
-
OCT/FP は、オクターブモード / フットペダルモードです。 このフォーマットは 2002年 (2003年?) に idee によって提案されました。
オクターブモードは、13 のキーと 2 つのターンテーブルを使用します。 オプションとして、1 つのフットペダルを使用できます。
これは、14KEYS (「7KEYS と 1 つのターンテーブル」のダブルプレイ) の外観を変更したモードです。
このモードが使用するチャンネルは、完全に 14KEYS と同じです。
このフォーマットは、外観を柔軟に変更できる nazo を使用して、14KEYS を擬似 OCT/FP として表現します。
このフォーマットの考え方は、Project2DX に似ています。
BMSEは、テーマ・ファイルという方法によって、OCT/FP の譜面の編集をサポートしています。
- nanasi は 14KEYS と OCT/FP を区別できません。 なぜなら nanasi は使用されたチャンネルからモードを推測するからです。
- したがって、nanasi は識別子としてこの
#OCT/FPコマンドを必要とします。 - このコマンドが見つかる場合、nanasi は常に OCT/FP として BMS をレンダリングします。
nanasi と uBMplay 1.5.0+ と TechnicalGroove 以外のアプリケーションは、このコマンドを無視します。
- BMSE は
#OCT/FPコマンドを「拡張命令」タブに分離します。 BMSE のテーマファイルは手動で変更する必要があります。 その手順は:
- BMSE ウィンドウの右上の 「基本」タブを選択します。
- プルダウンメニュー
プレイモードを選択します。 - メニュー項目「13 keys (oct/fp)」を選択します。
- メニューバー項目「設定(O)」を選択します。
- 子メニュー項目「Select Theme」を選択します。
- 孫メニュー項目「Default (for oct/fp)」を選択します。
Angolmois はコマンドライン引数によって OCT/FP のレンダリングを適用できます。 (
--key-spec 'Leftside string' 'Rightside string')例:
$ angolmois.exe --key-spec '21p 16s 11a 12b 13a 14b 15a 18b 19a 22b 23a 24b 25a 28b 29a 26s' ''- Sonorous は
#LANES独自拡張命令によって OCT/FP のレンダリングを適用できるかもしれません。 TechnicalGroove は独自モード「9KEYS/FP」を適用します (もしレーン 6・7 が未使用なら)。
- BMSE は
- OCT/FP の譜面は、近年ほとんど見られません。 ( e.g. Microcosm from bms同窓会(仮) )
#OPTION optionID
| origin: | nanasi |
|---|---|
| support: | nanasi, HDX (v0.99+), IIDXv (v2.14+), Sonorous(parsing-only) |
- BMS 側で定義したプレイオプションが、プレイヤー側に強制的に適用されます。
- 通常のコマンドが重複する場合は、「行番号が最も大きい行」が採用されますが、
#OPTIONは重複可能です (部分的に)。 他のアプリケーションがこのコマンドをサポートする可能性に備えて、ベンダー接頭辞を付けることが推奨されます。
機種 接頭辞 nanasi 774:HDX, IIDXv charatbeatHDX:TechnicalGroovenone註: TechnicalGroove はベンダー接頭辞を無視し、使用できるオプションのみを適用します。- もし BMS フォーマットの仕様が標準化されれば、ベンダー接頭辞のない
optionIDもサポートされるかもしれません。 複数の
#OPTIONを記述できるので、次の例のような指定を行なうことができます:For example remarks #OPTION 774:HI-SPEED_x99.75 #OPTION 774:HI-SPEED_x0.77 #OPTION 774:CHANGE-HS_RANDOM #OPTION 774:CHANGE-HS_COMBO-UP #OPTION 774:HIDDEN_DEEPMIST #OPTION 774:HIDDEN_OFF #OPTION 774:RANDOM_ALL+ #OPTION 774:RANDOM_MIRROR #OPTION 774:NOTES_DOUBLE #OPTION 774:NOTES_DBLCOPY #OPTION 774:CRAZY_STAR #OPTION 774:CRAZY_SPIN #OPTION 774:CRAZY_CLONE #OPTION 774:CRAZY_GREAT2BAD #OPTION 774:CRAZY_XYWAVE2 #OPTION 774:CRAZY_3DWAVE #OPTION 774:CRAZY_DARK2 #OPTION 774:CRAZY_FADEOUT #OPTION 774:CRAZY_RD-SIZE #OPTION 774:CRAZY_ADDMINE #OPTION 774:AUTOPLAY_LINE同系列のオプションが重複する場合、EOF に最も近い行が優先されます。
x99.75ではなくx0.77が適用されます。x0.77は BMS 側からのみ適用可能な値です。RANDOMではなくCOMBO-UPが適用されます。 (これらは同系列なので)DEEPMISTではなくOFFが適用されます。OFFは、オプションの適用をキャンセルします。ALL+ではなくMIRRORが適用されます。 (これらは同系列なので)DOUBLEではなくDBLCOPYが適用されます。NOTES系は#CHANGEOPTIONでは使えません。CRAZY系列は、複数のオプションを適用することができます。 通常のプレイでは、1 つのオプションしか適用できません。#OPTIONを指定することによってのみ、CRAZYオプションを複数同時に適用できます。CRAZY系列では、 「判定に作用するオプション」とADDMINEは#CHANGEOPTIONでは使えません。AUTOPLAY系列は、#OPTIONと#CHANGEOPTIONでは無効です。(つまりこの行は無効です)この例において、合計で 14 のオプション が強制的に適用されます。
nanasi と pomu2 では、実装されたオプションの探索が、メタゲームとして用意されています。
- 隠しオプションは、トライアル・モードにおける成功報酬としてリリースされます。
- BMS 側からオプションを強要するゲーム性が受け入れられるなら、それはリズムゲームの難易度の単線的な方向性に一石を投じるかもしれません。
#CHANGEOPTION[01-ZZ] optionID
| channel: | #xxxA6 |
|---|---|
| origin: | nanasi 1.550 |
| support: | nanasi 1.550+, Sonorous(parsing-only) |
- プレイオプションを、BMS 側から動的に変更します。
- 動的オプション変更チャンネルは、複数のオプションを同時に変更可能にするために、BGM チャンネルと同じ性質を持ちます。(複数行)
いくつかのオプションは、動的な変更を適用することができません。
HI-SPEED,CHANGE-HS,HIDDEN, およびCRAZYの各シリーズは、そのほとんどを使用することができます。GAMELEVEL,BASE-SPEED,RANDOM,NOTES,EXTRA, およびAUTOPLAYの各シリーズは、使用することができません。CRAZYシリーズでは、GOOD2BAD,GREAT2BAD,HELLJUDGE, およびADDMINEは使用することができません。CRAZYシリーズは、複数のオプションを適用することができます。
For example remarks #changeoption01 774:HIDDEN_STEALTH #changeoption02 774:HIDDEN_OFF #changeoption03 774:HI-SPEED_x0.25 #032a6:00000001 #034a6:02 #034a6:03この例において、
#032の 4 拍目で、ノートは全く表示されない状態になるでしょう。#034に達した瞬間、STEALTH 状態は解除され、ノートは再び表示されるでしょう (圧縮された形で)。nanasi の
optionIDについて: [詳細は option.htm を参照]category 1.500 以前 1.500 以降 GAMELEVEL774:GTP-EASY774:GAMELEVEL_BEGINNERHI-SPEED774:HSP-1.0774:HI-SPEED_x1.00CHANGE-HS774:HSP-COMBO774:CHANGE-HS_COMBO-UPHIDDEN774:HID-STEALTH774:HIDDEN_STEALTHRANDOM774:RND-MIRROR774:RANDOM_MIRRORNOTES774:CRA-CPDOUBLE774:NOTES_COPYCRAZY774:CRA-NORMAL774:CRAZY_OFFEXTRA774:GLV-VERYHARD774:EXTRA_VERYHARD- オプションを解除するコマンドは、
NORMALからOFFに変更されました。 - nanasi 1.552 は、旧
optionIDと新optionIDの両方をサポートしています。 - ただし、
#CHANGEOPTIONは古いoptionIDを無視します。
- オプションを解除するコマンドは、
#WAV[00-ZZ] soundfilename
| channel: | remarks | support |
|---|---|---|
#xxx01 | BGM (複数行) | ほぼすべて |
#xxx11-19 | 1P Visible Note | ほとんど (17 から 19 は部分的に) |
#xxx21-29 | 2P Visible Note | ほとんど (27 から 29 は部分的に) |
#xxx31-39 | 1P Invisible Note | ほとんど (37 から 39 は部分的に) |
#xxx41-49 | 2P Invisible Note | ほとんど (47 から 49 は部分的に) |
#xxx51-59 |
1P Long Note | RDM, DDR (Arrow mode only), nazo, nazoZZ, WAview, in_BM2, bme2wav, o2mania, Aqua (?), LR2, nanasi, ruvit, fgt++, fgt#, pomu2, BMSE, iBMSC, uBMplay, PMSee-V, bmx2wav, o2play, IIDXv, HDX, Angolmois, Sonorous, TechnicalGroove, diff ( |
#xxx61-69 |
2P Long Note | RDM, DDR (Arrow mode only), nazo, nazoZZ, WAview, in_BM2, bme2wav, o2mania, Aqua (?), LR2, nanasi, ruvit, fgt++, fgt#, pomu2, BMSE, iBMSC, uBMplay, PMSee-V, bmx2wav, o2play, IIDXv, HDX, Angolmois, Sonorous, TechnicalGroove, diff ( |
#xxx97 | BGM volume | forgetalia |
#xxx98 | KEY volume | forgetalia |
#xxxD1-D9 | 1P 地雷 | nanasi, LR2, fgt++, GDAC2+774gsc, PMSee-V (v1.11.0+), Angolmois, uBMplay (1.5.0+), Sonorous, TechnicalGroove ( |
#xxxE1-E9 | 2P 地雷 | nanasi, LR2, fgt++, GDAC2+774gsc, PMSee-V (v1.11.0+), Angolmois, uBMplay (1.5.0+), Sonorous, TechnicalGroove ( |
#xxx10 | 予約チャンネル | pomu2, Angolmois (--key-spec で指定されれば Visible Note, でなければ BGM),
Sonorous(?), TechnicalGroove(?) |
#xxx1A-1Z | 1P Visible Ex | pomu2, BMS List Sorter, bme2wav, bmx2wav, Angolmois ( BGM として: {BM98, BMSV, nBMplay, PMSee-V}( |
#xxx20 | 予約チャンネル | pomu2, Angolmois (--key-spec で指定されれば Visible Note, でなければ BGM),
Sonorous(?), TechnicalGroove(?) |
#xxx2A-2Z | 2P Visible Ex | pomu2, BMS List Sorter, bme2wav, bmx2wav, Angolmois (--key-spec),
Sonorous(?), TechnicalGroove |
#xxx30-6Z | Inv / LN Ex | 上記の拡張サポート状況に倣う |
#xxxD0-EZ | Landmine Ex | Angolmois (--key-spec), Sonorous, TechnicalGroove |
| index range: | origin | support |
|---|---|---|
[01-FF] (255) | BM98 | BM98, otama, nBMplay, BMSC, BMSV, bmse.kpi |
[01-FZ] (575) | BM98de | BM98de, DDR, RDM, MW, nazo, BMEV, bms2wav, BMSprinter |
[01-SF] (1023) | PMSee-V | |
[01-ZZ] (1295) | bemaniaDX | bemaniaDX, Mac, Aqua (?), GALLI, WAview, in_bm2, bme2wav, nazoZZ, DXEmu, o2play, O2mania, LR2, nanasi, ruvit, fgt++, fgt#, pomu2, uBMplay, IIDXv, HDX, PMSee-V (v2.1.0+), Angolmois, Sonorous, TechnicalGroove, GDAC2, BMSE, iBMSC, bmx2wav, woslicerII, woslicerIII, diff |
00 (地雷) | nanasi | nanasi, LR2, fgt++, GDAC2+774gsc, PMSee-V (v1.11.0+), Angolmois, uBMplay (1.5.0+), Sonorous, TechnicalGroove |
- 音声ファイルの定義。 WAV ファイルはほぼ確実にサポートされています。
- どのファイルタイプがサポートされるかは実装依存です。
#WAVxxは省略可能ですが、省略時は音は鳴りません。単一のファイルを複数のスロットに定義できます。 多重定義 はとても重要なテクニックです。
#WAV01 aaa.wav #WAV02 aaa.wav #WAV03 aaa.wav #WAV04 aaa.wav4 つのスロットに aaa.wav を定義した例。
多重定義
通常、
#WAVの同時発音数は 1 です。 しかし、複数の#WAVインデックスをネストすれば、同時発音数は増加します。image code remarks 
#00101:01 #00101:01 #00101:01 #00101:01この例で実際に鳴らされる aaa.wav は 1 個です。 
#00111:0100000000000000 #00112:0001000000000000 #00113:0000010000000000 #00114:0000000100000000この例では、次の aaa.wav が鳴らされるとき、前の aaa.wav の発音は常に中断されます。
音が中断されるとき、余計なノイズが発生するかもしれません。
#00101:01 #00101:02 #00101:03 #00101:04この例で実際に鳴らされる aaa.wav は 4 個です。
つまり、aaa.wav のボリュームは 4 倍になります。
#00111:0100000000000000 #00112:0002000000000000 #00113:0000030000000000 #00114:0000000400000000aaa.wav の音は中断されません。 実用的な例:
1 2 3 4 5 
- トレモロ中などの「故意でないノイズ」の生成を防ぐために。静かな音楽では、これは不可欠の技術です。
- タイミングを誤ったプレイによるノイズを生成しないために。深いリバーブが適用されたバスドラムなどで有効です。
短い音を擬似長音として鳴らすために。アーカイブのサイズを縮小できるかもしれません。
ただし、可視オブジェクトに対しては本物の長音を使うべきです。擬似長音が途中で鳴り止むと、プレイヤーはがっかりするからです。
- ボリューム増大のために。 ただし、この方法を用いる場合、私たちは音割れに注意しなければなりません。
- あえて 非多重定義 を用いる方法。 For example:
FINAL ATTACK RIDE D-D-D-DECADE
// wow, scratchy.
WAV について:
- WAV ファイルの量子化ビットレートは、PCM 8/16/24bit および IEEE Float 16/32bit が、BMS 中で使用された例があります。大部分は PCM 16 ビットです。
WAV ファイルのサンプリング周波数は、8000 から 48000 Hz が、BMS 中で使用された例があります。大部分は 11025/22050/44100Hz です。
- オートメーション工場 (automation factory, http://www.comeup.info/bofoon2007/automation.zip) は、8000 / 11025 / 12000 / 13275 / 16000 / 22050 / 24000 / 44100 Hz の WAV をすべて使用します。
- Angolmois は、11025/22050/44100Hz でないサンプリング周波数を正確に再生することができません。 これは SDL_mixer の制限です。
使用できる wav の長さを制限した実装があります。
- LR2 は、「60 秒より長い音声ファイルが定義された譜面」がインターネット・ランキングへ登録されることを禁止します。
- 更に LR2 には、BMS を MP3 に変換する機能があります。 しかし BMS が 60 秒より長い wav を含んでいる場合、LR2 はこの機能を禁止します。
- これらは著作権に違反する BMS への対抗策です。(商用タイトルのデータのクラッキングなど)
- したがって、LR2 ユーザの暗黙的な習慣として、60 秒より長い音声ファイルはもはやめったに使用されません。
uBMplay は、約 65500KB よりファイル・サイズが大きい wav を鳴らさないようです。
- (それが 44100Hz 16bit stereo である場合、65500KB は約 10 分間の長さに相当します。)
- これはたぶん、プログラミング言語の制限です。
BMS が常に正常な WAV を使用するとは限りません。
<fmt >チャンク以外のメタ情報 (たとえば Loop タグ) が、ヘッダやフッタに過剰に付加されている WAV- 古いバージョンの woslicerII など、特定の波形スライサーソフトウェアが出力することがある、
<data>チャンクが 0 Byte の WAV - リニア PCM でない RIFF WAV (前述の IEEE Float 型や、後述の mu-law など)
寛容なソフトウェアは、これらを鳴らすことができるかもしれません。 しかしエラーを返すソフトウェアも存在します。
OGG について:
モダンな実装は OGG をサポートしています。 (https://en.wikipedia.org/wiki/Ogg)
origin: DDR? support: DDR, LR2, nanasi, ruvit, fgt++, fgt#, pomu2, nazoZZ, iBMSC, uBMplay, PMSee-V, o2play, bmx2wav, IIDXv(註), HDX (註), Angolmois, Sonorous, TechnicalGroove, woslicerII, woslicerIII- 註: (IIDXv はデフォルトで
、HDX は設定を変更することで、) デコード後の WAV をキャッシュします。ディスクの空き容量に注意してください。 - [HDX v1.00 以降] デコード済み WAV をキャッシュする設定は削除されました。
- 註: (IIDXv はデフォルトで
DirectShow フィルタを適用すれば、BMSE は OGG を鳴らすことができます。 (これは非公式の振る舞いです。公式上のサポートはなされません。)
e.g. 次のうちのいずれかひとつ: [RadLight Ogg Media DirectShow filters] or [Open Codecs]
- OGG は、高品質の音声を手頃なサイズでやりとりできる、非常に便利なフォーマットです。
- しかしながら、プレイ時に OGG をデコードする必要があるので、WAV と比較すると非常に多くのメモリが必要になるのが難点です。
- この理由から、自分の手で OGG をすべて WAV に変換するユーザが、少なからず存在します。
- いくつかの実装は、非常に長い OGG を鳴らすことができないようです。(
PMSee-V など) (PMSee-V 2.1.2+ 再生可能になりました) - 私の誤解かもしれませんが、64-bit OS 上でエンコードされた OGG は、32-bit OS 上で鳴らないかもしれません。
マイナーなフォーマットについて:
いくつかの実装は MP3 をサポートしています。 (明示的か暗黙的かはさておき)
origin: DDR? support: DDR, RDM, MW, bemaniaDX, nazo, nazoZZ, Mac, Aqua, otama, WAview, in_bm2,
LR2, ruvit, pomu2, BMSE, iBMSC, uBMplay, MyO2, IIDXv(註 1), HDX
(註 1), Angolmois(註 2), Sonorous(註 2), TechnicalGroove- 註 1: (IIDXv はデフォルトで
、HDX は設定を変更することで、) デコード後の WAV をキャッシュします。ディスクの空き容量に注意してください。 - 註 2: 環境にもよりますが、再生できる形式のレギュレーションが厳しめです。
- 註 1: (IIDXv はデフォルトで
- しかしながら、プレイ時に発音が少し遅れるので、MP3 の使用は避けられる傾向があります。
いくつかの実装では、MIDI ファイルを
#WAVxxに定義することができ、鳴らすことができます。origin: DDR? support: DDR?, LR2, IIDXv, HDX, TechnicalGroove conditional: BMSE, iBMSC (もし、以下のレジストリキーに “Mid” があるなら、それは鳴るでしょう)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI Extensionsしかしながら、それがハードウェアにあまりに依存し、発音が遅れるので、MIDI はほとんど使用されません。
- IIDXv は、これらの問題を回避するために、ソフトウェア側で MIDI 演奏をエミュレートします。
- もちろん、IIDXv はハードウェア音源もサポートしています。
IIDXv は、ビープ音源による MIDI 演奏もサポートしていますが、
この機能は 64bit Windows7 で使用することはできません。HDX 0.99 以降、“inpout32.sys” & “inpoutx64.sys” ドライバを同梱することによって、ビープ音源による MIDI 再生が可能になりました (管理者権限のみ)。
IIDXv と HDX では、MIDI が
#WAVとして定義される場合、MIDI は BGM チャンネル#xxx01でのみ鳴らすことができます。- 複数の MIDI-BGM オブジェクトがある場合、最初のそれが鳴らされ、他のそれは無視されます。
これらに加えて、ADPCM, AAC, MP2, mu-Law, XA (“WAV to XA”, 解説), FLAC, MOD (file format) などをサポートする実装が存在します。
- しかしながら、ポータビリティの問題があるので、WAV および OGG だけが実際に使用されます。
代替検索:
モダンなアプリケーションは 拡張子の代替検索 を実装しています。
origin: DDR support: bemaniaDX, DDR, in_bm2, LR2, nanasi, ruvit, fgt++, fgt#, nazoZZ, pomu2, uBMplay, PMSee-V, bmx2wav, IIDXv, HDX, Angolmois, Sonorous, TechnicalGroove - BMS に定義されたファイルは、まずそのままのファイル名で検索されます。
見つからなかった場合、「定義と同じ基底名を備えた、ファイル・タイプが異なるファイル」が検索されます。
この時、検索されるファイル・タイプの優先順位は実装依存です。
- もし見つかれば、そのファイルが適用されます。
For example:
#WAV01 sample.wav- bemaniaDX では、ファイルは以下の順で検索されます:
sample.wav»sample.mp3 - DDR では、ファイルは以下の順で検索されます:
sample.wav»sample.mp3»sample.ogg uBMplay では、同じ基底名を備えたファイルが複数存在する場合、一番最初に見つかったファイルだけが適用されます。[uBMplay 1.4.6 以前]
sample.bmpが存在するなら、sample.oggよりも先にsample.bmpがマッチしてしまいます。[uBMplay 1.5.0 以降] この不具合は修正されました。
- LR2 では、「相対パスが定義され、指定されたディレクトリにファイルが存在しない」場合、他のディレクトリが検索されます。
- bmx2wav では、「
sample.wavとして定義されたsample.ogg」は検索されますが、 「sample.oggとして定義されたsample.wav」は検索されません。 - [Angolmois-Rust, Sonorous]
sample.rarが存在するなら、sample.wavよりも先にsample.rarがマッチしてしまいます。
- bemaniaDX では、ファイルは以下の順で検索されます:
この機能は非常に便利です。
なぜなら、WAV の編集し易さと OGG の配布し易さを、BMS の MD5 に影響を与えずに両立させることができるからです。
- これはインターネット・ランキングにおいて有利です。
- LR2IR と nazoIR は、MD5 によって BMS の同一性をチェックしています。
BMS がここにあると仮定しましょう。譜面ファイルの音声定義は以下のとおりです。
#WAV01 foo.wav #WAV02 bar.wavWAV 版はサイズが巨大なので、配布しやすいよう OGG に変換するとしましょう。
ここに、「最高音質の WAV 版 BMS」および「最適音質の OGG 版 BMS」があります。
OGG 版の譜面ファイルの音声定義は、以下のように置換します。
#WAV01 foo.ogg #WAV02 bar.ogg- 「品質を求めるプレイヤー」および「最適を探求するプレイヤー」の両者を満足させるために、WAV 版と OGG 版の両方が配布されます。
- しかしながら、定義の部分が変更されたので、譜面ファイルの MD5 は同一ではなくなっています。
WAV 版の譜面ファイルが OGG 版の譜面ファイルと異なる場合、面倒な問題が IR で生じます。
- IR の登録先は、WAV 版および OGG 版で別々に分かれます。
- その結果、IR ページはその BMS を遊んだ人が少ないかのように見えてしまうでしょう。
しかし、代替ファイル検索が使用される場合:
- クリエイター側は、同一の譜面ファイルを、WAV 版と OGG 版の両方に使用することができます。
- プレイヤー側は、WAV 版 と OGG 版を自由に選ぶことができます。さらに、自由に OGG を WAV に変更することができます。
- しかしながら、稀にですが、この機能は誤ったファイルを読んでしまうという危険性があります。
強調:
一部のアプリケーションは BGM と KEY の音量を差別化できます。
origin: LunaticRave (?) support: LR2, fgt, fgt++, Angolmois, Sonorous, TechnicalGroove, ... (調査中) - BGM の再生時音量を弱めることによって、KEY ノートは相対的に強調されます。
- TechnicalGroove は、KEY ノートの波形の先頭部分を強調します。
- 音量はそれぞれ制御可能かもしれません。
#WAVCMD commandID #WAV-index value
| channel: | #xxx11-49 |
|---|---|
| origin: | MacBeat |
| support: | MacBeat, Sonorous(parsing-only) |
#WAVで読まれたファイルを鳴らすとき、オプションとして、ピッチ、ボリューム、オーディオ再生時間を定義することができます。- これは、MOD もどきです。 (https://en.wikipedia.org/wiki/MOD_%28file_format%29)
#WAVCMDをサポートしないソフトウェアへの影響を避けるため、 このコマンドを含む BMS は、拡張子を MBM (MacBeatMod) に変更する必要があります。
commandID:-
変更するべきパラメータを指定します。
00ピッチを設定する 01ボリュームを設定する 02オーディオ再生時間を設定する #WAV-index:-
操作するべき音声を指定します。事前に定義済みの
#WAVのインデックスを指定します。[01-FF](255)MacBeat は、16 進数の
#WAVインデックスだけをサポートしています。 value:-
操作するべき「価」を 10 進数整数で指定します。
値が意味するものは、
commandID次第で変化します。pitch: [0-127]10 進数整数で値を設定します。 これは相対音階です。 デフォルトは
60です。A A# B C C# D D# E F F# G G# Octave1 0 1 2 3 4 5 6 7 8 Octave2 9 10 11 12 13 14 15 16 17 18 19 20 Octave3 21 22 23 24 25 26 27 28 29 30 31 32 Octave4 33 34 35 36 37 38 39 40 41 42 43 44 Octave5 45 46 47 48 49 50 51 52 53 54 55 56 Octave6 57 58 59 60 61 62 63 64 65 66 67 68 Octave7 69 70 71 72 73 74 75 76 77 78 79 80 Octave8 81 82 83 84 85 86 87 88 89 90 91 92 Octave9 93 94 95 96 97 98 99 100 101 102 103 104 Octave10 105 106 107 108 109 110 111 112 113 114 115 116 Octave11 117 118 119 120 121 122 123 124 125 126 127 volume: 10 進数整数 (パーセンテージ) で値を設定します。
100より大きい値を指定すると、音割れするでしょう。time: 「ミリ秒 × 0.5」に基づいて、オーディオ再生時間を指定します。
10 進数整数で値を指定します。
50ms 未満の値は、ほとんど信頼できないでしょう。0は、原音そのままの長さを意味します。 #WAVCMDを使用しない場合のデフォルト値:-
parameter default remarks pitch: 60相対音階は C6 です。 volume: 100相対音量は 100% です。 audio playback time: 0オーディオ再生時間は変更されません。 変更する必要のあるパラメータだけを変更してください。
典型的な例は次の通りです:
For example remarks #wav0E aaa.wav #wavcmd 00 0E 61 #WAVCMD 01 0E 50#WAVCMDの参照用に、オーディオファイルを定義しなければなりません。#wav0Eは、原音のピッチが 半音分 上昇します。#wav0Eは、原音の音量が 50% になります。- ある
#WAVインデックスに対して、複数のエフェクトを同時に適用することはできるのでしょうか？ #WAVCMDの重複について、MacBeatMod の仕様書には何も書かれていません。 (http://harinezumi.s14.xrea.com/download/mbm.txt)- 私は MacBeat を持っていないので、詳細をテストすることができません。
#EXWAV[00-ZZ] [pvf] [pan] [volume] [frequency] soundfilename
| channel: | #xxx11-69, #xxxD1-E9 |
|---|---|
| origin: | nanasi |
| support: | nanasi, Sonorous(parsing-only) |
- BMS の中で鳴らすべきファイルを、単純なエフェクトを適用して定義します。
#EXWAVxxのインデックスは、#WAVxxと共用です。[pvf]:-
どのパラメータを操作するべきかのフラグ。パラメータの記述子。
記述された文字に対応するパラメータが操作されます。
フラグを記述する順序は、後続する値が相当するに違いないパラメータを示します。
フラグは大文字小文字を問わず解釈されます。
For example remarks #EXWAV01 vfp -50 100 -10000 aaa.wav #EXWAV02 P 500 aaa.wavvolume=
-50, frequency=100, pan=-10000Pan=
500(nanasi は、デリミタとして複数の半角空白あるいはタブを使用することができます。)
このフラグが定義した順に、後続の値を記述してください。
- 注意:
- フラグが全く指定されない場合の振る舞いは保証されません。
[pan]:-
[-10000 - 10000]::-10000から10000までの範囲を、値として指定することができます。左右の
スピーカー装置波形 の音量バランスが定義されます。左端は
-10000です。右端は10000です。音源ファイルの L-R バランスが何であれ、この定義中のデフォルト値は
0にセットされます。このエフェクトは、ステレオの波形に適用可能です。
このエフェクトは、モノラルの波形にも適用可能です。
- 注意:
-
#EXWAVxxは、音量の増加をサポートしていません。したがって、バランスの変更は、L か R の音量を減少させることによって行なわれます。
「L-R バランスが 100%-0% である波形」に対して、値
10000が適用されたなら、完全な無音になるでしょう。
[volume]:-
[-10000 - 0]::-10000から0までの範囲を、値として指定することができます。音量が定義されます。
0は原音の音量です。-10000は実質的に無音になります。音源ファイルの音量が何であれ、この定義中のデフォルト値は
0にセットされます。これは、音量というよりは、減衰率です。
[frequency]:-
[100 - 100000]::100から100000までの範囲を、値として指定することができます。周波数が定義されます。 値の単位は Hz です。
要するに、このパラメータはピッチを操作します。
soundfilename:-
エフェクトを適用するべき音声ファイル名が定義されます。
#WAVxxと同様に、相対パスを定義できます。(「MATERIALS」は使用することができません。nanasi では、「MATERIALS」のサポートは ver.1.00 で削除されました。)
パスの長さは 260 バイト未満に制限されます。
#CDDA track-number
| origin: | DDR |
|---|---|
| support: | DDR |
- CD-DA を BGM として使用することができます。
DDRでは、「SYSTEM OPTION」の「CD-Syncro」の設定も適用されます。
For example remarks #CDDA 5この例は、CD ドライブに挿入された音楽 CD のトラック 5 を、BGM として鳴らします。
#MIDIFILE midifilename
| origin: | BM98 |
|---|---|
| support: | BM98, BMSV, DDR, RDM, Mac (?), Aqua (?), IIDXv, HDX, Sonorous (parsing-only) |
- MIDI ファイルを BGM として鳴らすことができます。
- ハードウェアに非常に依存します。あるいは、ソフトウェア・シンセサイザーでは発音が遅れます。
- これらの理由で、BMS で MIDI を使用することは推奨されません。
- しかしながら、MIDI を熱心にサポートしている IIDXv は例外です。
#BMP[00-ZZ] imagefilename
| channel: | remarks | support |
|---|---|---|
#xxx04 | BGA BASE | ほとんど |
#xxx06 | BGA POOR | ほとんど (註: IIDXv と HDX は除く) |
#xxx07 | BGA LAYER | ほとんど (註: IIDXv 2.13+, HDX 0.98+) (origin: BM98k) |
#xxx0A | BGA LAYER2 | nanasi, Angolmois (2.0a2+), Sonorous, BGAEncAdv |
#xxx0B |
BGA BASE の不透明度 | nanasi (透明 « [01-FF] » 不透明) |
#xxx0C |
BGA LAYER の不透明度 | nanasi (透明 « [01-FF] » 不透明) |
#xxx0D |
BGA LAYER2 の不透明度 | nanasi (透明 « [01-FF] » 不透明) |
#xxx0E |
BGA POOR の不透明度 | nanasi (透明 « [01-FF] » 不透明) |
| index range: | origin | support |
|---|---|---|
[00-FF] (256) | BM98 | BM98, BM98de, MW, otama, nBMplay, BMSC, BMSV, BMS2AVI, pomu2 |
[00-FZ] (576) | bemaniaDX | bemaniaDX, DDR, RDM, nazo, BMEV |
[00-ZZ] (1296) |
nanasi | GALLI, WAview, BGAenc, Mac (?), Aqua (?), LR2, ruvit, nanasi, fgt++, nazoZZ, GDAC2, BMSE, uBMplay, bmx2wav, IIDXv, HDX, Angolmois, Sonorous, BGAEncAdv |
- イメージファイルの定義。
通常のサイズは 256x256 ピクセル未満です。
- なぜなら、通常の実装のイメージ・キャンバスのサイズが 256x256 pixel だからです。
- 仕様は、オーバーサイズのイメージを処理する方法を定義していません。
- したがって、その方法は実装依存です。例えば、nazo はオーバーサイズのイメージを表示しません。
- バックグラウンド・アニメーションを使用しない場合は、省略可能です。
#BMPとして定義されたイメージは、#BGA,#@BGA,#SWBGAの定義中でも使用できます。 (もしそれらがサポートされていれば)#BMPインデックス00は、ミスした時に表示されます。#BMPインデックス00は、チャンネル#xxx06によってミス画像が変更されるまでの間、有効です。For example remarks #bmp00 miss-default.bmp #bmp11 miss-change.bmp #01606:0011#000の頭から#016の中間までの区間内では、ミスした時に
#bmp00が表示されます。そこから以降では、ミスした時に
#bmp11が表示されます。
空の #BMP による暗転
- イメージファイルが定義されないインデックスが、チャンネル
#xxx04/06/07で見つかったとき、BM98k は 256x256 の黒 (RGB:00:00:00) を表示します。 これは BMS の仕様書に書かれていない振る舞いですが、ほとんどのアプリケーションはこの振る舞いを踏襲しました。
For example remarks #BMP11 1.bmp #BMP22 2.bmp #BMP33 3.bmp #01604:112233FF#bmpFFは未定義です。譜面が FF に達したとき、イメージディスプレイは黒く塗り潰されます。
- しかし RDM では、
#BMPインデックスが[G-Z]を含んでいる場合、 LAYER が空の#BMPインデックスによってリセットされれば、他の無関係なイメージがランダムに表示されるでしょう。 - 互換性を維持したければ、私たちは暗黙の振る舞いを期待するべきではありません。定義を明示的に与えるべきです。
要するに、私たちは空の
#BMPインデックスを使用するのではなく、black.bmpの定義を使用するべきです。より安全な例 black.bmp (256x256) black.bmp (1x1) #BMP11 1.bmp #BMP22 2.bmp #BMP33 3.bmp #BMPFF black.bmp #01604:112233FFblack.bmp (256x256)
black.bmp (1x1)
私たちは要はイメージを変更したいだけなので、サイズは 1x1 で十分です。
さらに black.bmp は、カラーパレットが 2 色 (1ビット) あれば十分です。
減色によって、サイズは相当に減少します。
LAYER
LAYER チャンネル
#xxx07は、黒を透明にします。 イメージ中の黒い部分だけが透明になり、BASE チャンネル#xxx04を表示します。Sample code Image 実際の表示 #BMP01 1.bmp1.bmp
#BMP02 2.bmp2.bmp
#BMP03 3.bmp3.bmp
#BMP04 4.bmp4.bmp
#00104:01020304
#BMP05 5.bmp
#BMP06 6.bmp
#BMP07 7.bmp
#BMP08 8.bmp
#00107:05060708
一般的な実装では、BASE+LAYER が上記のように表示されます。
LAYER が透明にする黒の閾値は、デスクトップのプロパティ「画面のプロパティ » 画面の色」に依存します。
- 色が 16bit である場合、
RGB:00:00:00-RGB:0F:0F:0F(黒っぽい) が透明になります。 - 色が 32bit である場合、
RGB:00:00:00(完全な黒) だけが透明になります。 - つまり、「DirectX が値を丸めたときに
00にセットされる色」が透明になります。 - (私は誤解しているかもしれません。これはアプリケーション側の設定に関する記述かもしれません。)
- 色が 16bit である場合、
いくつかの実装は、この閾値を操作することができます。
uBMplay は
Transparent=0(ubm.ini) を変更することができます。値は
0から255を指定することができます。0は完全な黒です。255は完全な白です。- nanasi には、透明度と透過色の両方を詳細に操作することができるコマンドがあります。
#EXBMPと#ARGBを参照してください。
透明にできる色が黒に制限されているという事実は、ときどき不便です。
- 例えば、モノクロのアニメーションで LAYER を使用する場合に、完全な黒ではなく「黒っぽい色」を使用しなければなりません。
透明度には同じ問題があります。赤い BASE に青い LAYER を加えても、表示は紫になりません。
(BMS アプリケーションがアルファチャンネルをサポートしており、かつ LAYER 画像にアルファ値が指定されている場合は、例外的にブレンド可能)
- これらを解決することができる拡張コマンドを、nanasi は豊富に持っています。 しかしながら、それらを使いこなすのは非常に困難です。
- BGA クリエイターたちは複雑なプログラミングを望みません。 彼らはマルチメディア・オーサリング・システムを好みます。
補正
通常、イメージの X 軸の中心は、イメージキャンバスの X 軸の中心に表示されます。
- nanasi に関しては、BMP 以外のいかなるファイル形式も、X 軸センタリングを行ないません。
通常、イメージの上端は、イメージキャンバスの上端に表示されます。
この振る舞いに関しては、前述の例、および次の URL を参照してください: https://hitkey.nekokan.dyndns.info/bmse_help_full/Capture/bmse_bga_easypreview.gif
しかしながら、例外として、いくつかの実装はイメージに拡大縮小を適用します。
自動的な拡大縮小: MacBeat, LR2, ruvit, IIDXv, HDX- MacBeat は「256x256 より小さなイメージ」を 256x256 に拡大して表示します。
- LR2 は「256x256 より大きなイメージ」を「縦横比 1:1、サイズ 256x256」に変更し、それらを表示します。
IIDXv はすべてのイメージを「縦横比 1:1、サイズ 256x256」に変更し、それらを表示します。この表示方法を変更することができる実装もあります。
ruvit は、初期設定では 256x256 をベースとして、イメージを拡大表示します。
いくつかの実装は、256x256 より大きなサイズのイメージもサポートしています。
広がるキャンバス: BM98 (origin ?) (5KEYS | 5K-Couple only ?), DDR (origin), nanasi, fgt++, uBMplay (1.5.0+), IIDXv, HDX, Sonorous(?), BGAEncAdv, ... (調査中)- 256x256 より大きなイメージは、譜面表示用のスペースにさえ広がって表示されます。
演出効果としてこの振る舞いを使用した BMS が、わずかに存在します。 例えば:
- relative
- xra, (https://web.archive.org/web/*/http://xra000.hp.infoseek.co.jp/bms.htm)
- FIGHTING OF THE SPIRIT
- shammy, (https://web.archive.org/web/20140819192029/http://shammy.kdn.jp/bm/details.html)
- Chip Disco Paradise
- RED L:TUS,
- せがた三四郎伝説
- デッシュ, (https://www.nicovideo.jp/watch/sm351014)
- loves honey, crazy apple.
- World's endo pisum sativum L., (http://manbow.nothing.sh/event/event.cgi?action=More_def&num=28&event=44)
- LR2, ruvit,
IIDXv, HDXは「256x256 より大きなイメージ」を使用することができますが、イメージはキャンバスから溢れません。 - Sonorous では、独自拡張命令
#CANVASSIZEによって、キャンバスサイズを任意に変更できるかもしれません。
Image file formats
- どのファイル・タイプがサポートされるかは実装依存です。ビットマップ・イメージ・ファイルは、ほぼ確実にサポートされています。
BMP は RLE (Run Length Encoding) で圧縮されるかもしれません。 いくつかの実装は RLE を正しく表示できません。
BMSC
と BGAEncAdvは RLE をサポートしていません。 いくつかの実装は、行儀が悪い BITMAPINFOHEADER によって、強制終了させられます。筆者は確認できていませんが、OS/2 Bitmap を使用する BMS もかつて存在したようです。 (E.g. LOVE'S REBIRTH, positive dance "2nd RAVE") 詳細は bmpfmt.htm を参照。- モダンな実装は PNG をサポートしています。 近年、PNG は非常に頻繁に使用されます。 可逆圧縮は利便性が高いです。
- JPEG と GIF は、BMP と PNG ほどポピュラーではありません。
GIF にはライセンスの問題があります。 BMP 以外のイメージ・ファイル・フォーマットのサポート状況:
suffix support PNG: LR2, nanasi, ruvit, IIDXv, HDX, fgt++, pomu2, nazoZZ, uBMplay, bmx2wav, PMSee-V, PMChr-V, DTXV, Angolmois, Sonorous, BGAEncAdv , TechnicalGrooveJPG: otama, bemaniaDX, MacBeat, LR2, nanasi, ruvit, fgt++, pomu2, nazoZZ, BMSE, uBMplay, IIDXv, HDX, MyO2, PMSee-V, DTXV, Angolmois, Sonorous, BGAEncAdv , TechnicalGrooveGIF: bemaniaDX, BMSE, PMSee-V, pomu2 (Char), LR2, uBMplay (1.5.0+), Angolmois, Sonorous PNG (要 ifpng.spi): BM98de, DDR, RDM, MW, WAview, bms2avi JPG (要 ifjpeg.spi): BM98, BM98de, DDR, RDM, MW, WAview, bms2avi GIF (要 ifgif.spi): BM98de, DDR, RDM, MW, WAview, bms2avi, IIDXv (同梱), HDX (同梱) MAG: otama WMF: bemaniaDX, BMSE, PMSee-V EMF: bemaniaDX, BMSE, PMSee-V CUR: bemaniaDX ICO: BMSE, PMSee-V, pomu2 (Char) TGA: LR2, nanasi, ruvit, IIDXv, HDX, PMSee-V DDS: LR2, nanasi, ruvit, IIDXv, HDX DIB: IIDXv, HDX TIFF: Angolmois, uBMplay (1.5.0+), Sonorous(?) WebP: Angolmois, Sonorous(?) PNM (pbm, pgm, ppm): Angolmois, Sonorous(?) XCF: Angolmois, Sonorous(?) PCX: Angolmois, Sonorous(?) IFF/ILBM: Angolmois, Sonorous(?) PXR: uBMplay (1.5.0+ / 24-bit のみ / 無保証) いくつかの実装は、アルファチャンネルを備えたイメージをサポートしています。
Alpha-Channels: LR2, nanasi, ruvit, IIDXv, HDX, Angolmois (028e49caa6bd 以降), Sonorous, BGAEncAdv , TechnicalGroove, ... (未調査)モダンなアプリケーションは、イメージ・ファイルの代替探索も実装しています。
代替検索: LR2 (origin?), uBMplay, bmx2wav, IIDXv, HDX, Angolmois, Sonorous, BGAEncAdv , TechnicalGroove, ... (調査中)- 定義された BMP ファイルが見つからない場合、LR2 は、同じ基底名を備えた PNG および JPG を探索します。
#BMP へのビデオファイル定義
| channel: | #xxx04 |
|---|---|
| origin: | LR |
| support: | LR2, ruvit, nazoZZ, IIDXv (1 スロットのみ), HDX (1 スロットのみ), Angolmois (限定的なサイズと形式),
uBMplay (1.5.0+ / by DirectShow), Sonorous (限定的なサイズと形式?), BGAEncAdv |
| loop: | LR2 (部分的 ?), ruvit, uBMplay (1.5.0+), Angolmois, Sonorous, BGAEncAdv |
| rewind: | LR2, nazoZZ, IIDXv, HDX, uBMplay (1.5.0+), BGAEncAdv |
| body | MPG | AVI | WMA | WMV | OGV | WebM | OGM | MOV | M2P | MP4 | MKV | FLV | SWF | 3GP | ASF | M4V |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| LR2 | Yes | Yes | Yes | No | Yes | Yes | No | No | No | Yes? | No | No | No | No | No | No |
| ruvit | Yes | Yes | No | No | No | Yes | No | No | No | No | No | No | No | No | No | No |
| nazoZZ | Yes | Yes | No | No | No | No | No | No | No | Yes? | No | No | No | No | No | No |
| Angolmois | Yes | No | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| Sonorous | Yes | No | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| IIDXv, HDX | Yes | Yes | No | Yes | No | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| uBMplay | Yes | Yes | Yes | Yes | No | Yes | No | Yes | No | Yes | No | No | No | No | Yes | No |
| BGAEncAdv | Yes | Yes | ? | ? | Yes | Yes | ? | ? | ? | Yes | ? | ? | ? | ? | ? | ? |
| MyO2 | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | Yes | Yes | ? | ? | ? |
- 最も互換性が高い形式は MPEG1 (256x256) です。
#xxx04以外のチャンネルでのビデオ・ファイルの再生は保証されません。- BGAEncAdv は
#xxx[04|06|07|0A]のすべてのチャンネルで多重にビデオを再生できます。 しかし、これが普通だと思わないでください。
- BGAEncAdv は
- イメージの LAYER は、ビデオの上層に表示することができます。ビデオの LAYER は...??
- ビデオが音声を含んでいる場合、ビデオ中の音声は無音になるべきです。しかし、nazoZZ はビデオの音声を鳴らします。
以下の条件が満たされる場合、いくつかの実装はループ再生を行ないます:
- 他のイメージによって中断されずに、ビデオが最終フレームまで達した。
- BMS の演奏時間がまだ残っている。
この振る舞いをサポートする実装は、「汎用動画」を使いやすいでしょう。
E.g. Our moments (Kei + schneider murotani, )
いくつかの実装はビデオの再生位置を巻き戻すことができます。
たとえば “
#BMP01 mpg.mpg” は、“#00104:01010101” によって 4 回 「最初から再生」 されるでしょう。通常、ビデオの縦横比は 1:1 です。しかしながら、いくつかの実装は、4:3 や 16:9 などをサポートしています。
LR2 や IIDXv は、ビデオもサイズを補正できます。
- O2mania では、定義がなくても、BMS と同じ場所でビデオ・ファイルが見つかった場合、ビデオは
#000から再生されます。
- I give up. What is Codec? Delicious?
- イメージとビデオの表示方法は私にとって難しすぎます。私はまだほとんどこれらの詳細を理解することができません。
- 256x256 より大きなサイズを備えたビデオ・ファイルを使用する BMS のうちのいくつかは、 http://megaphone.blog64.fc2.com/blog-entry-907.html に列挙されています。
#EXBMP[00-ZZ] a,r,g,b imagefilename
| channel: | remarks |
|---|---|
#xxx04 | BGA BASE |
#xxx06 | BGA POOR |
#xxx07 | BGA LAYER |
#xxx0A | BGA LAYER2 (nanasi) |
| origin: | nanasi |
|---|---|
| support: | nanasi, Sonorous(parsing-only) |
- 透明色を調整したイメージ・ファイルを定義します。
#BMPxxと同様に、その色の近似色も透明にします。- 省略可。
#EXBMPxxのインデックスは#BMPxxと共用です。各パラメータは、
0から255までの 10 進数整数で指定します。パラメータのデリミタとしてコンマを使用します。param range remarks a[0-255]alpha r[0-255]red g[0-255]green b[0-255]blue for example remarks #exbmp01 0,0,0,0 overlay.png #00407:00000001値がすべて 0なので、透明化は行われません。 // ...? 要テスト#EXBMPとして定義されたイメージは、#BGA,#@BGA,#SWBGAの定義中でも使用することができます。 (それらがサポートされているなら)
#BGA[00-ZZ] [#BMP-index] x1 y1 x2 y2 dx dy
| channel: | remarks |
|---|---|
#xxx04 | BGA BASE |
#xxx06 | BGA POOR |
#xxx07 | BGA LAYER |
#xxx0A | BGA LAYER2 (nanasi, Angolmois(2.0a2+), Sonorous, BGAEncAdv |
| origin: | BM98de |
|---|---|
| support: | BM98de, DDR, MW, bemaniaDX, RDM, BMEV, WAview, nanasi, ruvit, uBMplay, BMSE, Angolmois, Sonorous, BGAEncAdv |
イメージ・ファイルの一部をトリムして表示します。値はピクセル単位です。
parameter summary remarks x1 y1トリム開始位置 オリジナルのイメージから切り抜かれた範囲の、左上隅 の座標 x2 y2トリム終了位置 オリジナルのイメージから切り抜かれた範囲の、右下隅 の座標 dx dy描画開始位置 描画する領域の、左上隅 の座標 For example:
元の画像: #BMP01 320x64.bmp切り抜く部分: 表示する部分: 
(64, 64) から (128, 128) までを切り抜く。
#BGA02 01 64 64 128 128 0 0キャンバスの (96, 96) に表示する。
#BGA03 01 64 64 128 128 96 96以下の URL は、BMSE による手順の例です:
- BMSE の
#BGA-UI はいまいちですが、それは#BGAコマンドの仕様がいまいちだからです。 - 通常、座標は、原点から右下方向に進みます。
しかしながら、負数座標が指定されれば、左上方向に進むでしょう。
- BM98de の描画方式:
-
DTX file format specifications から: http://dtxmania.net/attach/qa%255Fdtx%255Fspec%255Fe.bga%255Fdesc%255Fe.jpg
x1またはy1が負数である場合、以下の処理が行われます。- 最初に、負の数の値は
0にセットされます。(切り捨て) - 切り捨てた後の描画領域の左上角が、(
dx,dy) に表示されます。
- 最初に、負の数の値は
BMSE は負数座標をサポートしていません。
- トリムされたイメージ断片は、通常の
#BMPのように、チャンネル#xxx04/06/07および0Aにセットすることができます。 #BGAとして定義されたイメージは、#SWBGAの定義中でも使用することができます。(もしサポートされているなら)同じインデックスが
#BMPと#BGAに定義されている場合、#BGAが優先されます。For example remarks #BMP01 640x480.bmp #BGA01 01 178 99 434 355 0 0 #BGA02 01 179 98 435 354 0 0 #BGA03 01 179 97 435 353 0 0 #BGA04 01 180 96 436 352 0 0 #BGA05 01 181 95 437 351 0 0 #00104:0102030405#BGA01-05は、#BGAをサポートする実装で表示されます。#BMP01は表示されず、単に#BGAから参照されます。(あるいは「EOF の近くのライン」が採用される？ 仕様に書かれていないので、私は詳細をテストする必要があります。)
#BGAをサポートしない実装で、#BMP02-05が定義されなければ、#BMP01はしばらく表示され、直ちに消えます。Angolmois は、#BGAが同じインデックスの#BMPを参照することを許容しません。(例: 上記の#BGA01)[Angolmois e5cea53a2cbd またはそれ以降] この非互換性は修正されました。
#BGA の互換性について
あるいは #BGA の非互換性について。
| Name | #BGA |
#BMP |
0 0 1 1 |
Align | 1digit | Overlap | Nega | max-X | max-Y |
|---|---|---|---|---|---|---|---|---|---|
| BM98de | 00-ZZ | 0-255 [1] | 2x2 [2] | Yes | Yes | Yes | Yes | 4095 | 8190 |
| DDR | 01-ZZ | 0-255 [1] | 2x2 [2] | Yes | Yes | Yes | Yes | 4095 | 8190 |
| pomu2 | 01-ZZ | 1-255 [1] | 1x1 | Yes | Yes | Yes | Yes | ? | ? |
| MixWaver | 01-ZZ | 00-03 [3] | 1x1 | Yes | Yes | No | Yes | 638 | 478 |
| bemaniaDX | 00-ZZ [4] | 01-FZ [5] | 1x1 | Yes | No | Yes | Yes | 8128 | 8191 |
| Rhythm-it | 00-ZZ | 00-FZ | 1x1 | No | Yes | Yes | Yes | 8127 | 8190 |
| BMEV | 01-ZZ | 00-FZ | 1x1 | No | No | Yes | Yes | 70000+ | 65535 |
| WAview | 01-ZZ | 00-ZZ [6] | 1x1 | Yes | Yes | Yes | Yes [7] | ? | ? |
| nanasi | 00-ZZ [4] | 00-ZZ | 1x1 | Yes | No | No | Yes | 2147 | 2147 |
| ruv-it! | 00-ZZ | 00-ZZ | 1x1 | No | Yes | Yes | Yes [7] | 2147 | 2147 |
| Angolmois | 00-ZZ | 00-ZZ | 1x1 | Yes | No | Yes [10] | Yes | 16383 | [y1] 32767 |
| Sonorous | 00-ZZ | 00-ZZ | 1x1 | Yes | Yes [11] | Yes [11] | Yes | 16383? | [y1] 32767? |
| BMSE | 01-ZZ | 01-ZZ [5] | 1x1 | No | Yes | Yes | No | 32767 | 32767 |
| uBMplay -1.4.6 | 00-ZZ | 01-ZZ [5] | 1x1 | No | Yes | Yes | No | 4031 | 8190 |
| uBMplay 1.5.0+ | 00-ZZ | 00-ZZ | 1x1 | No | Yes | Yes | Yes | 4031 | 8190 |
| BGAEncAdv | 00-ZZ [4] | 00-ZZ [8] | 1x1 | Yes [9] | Yes | Yes | Yes [7] | 70000+ | 70000+ |
表の
#BGAカラムは、#BGAコマンドが使用できるインデックスの範囲を示します。01-ZZのグループは、#BGA00を#BMP00の代替として使用することができません。- BMEV と WAview はデフォルトのミス画像を表示できないので、暫定的に
01-ZZグループに分類しています。 - 註 [4]: 1 つ以上のイメージ・オブジェクトがチャンネル
04か07か0A(対応していれば) に存在するなら、#BGA00は使用することができます。
表の
#BMPカラムは、#BGAコマンドから参照できる#BMPインデックスの範囲を示します。註 [1]: 「16 進数インデックス
00-FFを 10 進数に換算した値」 が指定されなければなりません。36 進数インデックス
[G-Z]は使用できません。したがって、参照可能な画像は最大 256 ファイルです。- 註 [3]: 参照できる
#BMPは00,01,02,03の 4 スロットのみです。 他のインデックスを参照しても何も表示されません。 - 註 [5]:
#BMP00を参照することができません。 註 [6]:
100以上1295以下の 10 進数整数を指定すると、「36 進数の#BMP定義番号を、10 進数に換算した値」 として解釈されます。“
#BGAxx 099 ...” および “#BGAxx 009 ...” は#BMP09を参照します。- 註 [8]: ビデオファイルに対する座標指定も有効です。
“
0 0 1 1” カラムは、“x1 y1 x2 y2” パラメータがどのように扱われるのかを示します。- 大多数のアプリケーションは、この指定によって 「幅 1 pixel, 高さ 1 pixel」 の領域をトリムします。
- 註 [2]: BM98de と DDR は、この指定によって 「幅 2 pixel, 高さ 2 pixel」 の領域をトリムします。
Align カラムは、
#BGA内の 「連続する空白」 に対する寛容さを示します。区切り文字として使用可能なら “Yes” です。註 [9]: 空白のかわりにコンマ (U+002C) も使用できます。(BGAEncAdv の sample.bms を参照)
両者は混在できますが、もし 2 個以上のコンマが連続すれば (e.g. “
0,,0”)、BGAEncAdv は強制終了するでしょう。
1digit カラムは、
#BMPインデックスらしき指定に対する寛容さを示します。 “#BGAxx 1 ...” が#BMP01への参照として有効なら “Yes” です。- E.g. 風のたどり着く場所 (Extra-Mix) (猫蟹丸, )
- 註 [11]: Sonorous 0.1.0-pre () にて、この非互換性は修正されました。
Overlap カラムは、
#BMPと#BGAの定義番号の競合に対する寛容さを示します。#BGAが優先的に表示されるなら “Yes” です。For example Remarks #TITLE BMP vs BGA #BPM 120 #BMP01 1.bmp #BMP02 2.bmp #BGA01 02 0 0 255 255 0 0 #BGA02 01 0 0 255 255 0 0 #00104:0102このような曖昧な例が実際にいくつか存在します。
しかし BM98de 仕様は競合時の処理を規定していません。
#BGAが優先的に表示される保証はないので、私たちは曖昧な記述を避けるべきです。また、直接的なオーバーラップは Angolmois を強制終了させるでしょう。 (例: “#BGA01 01 ...”)註 [10]: Angolmois e5cea53a2cbd () にて、この非互換性は修正されました。
Nega カラムは、負数座標に対する寛容さを示します。私が知るサンプルはひとつしかありません。 (newbgatest.bms)
註 [7]:
- WAview はおそらく負数座標を表示できます。しかし WAview の座標の扱いは独特すぎるので、互換性がありません。
- ruvit は負数座標にタイル的な処理を加えます。したがって BM98de の表示とは異なります。
BGAEncAdv での表示は、BM98de とは微妙に異なります。
x1,y1,x2, あるいはy2が負数の場合、dxとdyの値が 2 倍になります。(バグ?)dxまたはdyの値が負数である場合、左方向または上方向へはみ出す部分はカットされません。これは BM98de や uBMplay 1.5.0 (またはそれ以降) と同じ振る舞いです。詳細は BGAEncAdv の sample.bms を参照してください。
max-X および max-Y カラムは、正確に表示できる座標の上限を示します。単位はピクセルです。
- これらの値はビデオメモリ128MB環境における調査結果です。ハイスペックなコンピュータでは異なる結果がもたらされるでしょう。
- これらの値よりも大きな画像を参照した場合、以下の不具合が発生する可能性があります: 表示されない、表示が崩れる、コンピュータの応答が停止する、etc.
FELYS の差分 は、
#BGAによって幅 3236 pixel のイメージファイルをスクロールします。(#066-073)この差分は BM98de & DDR & pomu2 専用です。そうでない形に書き直すことは可能ですが、MixWaver
, nanasi, ruvitはこれを表示できません。
#@BGA[00-ZZ] [#BMP-index] sx sy w h dx dy
| channel: | remarks |
|---|---|
#xxx04 | BGA BASE |
#xxx06 | BGA POOR |
#xxx07 | BGA LAYER |
#xxx0A | BGA LAYER2 (nanasi, Sonorous, BGAEncAdv |
| origin: | nanasi |
|---|---|
| support: | nanasi, Sonorous(parsing-only), BGAEncAdv |
- イメージ・ファイルの一部をトリムして表示します。
このコマンドは
#BGAのシンタックスシュガーであり、内部処理は#BGAと同じです。paramemter summary remarks sx syトリム開始位置 オリジナルのイメージから切り抜かれた範囲の、左上隅 の座標 w hトリムする距離 トリム開始位置からの、幅と高さ dx dy描画開始位置 描画する領域の、左上隅 の座標 - 切り抜くべきサイズが決まっている場合、
#@BGAは、#BGAよりも快適に記述することができます。
#POORBGA [0-2]
| origin: | nanasi |
|---|---|
| support: | nanasi, pomu2, Sonorous(parsing-only) |
POOR (MISS) イメージの表示方式が定義されます。
0:デフォルト。ミスを出したとき、数秒間チャンネル #xxx06に表示を変更する、オーソドックスなタイプ。1:BGA LAYER の上に
#xxx06を表示します。(ミスを出したとき)summary channel remarks BGA POOR (MISS) #xxx06top level BGA LAYER-2 #xxx0Asecond level BGA LAYER #xxx07third level BGA BASE #xxx04lowest level e.g. SigSig (from beatmaniaIIDX): https://www.youtube.com/watch?v=0UOx8sxzYgg
- ミスを出したとき、チャンネル
#xxx06は、通常のチャンネル#xxx04/07の上の層に重なって表示されます。 - その結果、「走って跪く少女」のイメージシーケンスが表示されます――ちょうど別種の LAYER のように。
- この例は BMS ではなく beatmaniaIIDX ですが、これに似ている演出効果を実現することができます。
2:非表示。
ミスを出したとき、表示はチャンネル
#xxx06に切り替わりません。通常のイメージシーケンスの表示が継続されます。- ミスを出したとき、チャンネル
uBMplay には
#POORBGAに似た機能があります。uBMplay は、イメージの表示方式を、以下のメニューから変更することができます。
label display channels NORMAL #xxx04+#xxx07ALWAYS MISS #xxx06OFF (非表示) BASE ONLY #xxx04LAYER ONLY #xxx07この機能はテストプレイで非常に役立ちます。
BGAEncAdv には
#POORBGAに似た機能があります。 (コマンドライン引数 “-l [0-2]”)-l 0Miss-layer only -l 1Show all layer // これは “ #POORBGA 1” と等価です。 なおかつ、“ALWAYS MISS” が適用されます。-l 2Standard (default)
#SWBGA[01-ZZ] fr:time:line:loop:a,r,g,b pattern
| channel: | #xxxA5 |
|---|---|
| origin: | nanasi |
| support: | nanasi, Sonorous(parsing-only) |
| caution: | これは試験的に実装されたコマンドです。今後、仕様が変更されるかもしれません。 |
キー押下に反応するイメージシーケンス。 これはキーバインド LAYER アニメーションです。
fr:-
フレームレート。 ワンフレームの所要時間 (-- アニメーションフレームの開始から終了までの経過時間、ミリ秒)
もしフレームレートが 60 FPS なら、値として 17 を指定します。 (Frames Per Second = 1000 / 60).
time:-
アニメーションの経過時間の合計。 (ms)
0 を指定した場合は、定義されたラインが押下され続けている間、アニメーションの表示が継続されます。
line:適用するべきラインのチャンネルを指定します。 値の範囲は
[11-19][21-29]です。loop:-
アニメーションが完了し、表示時間がまだ残っている場合にどうするか。
0:最後のフレームが保持されます。 「ループしない」 1:アニメーションが巻き戻されます。 「ループする」 a,r,g,b:Alpha channel, Red, Green, Blue. 値の範囲は
[0-255]です。デリミタはコンマです。pattern-
アニメーションのパターンを、BMS の MAIN DATA チャンネル・メッセージの記法を使用して記述します。 (e.g.
01020304)#BMP,#EXBMP,#BGA,#@BGAの各インデックスを使用することができます。(これらのインデックスは
#BMP族の間で共有される、本質的に同一のものです。)このコマンドは BMS の再生とは別のプロセスなので、分解能は存在しません。
通常のイメージ・コマンドとは異なり、
00は、そのまま#BMP00(/#EXBMP00/#BGA00/#@BGA00) のイメージを表示します。BMS code remarks 通常の記法: #00404:0011002200は 休符SWBGA の記法: #swbga01 100:400:16:0:255,255,255,255 0011002200は#BMP00したがって、表示するべきでないフレームがある場合、私たちは
00の代わりに透明なイメージか空の#BMPインデックスを指定する必要があります。
- さしあたり、複数の BGA スイッチングが同時に適用される場合の振る舞いは規定されません。
- 私がテストした限りでは、キーバインド・アニメーションは排他的で、新しい入力が優先的に表示されるようです。
example 1:
#SWBGA01 100:400:16:0:255,255,255,255 01020304 #070A5:01#070またはそれ以降で、チャンネル#xxx16(1P 側 SCRATCH) が入力されたとき、これは表示されます。- フレームレートは 10 FPS です。 (100 = 1000/10)
- 持続は 400ms です。
- ループしません。
タイムラインは以下のとおりです:
- キーが入力されれば、
#BMP01が表示されます。 - 100ms が経過すれば、
#BMP02が表示されます。 - 200ms が経過すれば、
#BMP03が表示されます。 - 300ms が経過すれば、
#BMP04が表示されます。 - 400ms が経過すれば、キーバインド・アニメーションの表示が終了します。
- キーが入力されれば、
#BMP01-04のイメージ中で、「完全に不透明で、完全に白い部分」は透明になり、通常の BMS のイメージシーケンスを表示します。
example 2:
#SWBGA02 50:0:11:1:255,255,255,255 01020304 #010A5:02#010またはそれ以降で、チャンネル#xxx11(1P 側 KEY1) が入力されたとき、これは表示されます。- フレームレートは 20 FPS です。 (50 = 1000/20)
- 持続は「KEY1 を押し続ける間」です。
- ループします。
タイムラインは以下のとおりです:
- キーが入力されれば、
#BMP01が表示されます。 - 50ms 経過時、キー押下状態がまだ保持されていれば、
#BMP02が表示されます。 - 100ms 経過時、キー押下状態がまだ保持されていれば、
#BMP03が表示されます。 - 150ms 経過時、キー押下状態がまだ保持されていれば、
#BMP04が表示されます。 - 200ms 経過時、キー押下状態がまだ保持されていれば、アニメーションは先頭に巻き戻されます。
- キーが入力されれば、
#BMP01-04のイメージのなかで、「完全に不透明で、完全に白い部分」は透明になり、通常の BMS のイメージシーケンスを表示します。
#ARGB[01-ZZ] a,r,g,b
| channel: | summary |
|---|---|
#xxxA1 | BGA BASE の描画時 aRGB 変更 |
#xxxA2 | BGA LAYER の描画時 aRGB 変更 |
#xxxA3 | BGA LAYER2 の描画時 aRGB 変更 |
#xxxA4 | BGA POOR の描画時 aRGB 変更 |
| origin: | nanasi |
|---|---|
| support: | nanasi, Sonorous(parsing-only), BGAEncAdv |
BGA の各層に適用されるべき aRGB の値が定義されます。デリミタはコンマです。
param range remarks a[0-255]alpha r[0-255]red g[0-255]green b[0-255]blue #ARGBの値は、不透明度チャンネル#xxx0B-0Eと共有されます。channel summary remarks #xxx0BBGA BASE's Opacity 透明 « [01-FF]» 不透明#xxx0CBGA LAYER's Opacity 透明 « [01-FF]» 不透明#xxx0DBGA LAYER2's Opacity 透明 « [01-FF]» 不透明#xxx0EBGA POOR's Opacity 透明 « [01-FF]» 不透明#xxx0B-0Eは透明度だけを変更できますが、#ARGBは透過色の変更も扱うことができます。#EXBMPは、各ファイルに適用されるべき aRGB です。 (単数掛け)#ARGBは、各 BGA チャンネルに適用されるべき aRGB です。 (全体掛け)- BGAEncAdv は、1 個以上のスペース (U+0020) もデリミタとして使用できます。
- BGAEncAdv は、ビデオファイルに対しても
#ARGBを適用できます。(sample.bms を参照)
#VIDEOFILE videofilename
| origin: | bemaniaDX |
|---|---|
| support: | bemaniaDX, TypeAce, Be-Pachi Music, RDM, ruvit, Sonorous(parsing-only) |
BGA として再生するビデオのファイル名を指定します。
filetype: MPEG のサポート: TypeAce, RDM, ruvit AVI のサポート: bemaniaDX, TypeAce, Be-Pachi Music, RDM, ruvit filename: bemaniaDX では、フルパスと相対パスも指定することができます。 loopable: 演奏時間が残っていれば、ビデオはループします。ビデオ再生は #000から開始されます。sounding: ビデオが含んでいる音声は鳴らされません。ビデオの音声は無視されます。 - AVI は、PC にインストールされたコーデックに依存します。
bemaniaDX の場合:
色が褪せる場合、
#VIDEOCOLORSのカラーパレット定義は、ビデオのカラーパレットより低いかもしれません。#VIDEOCOLORSを正確に指定してください。チャンネル
#xxx04,07, および06は、ビデオと同時に使用することができます。- チャンネル
#xxx04は、VIDEOFILE の上に積み重ねられます。 - チャンネル
#xxx07は、チャンネル#xxx04の上に積み重ねられます。
summary channel/header remarks BGA LAYER #xxx07top level BGA BASE #xxx04middle level VIDEOFILE #VIDEOFILEbottom level - チャンネル
- チャンネル
#xxx04および#xxx07両方の、黒い部分 (RGB:00:00:00) は、透明になります。 ミスを出したとき、チャンネル
#xxx04+#xxx07の表示は、チャンネル#xxx06のディスプレイに変わります。一定時間が経過すれば、再びチャンネル
#xxx04+#xxx07のディスプレイに戻ります。summary channel/header remarks BGA POOR #xxx06top level VIDEOFILE #VIDEOFILEbottom level 同様に、チャンネル
#xxx06の黒い部分 (RGB:00:00:00) は透明になります。
- RDM と ruvit では、VIDEOFILE と BGA のチャンネルは、どちらか片方だけが表示されます。(排他的な表示)
#VIDEOf/s n
| origin: | bemaniaDX |
|---|---|
| support: | bemaniaDX |
- ビデオのフレームレート (秒間表示フレーム数) が定義されます。
- 値として、小数を含む10進数を指定することができます。
- ビデオのフレームレートは、AVI ファイルのプロパティ「フレーム率」からチェックすることができます。(「n フレーム/秒」)
- このコマンドが省略される場合、AVI ファイルはファイル自身のフレームレートで再生されます。
再生速度を変更する例:
BMS code remarks #VIDEOFILE MOVIE.avi #VIDEOf/s 30MOVIE.avi ファイル自体のフレームレートは、15 フレーム/秒 です。
ビデオの再生速度は、30 FPS にセットされます。
MOVIE.aviは 2 倍速で再生されます。
#VIDEOCOLORS n
| origin: | bemaniaDX |
|---|---|
| support: | bemaniaDX |
- ビデオのカラーパレットを定義します。
- ビデオのカラーパレットは、AVI ファイルのプロパティ「ビデオ サンプル サイズ」からチェックすることができます。(「n ビット」)
- このコマンドが省略される場合、値には
16が適用されます。 (16bit color)
#VIDEODLY n
| origin: | bemaniaDX |
|---|---|
| support: | bemaniaDX |
- ビデオがどのフレームから再生されるかを定義します。つまり、ビデオのディレイをセットします。
- このコマンドが省略される場合、
#000の先頭位置で、0 フレーム目からビデオ再生が開始されます。 (遅延しない)
#MOVIE videofilename
| origin: | DXEmu |
|---|---|
| support: | DXEmu, IIDXv, HDX, Sonorous(parsing-only) |
- ビデオは
#000の先頭から再生されます。 #MOVIEおよびチャンネル#xxx04が競合する場合:- チャンネル
#xxx04がイメージ・ファイルである場合 (BMP、PNGなど)、#MOVIE側が優先されます。 - チャンネル
#xxx04と#MOVIEの両方がビデオ・ファイルである場合、チャンネル#xxx04側が優先されます。
- チャンネル
- ループしません。 演奏時間が残っている場合、ビデオは最後のフレームを表示したまま停止します。
- ビデオが音声を含んでいる場合、ビデオの音声は再生しません。
#SEEK[00-ZZ] n
| channel: | #xxx05 |
|---|---|
| origin: | LR |
| support: | LR, (LR2 で削除済み ?) |
- 現在のビデオの再生位置を、ミリ秒単位で変更します。
- 私は、このコマンドの詳細を全く知りません。
#ExtChr SpriteNum BMPNum startX startY endX endY [offsetX offsetY [x y]]
| channel: | #xxx05 |
|---|---|
| origin: | BM98 |
| support: | BM98k, DDR (部分的に) |
| detail: | BM98FinalSecret (http://bm98.yaneu.com/bm98/bm98secret.html) |
- BMS 側で準備した Extended-Character ファイルを、BM98 に適用します。
- プレイスクリーンに表示された要素はすべて、BMS 側が準備したイメージ・ファイルの一部と取り替えて表示することができます。
- これは、プレイ・スクリーンのユーザ・インタフェースをカスタマイズするコマンドです。
詳細:
SpriteNum:[0-1023](?)変更するキャラクタのインデックスを、内部的に準備されているキャラクタ・マップから選択して指定します。
BMPNum:[00-FF]-
#ExtChrが参照するために、ビットマップ・ファイルを事前に#BMPとして定義することが必要です。このファイルは切り抜かれるので、256x256 より大きなイメージも定義することができます。
実際には、仕様と異なり、#BMPインデックスは[00-09]あるいは[0-9]以外には指定することができません。[#BMP-index]の 16 進数を 10 進数に変換して、それを指定してください。おそらく、
-1と257は、BM98 のデフォルトテーマとして割り当てられています。これらも操作できるでしょう。 startX startY:トリム開始位置。オリジナルのイメージから切り抜かれた範囲の、左上隅の座標。
endX endY:トリム終了位置。オリジナルのイメージから切り抜かれた範囲の、右下隅の座標。
offsetX offsetY:-
切り抜いた座標に、オフセットを加えます。
- 例えば、イメージ・クリップがオフセット (-5, -10) を持っているとしましょう。
- このイメージ・クリップに対して、座標 (100, 120) への表示が命じられたとき、
- 実際には、座標 (95, 110) に表示されます。
オフセットが不要であれば、この「offsetX offsetY」パラメータは省略可能です。
x y:-
絶対座標を指定します。 静的な要素に対して指定されることが想定されています。
判定ライン直下のキーボード・イメージを変更する場合、など。
不要であれば、この「x y」パラメータは省略可能です。
このパラメータを指定する場合、「オフセット」が不要であっても、「オフセット」の指定は省略することができません。
単純な例:
#bmp00 custom_skin1.bmp #bmp09 custom_skin2.bmp #bmpFF custom_skin3.bmp #extchr 512 09 30 0 99 9 #extchr 514 255 38 11 62 19 #extchr 516 0 38 1 62 9 -2 -2 #extchr 513 0 38 1 62 9 -2 -2 0 0 #extchr 512 9 30 0 49 19// characterID- 512用のコマンドを上書きDDR は Project2DX フォーマットを部分的にサポートしています。(1P 用のデータのみ)
- このフォーマットは、1P 側 KEY6 および KEY7 に、チャンネル
#xxx21および#xxx22を割り当てる、スキンで実現する 7KEYS もどきです。 - これは 7KEYS をサポートする実装が存在しなかった時期の発明です。
BMS に以下の記述のいずれかが存在する場合、DDR は Project2DX 専用の処理を行ないます。
#ExtChr 730 -1 245 1 257 18 201 140 #ExtChr 774 -1 259 64 271 81 201 140 #ExtChr 780 -1 335 64 347 81 201 140 #ExtChr 779 -1 325 64 333 81 201 140 #ExtChr 745 -1 275 20 287 37 201 140 #ExtChr 771 -1 400 41 404 58 201 140 #ExtChr 760 -1 259 41 271 58 201 140 #ExtChr 784 -1 399 64 411 87 201 140#PLAYERの値に1が適用されます。- チャンネル
#xxx21および#xxx22は、#xxx18および#xxx19に置換されます。 - チャンネル
#xxx26(2P 側 SCRATCH) はすべて無視されます。
- このフォーマットは、1P 側 KEY6 および KEY7 に、チャンネル
- BM98de は、必ずしも
#ExtChrをサポートしていません。 - しかしながら、誤った解釈の結果、表示はたまたま変わるかもしれないように見えます。
私にはこのコマンドは難解すぎて、あまり理解できていません。実作例を参照してください:
九十九里 (TEM, ) (http://childs.squares.net/bms/index.html) (umi_99ri.rar の umi_99ri_3.bms)
MATERIALS
| origin: | BM98de |
|---|---|
| support: | BM98de, RDM, bemaniaDX, nanasi (1.00 未満) |
これは、「実行ファイルを起点とする、相対パスの定義」のエイリアスです。
- bm98body.exe と同位の「Materials」ディレクトリ配下に、新しいディレクトリを作成してください。
- この新しいディレクトリに、オーディオ・ファイルあるいはイメージ・ファイルを置いてください。
- BMS 側から “
<foldername>filename” を定義してください。 (ディレクトリ名は半角不等号で括る必要があります) - これによって、「Materials」配下ディレクトリのファイルも、BMS から参照できるようになります。
ディレクトリ階層の例:
bm98_beta1 ├ bm98body.exe ├ ... └ Materials └ samples ├ samplesound.wav └ sampleimage.bmp// 他の場所にある BMS #WAV01 <samples>samplesound.wav #BMP01 <samples>sampleimage.bmpこの BMS は、
samplesound.wavおよびsampleimage.bmpを、「bm98_beta1\Materials\samples\」からロードします。- 例えばこの機能によって、サウンドセットの管理が容易になるかもしれません。
- しかし、モダンな実装は、MATERIALS ではなくパスの定義をサポートしています。
#MATERIALSWAV path
| origin: | nanasi |
|---|---|
| support: | nanasi (1.00 未満) |
| caution: | このコマンドは旧式です。私たちはこのコマンドをもはや使用するべきではありません。 |
- Materials フォルダを起点とする相対パスを指定します。(260 バイト制限)
- このコマンドを含んでいる BMS は、音声ファイルをすべて Materials のパスから読み込みます。
優先順位は以下のとおりです:
1 通常の「MATERIALS」定義 #WAVxx <path>filename2 実行ファイルと同位の「Materials」フォルダ 他の実装と共有可能。 3 “ _datafiles\materials” (nanasigroove フォルダ内)nanasigroove 専用の「materials」フォルダ - 「MATERIALS」および
#MATERIALSWAVおよび#MATERIALSBMPのサポートは、nanasi 1.00 にて削除されました。
#MATERIALSBMP path
| origin: | nanasi |
|---|---|
| support: | nanasi (1.00 未満) |
| caution: | このコマンドは旧式です。私たちはこのコマンドをもはや使用するべきではありません。 |
- Materials フォルダを起点とする相対パスを指定します。(260 バイト制限)
- このコマンドを含んでいる BMS は、画像ファイルをすべて Materials のパスから読み込みます。
優先順位は以下のとおりです:
1 通常の「MATERIALS」定義 #BMPxx <path>filename2 実行ファイルと同位の「Materials」フォルダ 他の実装と共有可能。 3 “ _datafiles\materials” (nanasigroove フォルダ内)nanasigroove 専用の「materials」フォルダ - 「MATERIALS」および
#MATERIALSWAVおよび#MATERIALSBMPのサポートは、nanasi 1.00 にて削除されました。
#DIVIDEPROP n
| origin: | nanasi |
|---|---|
| support: | nanasi (0.98 未満) |
| caution: | このコマンドは旧式です。私たちはこのコマンドをもはや使用するべきではありません。 |
- BMS の小節の分解能を指定します。このコマンドは不要になったので削除されました。
- 今のところ、nanasi の分解能は、960 が自動的にセットされます。
- 分解能 960 は、浮動小数点を使用する擬似的なものです。
#CHARSET encode
| origin: | ruvit |
|---|---|
| support: | ruvit (2.0b5p2 未満) |
| caution: | このコマンドは旧式です。私たちはこのコマンドをもはや使用するべきではありません。 |
譜面が準拠する文字セットを IANA 登録名で指定してください。 (http://www.iana.org/assignments/character-sets)[EUC-KR|SHIFT-JIS|UTF-8]を値として指定することができます。 For example:#CHARSET EUC-KR- 日本語の IANA ライブラリ名は「Shift_JIS」(ハイフンではなく下線) なのですが、このコマンドには
SHIFT-JISを指定する必要があります。 - BOM (バイト・オーダ・マーク) がテキストファイル (BMS ファイル) に含まれている場合、
#CHARSETは BOM の内容に基づいて処理されます。 - EUC-KR/Shift_JIS 以外のエンコードで作成された BMS は、「BOM つき UTF-8」で保存して配布することが推奨されます。
- ruvit はバージョン 2.0b5p2 で全面的にユニコードをサポートしたので、
#CHARSETは削除されました。
- 今のところ、ruvit は charset を自動判別します。
ruv-it! | support page からの引用:
- ユニコードの対応:
-
BOM (Byte Order Mark) が含まれている場合、BOM の設定どおりテキストフォーマットを設定して読み込みます。 (UTF-8/UTF-16LE/UTF-16BE 対応)
BOM が含まれていない場合、DBCS LeadByte の頻度によって EUC-KR/Shift-JIS コードの中で判別し読み込みます。
もちろん、二つの言語コードのコード領域が重なったりして誤った結果が導出される場合もありますが、仕方ない…部分にしておきます。
このような処理によって、既存に作成された中国語・ベトナム語などのほかの言語でつくられた BMS の CHARSET が無視される問題が起こるようになったんですが
このような言語の場合には
#CHARSETを追加するより、ユニコード形式で保存することを誘導する方がずっと合理的だという判断をするようになりました。窮極的にはなるべく新しくつくられる BMS は UTF-8 フォーマットに保存されたらいいでしょうけど、受け入れられるか知れないですね。
Unicode のサポート
| origin: | ruvit |
|---|---|
| support: | ruvit, iBMSC, IIDXv (2.13+), HDX (0.98+), Sonorous, BGAEncAdv, TechnicalGroove |
- ruvit と iBMSC は、ASCII 以外のいくつかの文字セットをサポートしています。
- さらに、LR2 の次世代バージョンは、デフォルト文字セットとして、 ASCII ではなく BOM つき UTF-16LE を採用しました。
HTML5 仕様草案では、UTF-7 および UTF-32 の文字セットのサポートは削除されました。 (https://www.w3.org/TR/2008/WD-html5-20080122/)
Authors should not use JIS_X0212-1990, x-JIS0208, and encodings based on EBCDIC.
Authors should not use UTF-32. Authors must not use the CESU-8, UTF-7, BOCU-1 and SCSU encodings. [CESU8] [UTF7] [BOCU1] [SCSU]
BMS ファイルが Web アプリケーション中で使用される場合を想定したとき、UTF-7 および UTF-32 は障害になるかもしれません。
- IIDXv と HDX は、UTF-8, UTF-16LE, UTF-16BE をサポートしました (BOM 必須)。
- Sonorous は UTF-8 をサポートしました (BOM はオプションです)。
- BGAEncAdv と TechnicalGroove は、UTF-8 (BOM なし), UTF-8 (+BOM), UTF-16LE (+BOM), UTF-16BE (+BOM) をサポートしました。
%URL string
| origin: | BMS Manager |
|---|---|
| support: | BMS Manager, BMSC |
- メタ情報として、BMS 作成者に関するウェブページの URL を示します。
- これは BMS の構文解析とは無関係です。
- 私見では、予想外に有用です。
- 差分 BMS 配布時に、オリジナル BMS の獲得場所などの情報を示すことができるからです。
- 譜面が BMSE や iBMSC によって上書きされれば、このコマンドは削除されます。
%EMAIL string
| origin: | BMS Manager |
|---|---|
| support: | BMS Manager, BMSC |
- メタ情報として、BMS 作成者の E メールアドレスを示します。
- これは BMS の構文解析とは無関係です。
- 譜面が BMSE や iBMSC によって上書きされれば、このコマンドは削除されます。
<CONTROL FLOW>
| origin: | BM98 (http://bm98.yaneu.com/bm98/bmsformat.html) |
|---|---|
| support: |
BM98, BM98de, DDR, RDM, MW, bemaniaDX, nazo, Mac, Aqua, WAview, in_BM2, bms2wav, bms2avi, LR2, ruvit, nanasi, fgt++, fgt#, pomu2, nazoZZ, uBMplay, PMSee-V, IIDXv, HDX, bmx2wav, outliner, Angolmois, BMSE (partial), iBMSC (3.0+ / partial), Sonorous, BGAEncAdv, TechnicalGroove |
| 入れ子を外す: | RDM, bemaniaDX, nazo, nazoZZ, WAview, in_BM2, LR2, ruvit, fgt++, fgt#, uBMplay (1.4.6 以前), PMSee-V, bmx2wav |
| 入れ子を許す: | BM98, BM98de, DDR, MW, nanasi, Aqua, pomu2, BMSE (partial), IIDXv, HDX, outliner, Angolmois, uBMplay (1.5.0 以降), Sonorous, BGAEncAdv, TechnicalGroove |
#RANDOMは、1 からnまでの自然数のどれかひとつを生成します。 言うまでもなく、nには自然数を指定するべきです。#IFから#ENDIFまでの区間はブロック・ステートメントです。#RANDOMの生成値と同じラベルのブロックは、内容が適用されます。- 生成値に合わないブロックは、内容がすべて無視されます。
つまりこの構文は、「遊ぶつど変化する BMS」を作ることを可能にします。
- : BM98 は
#RANDOMを実装しました。 (#PLAYER 3(DP),#TOTAL,#xxx07(BGA LAYER), 等々よりも早期に) - この特徴は、beatmania の DJ BATTLE をエミュレートするために提案されました。
- 私が知る範囲で最古の無作為化 BMS は、FANKS "Anthology" COLLECTION (cranky, )
- 今なお、無作為化 BMS はリリースされ続けています。 e.g. DJ BATTLE 2011 (2106, )
- 詳しくは別項の作品リストを参照してください: [#RANDOM BMS list]
- : BM98 は
重要な点は、譜面の内容すべてを無作為化できる ということです。
- プレイ・オプションの RANDOM は、ノートのリズムを無作為化できません。
- コマンドの
#RANDOMは、より動的でより強力です。
基本的な例:
BMS code: 生成値 1 なら: 生成値 2 なら: #00111:11000000 #RANDOM 2 #IF 1 #00112:00220000 #ENDIF #IF 2 #00113:00003300 #ENDIF #00114:00000044
#00111:11000000 #00112:00220000 #00114:00000044
#00111:11000000 #00113:00003300 #00114:00000044- この例のトップレベルには、2 つの行と、1 つの
#RANDOMブロックがあります。 #00111:11000000と#00114:00000044は、#RANDOMの外部に書かれています。(top-level)したがって、
#RANDOMの生成値が何であれ、この 2 行は常に解析されます。この
#RANDOM文は、トップレベルに書かれています。 したがって、乱数は常に生成されます。- 1 が生成された場合、
#00112:00220000が適用され、#00113:00003300は無視されます。 - 2 が生成された場合、
#00112:00220000は無視され、#00113:00003300が適用されます。
- 1 が生成された場合、
#RANDOMをサポートしていない実装は、4 つのノートを表示するでしょう。
- この例のトップレベルには、2 つの行と、1 つの
悪い例推奨されない例: 共通部分の孤児化BMS code: 生成値 1 なら: 生成値 2 なら: #RANDOM 2 #00111:11000000 #00114:00000044 #IF 1 #00112:00220000 #ENDIF #IF 2 #00113:00003300 #ENDIF
#00112:00220000
#00113:00003300- ノーターは、この例が最初の例と同じ結果をもたらすだろうと期待しています。しかし、これは
構文違反です推奨されません。 - なぜなら、
#RANDOMブロックが#IFセクションに含まれていない行を含んでいるからです。 - ノート
11およびノート44はトップレベルに書かれていません。したがって、これらの孤児が表示されることは保証されません。 - BM98 や ruvit や uBMplay では、最初の例と同じ結果がもたらされます。しかし、nazo, LR2, BMSE 等では、これらの孤児は無視されます。
- それが「共通の一部分」である場合、私たちは
#RANDOMブロックの外部にそれを記述するべきです。
- ノーターは、この例が最初の例と同じ結果をもたらすだろうと期待しています。しかし、これは
入れ子の
#RANDOMの例:#RANDOM 2の 2 重の入れ子:生成値 1 » さらに生成値 1 なら: 生成値 1 » さらに生成値 2 なら: 生成値 2 なら: #00111:11000000 #RANDOM 2 #IF 1 #00112:00220000 #RANDOM 2 #IF 1 #00115:00550000 #ENDIF #IF 2 #00116:00006600 #ENDIF #ENDRANDOM #ENDIF #IF 2 #00113:00003300 #ENDIF #ENDRANDOM #00114:00000044
(pattern A)
#00111:11000000 #00112:00220000 #00115:00550000 #00114:00000044
(pattern B)
#00111:11000000 #00112:00220000 #00116:00006600 #00114:00000044(pattern C)
#00111:11000000 #00113:00003300 #00114:00000044- 入れ子の
#RANDOMを正しく解釈できる実装は少ないので、ご注意ください。 コードを読むことを簡単にするために、私は例の中でインデントと
#ENDRANDOMを使用しました。入れ子の
#RANDOMを実際に使用する場合、私たちはインデントを外し、さらに行末のスペースも削るべきです。#ENDRANDOMは省略してはなりません。 なぜなら nanasi は入れ子の#RANDOMでこれを要求するからです。トップレベルの行は常に解釈されます:
#00111:11000000,#RANDOM 2,#00114:00000044トップレベルの
#RANDOMの生成値が1なら、#00112:00220000が解釈されます。さらに、セカンドレベルの
#RANDOM文が解釈されます。- セカンドレベルの
#RANDOMの生成値が1なら、#00115:00550000が解釈されます。 - セカンドレベルの
#RANDOMの生成値が2なら、#00116:00006600が解釈されます。
- セカンドレベルの
- トップレベルの
#RANDOMの生成値が2なら、#00113:00003300が解釈されます。
この例は 3 つのパターンに分岐しますが、各パターンが選ばれる確率は 1/3 ずつではありません。
#00115:00550000が選ばれる確率は 1/4 です。#00116:00006600が選ばれる確率は 1/4 です。#00113:00003300が選ばれる確率は 1/2 です。
例えば、
#RANDOM 2を 6 重の入れ子にすれば、最深層のパターンは 1/64 の確率で選ばれるでしょう。(64 は 2 の 6 乗)同じことを実現するために、私たちは 64 個の
#IFブロックを書いても構いません。 それは無駄が多い反面、ほとんどの実装が解釈できます。
- 入れ子の
#RANDOMをサポートしていない実装は、全行をトップレベルの文として解釈し、解析を誤るでしょう。For example: Declinin' (sta, ) (download: 低級言語を労わる会) BMSE (部分的なサポート): https://hitkey.nekokan.dyndns.info/090102/090102_01.png BMSC (サポートしていない): https://hitkey.nekokan.dyndns.info/090102/090102_02.png iBMSC 3.0 (部分的なサポート): content/img/20120123_ibmsc30_random.png
「拡張コード」タブへの隔離は正確に行なわれます。 このタブは少なくとも 700,000 文字以上を確実に格納できます。
しかし現在の隔離は不完全であり、「編集パネル」にもフロー制御表現を表示してしまうでしょう。
- この BMS は、
#026-033で、40 個の#RANDOM文を使用して、音符のリズムを無作為化します。 - 概念図: https://hitkey.nekokan.dyndns.info/090102/090102_03.gif
BMSEは、
#RANDOMのセクションを解析することができ、「拡張命令」 タブにそれを分離することができます。しかしながら、この BMS のあまりにも多くの
#RANDOMブロックは、BMSE の 「拡張命令」 タブのキャパシティを超過するでしょう。この BMS によって、私は、「拡張命令」 タブが最大 65535 文字までであることを発見しました。
- この BMS は、
- 他のあらゆるコマンドよりも先に、コントロール・フローを解析する必要があります。
コントロール・フローは、ヘッダも含むあらゆるコマンド行を、変更する能力を持っています。
- e.g. オートメーション工場 (automation factory) (John "De Bello" Cage, ) (http://www.comeup.info/bofoon2007/automation.zip)
- この BMS は、音楽を無作為に自動生成します。
#TITLE,#RANK,#BPM[01-ZZ]はすべて、この構文によってコントロールされます。- また、行番号
347781-409539のセクションは、#IF 14(347780-409542) の子です。 - 6177 の
#RANDOM文がこの譜面に使用されており、そのうちの 1260 文は、347780 行目の#IF 14の子供です。 - この BMS は、「無制限の兄弟」 の格好のサンプルです。 これはベンチマーク BMS と呼ばれる kusofumen の典型的な例です。
- この BMS が、「無制限の子孫」 の要素を含まなかったことは、多くの実装にとって幸運でした。
- ほとんどすべての実装は、「無制限のコントロール・フロー」を解析することができません。
- ほとんどすべての場合に、無作為化できるヘッダは制限されます。あるいは、ステートメントの数が制限されます。
例えば、入れ子を許す実装では、理論上は半永久的な入れ子が可能なはずです。
- しかしながら、ネストの深さが何であれ、私たちはブロック終了コマンド
#ENDRANDOMを常に記述しなければなりません。 - なぜなら、
#ENDRANDOMのない#RANDOMステートメントが 47 回以上現われれば、nanasi が強制終了を行うからです。 - (これは nanasi のバグであるように見えますが、ひょっとしたら私の誤解かもしれません。)
- しかしながら、ネストの深さが何であれ、私たちはブロック終了コマンド
IIDXv と HDX と BGAEncAdv と TechnicalGroove は、
#RANDOM nが見つからなかった場合、デフォルト値1を適用します。- これは手打ち由来の単純な構文違反に対処するための方法のひとつです。
- (たとえば、
#random5(区切り文字が無い) や#rondam 5(誤字) など)
#RONDAM n
| origin: | uBMplay |
|---|---|
| support: | uBMplay, outliner, Sonorous, BGAEncAdv, TechnicalGroove |
- 誤字に対処するために。
e.g. 20,november "club edit" [random ver.] (cranky, )
- 366 行目に
#rondam 5が書かれています。この行が無視される場合、構文上の難問が生じます。 この
#RONDAMは 5 つの#IFブロックを持っていますが、それらをどのように扱えばよいのでしょうか？- ほとんどすべての実装は、その前の
#RANDOMの生成値を参照します。 - しかしながら、この振る舞いは仕様で指定されていないので、実装依存です。
- ほとんどすべての実装は、その前の
#RANDOMの範囲はどのように決定されるのでしょうか？ そんなものは存在せず、単に#IF-#ENDIFのセクションだけが存在するのでしょうか？疑わしいコードの例 remarks #00111:11 #RANDOM 2 #IF 1 #00212:22 #ENDIF #IF 2 #00313:33 #ENDIF #00414:44 #00515:55 #RONDAM 3 #IF 1 #00616:66 #ENDIF #IF 2 #00717:77 #ENDIF #IF 3 #00818:88 #ENDIF #00919:99この行はトップレベルにあるので、常に解釈されます。 ┐ │ │ │ │ │ ┆ #RANDOM がこの位置で閉じられているかどうかが分からなくなります。 ┐ 通常の場合なら、これらの行はトップレベルです。 ┘ しかし #RONDAM では、それは正しくないかもしれません。 ここは孤児ブロックになるかもしれません。 ] この行はコメントアウトされます。 ┐ │ 前の #RANDOM の生成値が 1 なら、このブロックも適用されます。 ┘ ┐ │ 前の #RANDOM の生成値が 2 なら、このブロックも適用されます。 ┘ ┐ │ 前の #RANDOM の生成値が 3 なら、このブロックも適用されます。 ┘ それは実現されないので、このブロックはいかなる手段でも適用されません。 ] この行はトップレベルでしょうか ? #RANDOM の外にあるのでしょうか ? 本当に ?もし最初の
#RANDOM 2が存在しなければ、前述の例で何が起こるでしょうか？nanasi は
#IFブロックを#IFブロックと認めません。つまり、
#IFブロックの内容は、「#RANDOMの外に書かれたコマンド行」と同じプライオリティで処理されます。- LR2 と uBMplay は、孤児の
#IFの内容をすべて無視します。(廃棄:#00616:66,#00717:77,#00818:88) - PMSee-V は以下のように警告します:
最初の
#RANDOMまたは#SETRANDOMより前に#IFが入っています！！
- 366 行目に
- コントロール・フローの問題は、構文エラーをいともたやすく書けてしまうということです。
- uBMplay の方法はアドホックかもしれませんが、仕様が詳細を定義していないので、仕方がありません。
#END IF
| origin: | uBMplay (1.5.0) |
|---|---|
| ad hoc support: | Angolmois (#END), outliner (#END), Sonorous (#END), BGAEncAdv, TechnicalGroove |
| たまたま解釈される: | nazo, rdm, ruvit, fgt++, fgt#, LR2, uBMplay (1.4.6 以前), PMSee-V |
最初の #IF が一致する場合に限り解釈される: | BM98k, BM98de, DDR, |
最後の #IF が一致する場合に限り解釈される: | nanasi |
- 誤字に対処するために。
e.g. Velocity Magic 3 [Aren't you lucky?] (Speed Magician / Transfero, ) (http://uploader.bms.ms/data/PW/vm3_ts3.zip) (現在 DL 不可)
- lovetricks.ogg の拡張子を、bms, bme, あるいは bml に変更してください。
#END IFは誤解に基づく誤字です。 あるいはこれも意図的なトリックのひとつかもしれませんが、私はそれについて興味がありません。- 通常の実装は、この行を無視します。 すなわち、これは「
#ENDIFの無い#IF」に関する問題です。 入れ子の
#RANDOMをサポートしない実装は、この例に容易に対処することができます。#IFブロックの中で、#ENDIFが見つかる前に別の#IFが見つかった場合、 「それは入れ子ではなく隣接兄弟ブロックである」と決めつけることができるからです。
入れ子をサポートする実装にとって、この例は面倒です。なぜなら、それが入れ子である可能性を無視できないからです。
- 私は、終了タグのない HTML を思い出します。HTML パーザは、XML パーザよりも困難な仕事をやり遂げなければなりません。
- BMS パーザは、HTML パーザのような能力を獲得するべきなのでしょうか？ 私は、BMS が XML 化するほうがよいと思います。
間違いの実例
#RONDAM n#END IF#ENDIFが無い#IF n＃ENDIF#RANDOMn#IFn#IFEND
参照: [#RANDOM BMS list]
上記のすべてに対応: uBMplay 1.5.2 以降, Sonorous (UTF-8 なら), BGAEncAdv, TechnicalGroove
#SETRANDOM n
| origin: | pomu2 |
|---|---|
| support: | pomu2, WAview, in_bm2, nanasi, Aqua, PMSee-V, IIDXv, HDX, outliner, iBMSC (3.0+ / partial), Angolmois, Sonorous, BGAEncAdv, TechnicalGroove |
| 類似の機能: | bms2avi (「SEED」 メニュー), bmx2wav (bmx2wav.ini の RandomConstantValue) |
#SETRANDOM nを#RANDOM nの代わりに記述すれば、定数nが生成されます。For example remarks // #RANDOM 3 #SETRANDOM 2 #IF 1 #WAV01 a.wav #ENDIF #IF 2 #WAV01 b.wav #ENDIF #IF 3 #WAV01 c.wav #ENDIF #ENDRANDOM- このサンプルは元々の
#RANDOM文をコメントアウトしています。 インデントをサポートする実装がまだほとんどないので、インデントの使用は時期尚早です。
サンプルコードを読みやすくするために、この文書ではインデントを使用します。
- この
#SETRANDOMは常に2を生成するので、ラベル「2」を備えたブロックが常に選ばれます。 - その結果、
#WAV01 b.wavは常に適用されます。 #SETRANDOM 2が指定されている限り、#IF 1および#IF 3は決して選ばれません。- 選ばれなかったステートメント・ブロックは単に無視されます。
- このサンプルは元々の
- おそらく
#SETRANDOMは、入れ子のコントロール・シンタックスをテストするために準備されたコマンドであるように見えます。
#ELSEIF n
| origin: | IIDXv |
|---|---|
| support: | IIDXv, HDX, outliner, Angolmois, Sonorous, BGAEncAdv, TechnicalGroove |
#ELSEIF n文は、#IF文と#ENDIF文の間のどこかに、何度か書くことができます。#ELSEIF n文は、もし#ELSEが存在するなら、#ELSEの前方に書くことができます。- もし必要がなければ、私たちは
#ELSEIFを書く必要はありません。 「生成値とラベルが一致するブロックのうち、最初のブロック」の内容が適用されます。 例 :
#RANDOM 5 #IF 1 #00111:UU #ELSEIF 2 #00112:VV #ELSEIF 3 #00113:WW #ELSE #00115:ZZ #ENDIF #IF 2 #00121:AA #ELSEIF 2 #00123:BB #ELSEIF 5 #00125:CC #ELSE #00126:DD #ENDIF #ENDRANDOM- 生成値が
1なら、以下が適用されます ：#00111:UU+#00126:DD - 生成値が
2なら、以下が適用されます ：#00112:VV+#00121:AA - 生成値が
3なら、以下が適用されます ：#00113:WW+#00126:DD - 生成値が
4なら、以下が適用されます ：#00115:ZZ+#00126:DD - 生成値が
5なら、以下が適用されます ：#00115:ZZ+#00125:CC
IIDXv と HDX では、
#IF-#ELSEIF-#ELSEの各ブロックは、相互に排他的な選択肢となります。生成値と一致する選択肢が見つかった時点で、以降の選択肢は読み飛ばされます。
- したがって、この例における
#00123:BBは、生成値が何であれ絶対に適用されません。 - outliner は、この排他的な挙動を未だシミュレートできていません。
- 生成値が
#ELSE
| origin: | nanasi |
|---|---|
| support: | nanasi, IIDXv, HDX, outliner, iBMSC (3.0+ / partial), Angolmois, Sonorous, BGAEncAdv, TechnicalGroove |
#ELSE文は、#IF文と#ENDIF文の間のどこかに、一度だけ書くことができます。#ELSE文は、もし#ELSEIFが存在するなら、#ELSEIFの後方に書くことができます。- もし必要がなければ、私たちは
#ELSEを書く必要はありません。 #ELSEが存在する場合、#IF-#ENDIFのステートメント・ブロックは、 「#IF-#ELSE」 と 「#ELSE-#ENDIF」 の 2 区間に分割されます。#ELSEがステートメント・ブロック中に存在する場合、次の処理が行なわれます。- ブロックのラベルが生成値と一致すれば、
#IF-#ELSEの内容が適用されます。 - ブロックのラベルが生成値と不一致なら、
#ELSE-#ENDIFの内容が適用されます。
- ブロックのラベルが生成値と一致すれば、
#ELSEがステートメント・ブロック中に存在しない場合、通常の処理が行なわれます。- ブロックのラベルが生成値と一致すれば、
#IF-#ENDIFの内容が適用されます。 - ブロックのラベルが生成値と不一致なら、
#IF-#ENDIFの内容は無視されます。
- ブロックのラベルが生成値と一致すれば、
For example:
#RANDOM 4 #IF 1 #00111:UU #ELSE #00112:VV #ENDIF #IF 2 #00113:WW #ELSE #00114:XX #ENDIF #IF 3 #00115:YY #ELSE #00116:ZZ #ENDIF #ENDRANDOM// 1 UU XX ZZ// 2 VV WW ZZ// 3 VV XX YY// 4 VV XX ZZ┐ │ │ IF-1 block │ ┘ ┐ │ │ IF-2 block │ ┘ ┐ │ │ IF-3 block │ ┘
- 生成値が
1なら、以下が適用されます:#00111:UU+#00114:XX+#00116:ZZ - 生成値が
2なら、以下が適用されます:#00112:VV+#00113:WW+#00116:ZZ - 生成値が
3なら、以下が適用されます:#00112:VV+#00114:XX+#00115:YY - 生成値が
4なら、以下が適用されます:#00112:VV+#00114:XX+#00116:ZZ
- 生成値が
別の例 (特別なパターンが、1/64 の確率で適用される譜面):
#RANDOM 64 #IF 1 // special pattern #ELSE // default pattern #ENDIF #ENDRANDOM- 生成値が
1なら、特別なパターンが適用されます。 - 生成値が
1以外なら、既定のパターンが適用されます。 #ELSEを使用しない場合、1 つの特別なパターンと、63 の既定パターンを記述しなければなりません。
- 生成値が
ナナシグルーヴ仕様には、
と書かれています。1-xまで全てのパターンを網羅する必要がある。- したがって、前述の 2 つの例は nanasi 仕様に違反しています。
- しかしながら、nanasi は前述の 2 つの例を正確に解析することができます。
- IIDXv と outliner も、前述の 2 つの例を正確に解析することができます。
- しかし、このようなフロー制御を行なうなら、私たちは
#ELSEではなく#SWITCHを使用するべきでしょう。
#ENDRANDOM
| origin: | nanasi |
|---|---|
| support: | nanasi, IIDXv, HDX, outliner, iBMSC (3.0+ / partial), Angolmois, Sonorous |
#RANDOMブロックの終了を明確に表現するためのコマンド。- ある
#RANDOMブロックは、1 つの#RANDOM文によって開始され、1 つの#ENDRANDOM文によって閉じられます。 #ENDRANDOMをサポートしない実装は、#ENDRANDOMを単に無視します。- もし
#ENDRANDOMが BMS の仕様に当初から含まれていたならば、プログラマの仕事は現在よりわずかに容易だったでしょう。 - しかしながら、そうではなかったので、
#RANDOMの解析は面倒な仕事になっています。
- もし
ナナシグルーヴ仕様には、
と書かれています。#ENDRANDOMは分岐を入れ子する場合必須。- しかし実のところ、
#RANDOMを入れ子にしない場合でも、私たちは常に#ENDRANDOMを書くべきです。 - なぜなら、
#ENDRANDOMのない#RANDOMステートメントが 47 回以上現われれば、nanasi が強制終了を行うからです。
- しかし実のところ、
nanasi を除くすべての「
入れ子の#RANDOMをサポートする実装」で、#ENDRANDOMは省略可能です。- したがって、さしあたり、
#ENDRANDOMは#RANDOMを nanasi に正確に解釈させる目的でのみ必要です。 - しかしながら、私は
#ENDRANDOMを常に書くことを推奨します。なぜならそのことによって、私たちが BMS コードを読みやすくなるからです。
- したがって、さしあたり、
IIDXv と HDX は、
#ENDRANDOMを見つけると、その階層の#RANDOMの生成値を1に戻します。- 逆にいえば、
#ENDRANDOMによる後処理が行われない限り、以前の#RANDOMの値が継承されます。
- 逆にいえば、
| origin: | nanasi |
|---|---|
| support: | nanasi, IIDXv, HDX, outliner, iBMSC (3.0+ / partial), Sonorous (parsing-only), BGAEncAdv, TechnicalGroove |
- これらはプログラミング言語の SWITCH 構文とほとんど同じです。
#SWITCHは、1 からnまでの自然数のどれかひとつを生成します。 言うまでもなく、nには自然数を指定するべきです。#SETSWITCH nが#SWITCH nの代わりに記述されれば、定数nが生成されます。これはテストプレイ時に有用です。#CASEのラベルnが、#SWITCHの生成値と一致するかどうかが評価されます。言うまでもなく、BMS パーザは、
#SWITCH以降に存在する各行を、行番号順に評価していきます。ラベルが一致した
#CASEから、#ENDSWまでの区間の、間にある内容が適用されます。- ラベルが一致した
#CASEと次の#CASEとの間に#SKIPが存在する場合、 解析は#SKIPから#ENDSWまでスキップされます。 - 次の
#CASEのラベルが目標値と一致しなくても、現在の#CASEと次の#CASEとの間に#SKIPが存在しないなら、次の#CASEの内容も適用されます。 つまり、ナナシグルーヴ仕様は フォールスルー を許容します。 #ENDSWは#SWITCHブロックを終了します。#ENDRANDOMの場合と異なり、ノーターは#ENDSWの省略を許されていません。#DEFも#CASEの代わりに使用することができます。#CASEがまだ目標値と一致していない場合、#DEFの内容が適用されます。ナナシグルーヴ仕様には次のように書かれています:
それまでの #CASE が不一致であった場合実行される。
しかしながら、
#CASEが既に目標値と一致していた場合でも、#SKIPが省略されれば、#DEFもフォールスルーによって適用されます。#DEFは、「#CASEがすべて不一致だった場合に適用されるべき、default の選択肢」として用意されたコマンドです (少なくとも nanasi では)。- したがってノーターは、1 つの
#SWITCHに対して複数の#DEFを書いてはなりません。 さらに、
#DEFが必要な場合、ノーターは他のすべての#CASEの後に#DEFを書くべきです。- このルールはナナシグルーヴ仕様に書かれていませんが、私たちはこのルールに従わなければなりません。
それは、nanasi が
#DEFを見つけた場合、#DEF-#ENDSW間にあるすべての#CASE/#SKIP/#DEFが機能しなくなるからです。つまり nanasi は、
#DEF-#ENDSWを 1 つのセクションとみなし、その間にあるすべての内容を適用してしまいます。IIDXv と HDX と outliner は、
#CASEよりも前に書かれた#DEFを、正しく解釈します。#DEFからのフォールスルーも有効です。#DEFと次の#CASEとの間に#SKIPが存在しない場合、解析は次の#CASEに流れ落ちます。
- 私は、「CASE より前にある DEF」やフォールスルーのようなスタイルは無作法であるように思います。 しかしながら、私はプログラミングに無知なので、態度を決めかねています。
For example:
BMS code remarks #SWITCH 5 #CASE 1 #00111:XX #CASE 2 #00112:YY #SKIP #CASE 3 #00113:ZZ #DEF #00114:AA #00115:BB #ENDSW- 生成値が
1なら、以下が適用されます:#00111:XX+#00112:YY - 生成値が
2なら、以下が適用されます:#00112:YY - 生成値が
3なら、以下が適用されます:#00113:ZZ+#00114:AA+#00115:BB - 生成値が
4なら、以下が適用されます:#00114:AA+#00115:BB - 生成値が
5なら、以下が適用されます:#00114:AA+#00115:BB
- 斜体は、それが
#SKIPの省略によって適用された行であることを表現します。 (すなわちフォールスルー。) - 実際に
#SWITCHを使用する場合、私たちはインデントを外すべきです。 (そうしなければ、nanasi は#SWITCHブロックをすべて無視するでしょう。)
- 生成値が
#SWITCHは、#RANDOMと同じ内容を、より巧みに示すことができるかもしれません。特別なパターンを 1/64 の確率で適用する例: #RANDOMの場合:#ELSEも使う場合:#SWITCHの場合:1/65535: #RANDOM 64 #IF 1 // special pattern #ENDIF #IF 2 // default pattern #ENDIF ... #IF 64 // default pattern #ENDIF #ENDRANDOM#RANDOM 64 #IF 1 // special #ELSE // default #ENDIF #ENDRANDOM註: nanasi 仕様に違反
#SWITCH 64 #CASE 1 // special #SKIP #DEF // default #SKIP #ENDSW#SWITCH 65535 #CASE 1 // special #SKIP #DEF // default #SKIP #ENDSW#RANDOMでは、ノーターはすべての選択肢を記述しなければなりません。この例なら 63 のデフォルト・パターンを書かなければなりません。#RANDOMをサポートする実装はすべて、この方法を解釈することができます。この方法の可搬性は最高です。- しかしながら、この方法は最も面倒なものであり、譜面のファイル・サイズは最大になります。
#ELSEは最も賢い方法です。 しかしながら、実害はありませんが仕様違反であり、適切ではありません。#SWITCHは次善の方法です。 非常に簡潔に記述することができ、確率も容易に調整することができます。
#SWITCHによって表現できる内容は、#RANDOMでも表現できます。 しかし、私は 65534 もの#IFを書きたいとは思いません。- 私は、同じパターンの重複が存在しない場合なら、
#RANDOMを使用することは適切であると思います。
次のルールが仕様に書かれていないことは、私を不安にします:
- ノーターは、各ラベルについて、昇順で記述しなければなりません。
- ノーターは、各ラベルについて、一度だけ記述しなければなりません。
それは
#RANDOMでも同様です。 いくつかの実装は、無作法な制御文を解釈することができます。しかし、すべてがそうであるとは限りません。BMSE がサポートしないコマンド行は、BMSE の 「拡張命令」 タブに分離されます。
- BMSE は、
#IF-#ENDIFの区間を解析することができ、「拡張命令」 タブにそれを分離することができます。これは非常に素晴らしい特徴です。 - しかし、BMSE は
#SWITCHをサポートしていないので、#SWITCHの区分内容は、単なるトップレベルのコードとして解釈されます。 - つまり、「
RANDOMized BMS を、BMSC で開いた場合」と同じ結果がもたらされます。 (https://hitkey.nekokan.dyndns.info/090102/090102_02.png)
- BMSE は、
コントロール・フロー自体を編集することができる BMS エディタは、いまだ存在しません。
もし存在しうるなら、それはアウトラインプロセッサのような形になるだろう、と私は推測しています。
ナナシグルーヴの仕様によると:
#SWITCHブロックは、#RANDOMブロックの中に書くことができます。#RANDOMブロックは、#SWITCHブロックの中に書くことができます。#RANDOMと#SWITCHは、無制限に入れ子にすることができます。
しかしながら、nanasi に実装されたコントロール・フローは不可解です。
#RANDOMを 90 層以上ネストすると、nanasi は強制終了を行うでしょう。(#SWITCHが混合されない場合)#SETSWITCHを 47 層以上ネストすると、nanasi は強制終了を行うでしょう。 (#RANDOMが混合されない場合)- nanasi は、
#RANDOMと#SWITCHを交互に入れ子にすることによって、約 100 層以上のネストを実現することができます。
- outliner で入れ子にできる制御文の層数は、Web ブラウザ側のレンダリング制限 に依存します。
IIDXv と HDX は、コントロール・フローに関する性能はベストです。
Indent style
| origin: | IIDXv | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| support: |
|
- タブ文字あるいは半角空白によるインデント。(IIDXv サポートページでは「段落化」と呼ばれています)
- 私は、これはノーターにとって非常に有用であると思います。 私はもはやインデントなしでコントロール・フローを書くことができません。
fgt, fgt++, fgt#, BGAEncoder (ヘッダ行のみ), BGAEncAdv, TechnicalGroove では、“
#” を除くあらゆる文字がインデントになってしまいます。- forgetalia シリーズは、コマンド行をコメントアウトできません。
- BGAEncoder は、ヘッダ行をコメントアウトできません。
- BGAEncAdv と TechnicalGroove は、“
//” を除き、コマンド行をコメントアウトできません。 - いくつかの BMS は、この仕様によって互換性を失います。
(例: FANKS "RANDOM" COLLECTION は
#randomを “/” でコメントアウトしています)
Comment syntax
| origin: | IIDXv |
|---|---|
| support: | IIDXv, HDX, outliner (エスケープは除く),
BGAEncAdv (“//” のみ),
TechnicalGroove (“//” のみ) |
- 譜面デバッグ用の、明示的なコメント構文です。
- コメント構文は、制御構文よりも優先的に解釈されます。
;： 単一行コメントの開始符。;から改行文字までの区間は、コメントとして無視されます。- これは DTX フォーマットの単一行コメントシンタックスと同一のものです。
//： 単一行コメントの開始符。//から改行文字までの区間は、コメントとして無視されます。- これは C 言語風プログラミング言語の単一行コメントシンタックスと同一のものです。
/*-*/: 複数行コメントの開始符と終了符。/*から*/までの区間は、コメントとして無視されます。- これは C 言語風プログラミング言語の複数行コメントシンタックスと似ていますが、
- コメントブロック内の改行文字が解釈される点に注意してください。
- ブロックコメントは入れ子にできません。
例 ：
before parsing after parsing remarks #TITLE foo-/*bar-*/baz; :) #RANDOM 23 #IF 1 #00111:XX #ELSEIF 2/* #00112:YY #ELSEIF ; */3 #00113:ZZ #ELSE//IF 4 #00114:AA #ENDIF //* #ARTIST foon /*/ #ARTIST asso //*/ #BPM 130#TITLE foo-baz #RANDOM 23 #IF 1 #00111:XX #ELSEIF 2 3 #00113:ZZ #ELSE #00114:AA #ENDIF #ARTIST foon #BPM 130プログラミング言語と異なり、
#ELSEIF 23という結果にはなりません。- これは 「1 行 につき 1 コマンド」 という BMS の仕様に準拠したから、とのこと。
- コメントアウトの結果として、文字
3だけが行に残されます。 - この行は、BMS の仕様上、暗黙的コメント行と解釈され、単に無視されます。
//*の先頭のスラッシュを 1 文字削除すると、この箇所は以下のようにコメントアウトされるでしょう ：
/* #ARTIST foon /*/ #ARTIST asso //*//* (another solution) #ARTIST foon /*/ #ARTIST asso /**/- このように、ブロックコメントのオンオフを簡単に切り替えることができます。
IIDXv と HDX では、コメント構文を無効化する手段が存在しません。
- 文字列値に使いたいコメントシンボルは全角文字に変更する方法が、IIDXv のドキュメントで提案されています。
- たとえば、
#ARTIST audio: foo // video: barは#ARTIST audio: foo ／／ video: barに変更する、など。 - 過去の BMS 作品などで修正ができない場合、IIDXv と HDX では
#ARTIST audio: fooと解釈されるしかありません。
IIDXv 2.13+ と HDX 0.98+ では、文字列のエスケープが提供されています。 (これはコメント構文を無効化するわけではありません)
- 文字列値を受け付けるコマンドはすべて、値を引用符 (U+0022) で括ることができます。
- 引用符で括られた文字列の中のコメントマークは、単なる文字列として解釈されます。
- また、エスケープ文字 “
\” (U+005C) を前置した文字は、単なる文字として解釈されます。
- 例 1:
#ARTIST C:\usr the "DPer" (http://hitkey.nekokan.dyndns.info/) -
IIDXv と HDX での表示: C:usr the DPer (http:
他ソフトウェアでの表示: C:\usr the "DPer" (https://hitkey.nekokan.dyndns.info/)
- 例 2:
#ARTIST C:\\usr the \"DPer\" (http:\//hitkey.nekokan.dyndns.info/) -
IIDXv と HDX での表示: C:\usr the "DPer" (https://hitkey.nekokan.dyndns.info/)
他ソフトウェアでの表示: C:\\usr the \"DPer\" (http:\//hitkey.nekokan.dyndns.info/)
- 例 3:
#ARTIST "C:\usr the "DPer" (http://hitkey.nekokan.dyndns.info/)" -
IIDXv と HDX での表示: C:usr the DPer (https://hitkey.nekokan.dyndns.info/)
他ソフトウェアでの表示: "C:\usr the "DPer" (https://hitkey.nekokan.dyndns.info/)"
- 例 4:
#ARTIST "C:\\usr the \"DPer\" (http://hitkey.nekokan.dyndns.info/)" -
IIDXv と HDX での表示: C:\usr the "DPer" (https://hitkey.nekokan.dyndns.info/)
他ソフトウェアでの表示: "C:\\usr the \"DPer\" (https://hitkey.nekokan.dyndns.info/)"
- HDX 0.99 以降、U+0022 で囲まれていない
“
\” (U+005C) は、エスケープされることなくそのまま出力されるように変更されました。
テストケース
BMIIDXView2010.txt から:
BMS code remarks #SWITCH 5 #DEF #00013:0055 #SKIP #CASE 1 #00013:0100000000000000 #RANDOM 2 #IF 1 #00014:04 #ELSE #00014:05 #ENDIF #CASE 2 #00013:0200000000000000 #SKIP #CASE 3 #00013:0300000000000000 #SWITCH 2 #CASE 1 #00016:1111 #SKIP #CASE 2 #00016:2222 #SKIP #ENDSW #SKIP #ENDSW- インデント
#CASEの前の#DEF#ENDRANDOMのない入れ子#RANDOM準備した
#IFの数より大きい目標値(註: ナナシグルーヴ仕様違反)
#SKIPの省略によるフォールスルー#RANDOMと#SWITCHが交互にされていない入れ子
- テストをパスする:
- IIDXv, HDX, outliner
- テストを部分的にパスする (が隔離に失敗する):
- iBMSC (3.0+)
オートメーション工場 (http://www.comeup.info/bofoon2007/automation.zip)
- 6177 の
#RANDOM文 / 147723 の#IF文 (無制限の兄弟) - ヘッダさえ含んでいるステートメント・ブロック
- 60,000行を超過する、巨大な入れ子の
#RANDOM(347781-409539) - あまりにも多くの、準備した
#IFステートメント数より大きい目標値 - 無作為化された
#TITLE(選曲画面や IR などにタイトルを使う実装では、たぶん大問題)
- テストをパスする:
- pomu2, IIDXv, HDX, outliner, Angolmois, uBMplay (1.5.0 以降), Sonorous, BGAEncAdv, TechnicalGroove
- テストを部分的にパスする (が、入れ子はすべて外される):
- uBMplay (1.4.6 以前), LR2, fgt++, ruvit, bmx2wav
#ENDRANDOMが補われるなら、nanasi もパスします。 (https://hitkey.nekokan.dyndns.info/a_lot_of_random_for774.zip)- 6177 の
20,november "club edit" [random ver.] (cranky, )
#RONDAMは誤字です。- テストをパスする: uBMplay, BMSE, outliner, Sonorous, BGAEncAdv, TechnicalGroove
Velocity Magic 3 [Aren't you lucky?] (Speed Magician / Transfero, ) (http://uploader.bms.ms/data/PW/vm3_ts3.zip) (現在 DL 不可)
- lovetricks.ogg » lovetricks.bms
#END IFは誤字です。- テストをパスする: nazoZZ, RDM, ruvit, fgt++, fgt#, LR2, uBMplay, PMSee-V, outliner, Angolmois, Sonorous, BGAEncAdv, TechnicalGroove
kitchen twies (Orange Strophe, ) (https://onedrive.live.com/?id=A1F351E1932E6FF7!282&cid=A1F351E1932E6FF7)
before after remarks #RANDOM 2 #00002:0.5 #00003:4F #IF 1 #00004:01 #00006:03 #ENDIF #IF 2 #00004:02 #00006:04 #ENDIF#00002:0.5 #00003:4F #RANDOM 2 #IF 1 #00004:01 #00006:03 #ENDIF #IF 2 #00004:02 #00006:04 #ENDIF- 不正な枝は、
#IFに属さない行を含んでいます。 - : このバグはパッチによって修正されました。
(私は、この問題を解決する必要性を理解しません。テストをパスするべきでしょうか？)むろん、テストにパスするのが望ましいです。BM98 はそのように
#RANDOMを実装しました。- テストをパスする: RDM, ruvit, nanasi, uBMplay, PMSee-V, bmx2wav, IIDXv, HDX, Angolmois, Sonorous, BGAEncAdv, TechnicalGroove, ... (未調査)
- 不正な枝は、
<CHANNEL>
チャンネル割り当て表
| num | summary | remarks | origin |
|---|---|---|---|
00 |
永久欠番チャンネル | いくつかの実装では: #xxx の先頭での BPM 変更 (削除済み) |
- |
01 |
BGM | #WAVxx (複数行) |
BM98 |
02 |
#xxx の長さ |
(1 は 4/4 拍子に相当) // 整数または小数を指定 | BM98 |
03 |
BPM 変更 | BPM 1 « [01-FF] » BPM 255 |
BM98 |
04 |
BGA BASE | #BMPxx (BASE は LAYER の下に表示される) |
BM98 |
05 |
Extended Object | #ExtChr (BM98 のみ) |
BM98 |
05 |
SEEK Object | #SEEKxx n (LR のみ) |
LR |
06 |
BGA POOR | #BMPxx (ミスを出した時、POOR が表示される) |
BM98 |
07 |
BGA LAYER | #BMPxx (LAYER は BASE の上に表示される) |
BM98k |
08 |
exBPM | #BPMxx n | #EXBPMxx n (実数) |
bemaniaDX |
09 |
STOP | #STOPxx n (1 は 192 分音符に相当) |
DDR |
0A |
BGA LAYER2 | #BMPxx (LAYER2 は LAYER の上に表示される) |
nanasi |
0B |
BGA BASE 不透明度 | 透明 « [01-FF] » 不透明 |
nanasi |
0C |
BGA LAYER 不透明度 | 透明 « [01-FF] » 不透明 |
nanasi |
0D |
BGA LAYER2 不透明度 | 透明 « [01-FF] » 不透明 |
nanasi |
0E |
BGA POOR 不透明度 | 透明 « [01-FF] » 不透明 |
nanasi |
11-1Z |
1P Visible | { BM98: 11-17, FlashTerminal: 18-19, MGQ: 1A-1F, pomu: 1G-1Z } | BM98/FT/MGQ/pomu |
21-2Z |
2P Visible | { BM98: 21-27, FlashTerminal: 28-29, MGQ: 2A-2F, pomu: 2G-2Z } | BM98/FT/MGQ/pomu |
31-3Z |
1P Invisible | { BM98: 31-36, FlashTerminal: 38-39, MGQ: 3A-3F, pomu: 3G-3Z } | BM98/FT/MGQ/pomu |
41-4Z |
2P Invisible | { BM98: 41-46, FlashTerminal: 48-49, MGQ: 4A-4F, pomu: 4G-4Z } | BM98/FT/MGQ/pomu |
51-5Z |
1P Longnote | { MGQ: 51-5F, pomu: 5G-5Z } | MGQ/pomu |
61-6Z |
2P Longnote | { MGQ: 61-6F, pomu: 6G-6Z } | MGQ/pomu |
70-96 |
予約チャンネル | [ 10, 20, 30, 40, 50, 60 ] も予約チャンネル |
- |
97 |
BGM volume | min 1 « [01-FF] » max 255 (最大は原音相当) // fgt only |
forgetalia |
98 |
KEY volume | min 1 « [01-FF] » max 255 (最大は原音相当) // fgt only |
forgetalia |
99 |
TEXT | #TEXTxx "string" |
pomu |
A0 |
JUDGE | #EXRANKxx n (100 は NORMAL 判定に相当 // 整数か小数を指定) |
nanasi |
A1 |
BGA BASE aRGB | #ARGBxx a,r,g,b (各 [0-255]) |
nanasi |
A2 |
BGA LAYER aRGB | #ARGBxx |
nanasi |
A3 |
BGA LAYER2 aRGB | #ARGBxx |
nanasi |
A4 |
BGA POOR aRGB | #ARGBxx |
nanasi |
A5 |
BGA KEYBOUND | #SWBGAxx |
nanasi |
A6 |
OPTION | #CHANGEOPTIONxx (複数行) |
nanasi |
D1-D9 |
1P Landmine | #WAV00 // [01-ZZ] でダメージ指定 (decimalize/2) // ZZ は即死 |
nanasi |
E1-E9 |
2P Landmine | #WAV00 // [01-ZZ] でダメージ指定 (decimalize/2) // ZZ は即死 |
nanasi |
KEY 割り当て表
| format | Visible Object Channel Mapping | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| BMS |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| BMS (nanasi-FP) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| BMS (Angolmois-FP) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| 縦連打測定器 (WayBack) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| DDR Arrow 6 |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| DDR Arrow 4/8 |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Project2DX |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| BME |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| BME (nanasi-FP) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| BME (Angolmois-FP) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| DSC / FPP |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| OCT/FP |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| PMS |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| PMS (BME-type) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| PMS (5button) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| PMS (pomu-battle) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| O2mania (?) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| MyO2 (?) |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| 未調査: |
GDA 9btn (feeling Pomu second), 16panel (D3beat), |
||||||||||||||||||||||||||||||||||||||||||||||||