BMS command memo (JP)

  • latest update:
  • written by hitkey

  • references:

    about BMS:
    This report referred to:
    BMS Format Specification: ()
    Basic specification of BML:
    BMS extensions proposed by Sonorous: ( から) (参考資料として)
    DTX file format specifications: (参考資料として)
    Guide to understand BMS format: () (参考資料として)
    Angolmois Internals: () (参考資料として)
    about obsolete MGQ notation: () (参考資料として)
    LR2beta3 スキンcsv仕様書 第五版: () (参考資料として)
  • 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 に関する大量のバグを修正した。 Valid HTML5 Valid CSS3
    • : 私は #TOTAL の項目を修正した。 (thanks to kisama)
    • : 私は iBMSC 3.0 の最新版を反映することを忘れていた。 私はそれに関して付け加えた。
    • : 私はすべての見出しにパーマリンクをセットし、さらにいくつかのアイテムを追記した。
    • : 私はこの文書をアップデートした。 修正箇所が多すぎて、私はそれらを思い出せない。
    • : 私はこの文書を日本語化した。 私のゲシュタルトは崩壊した。
    • : 私はこの文書を HTML 化した。 ファイルサイズは 4 倍になった。
    • : 私はこの文書を書き終えた。 私はプレーンテキストを単に <pre> タグで括った。
    • : 私はこの文書を書く気分になった。 私は書き始めた。

BMS apps:

このドキュメントは便宜的に以下の略称を使用します。 (公称とは異なる可能性があります。)

The name and version Abbr Description
Body (obsolete):
BM98 & BM98 kikuchan version 330 revision 42 BM98
BM98 Kikuchan Version 3.32β Drink Edition BM98de
music game quest ver2.18 MGQ
Delight Delight Reduplication Ver.0.50 beta5 DDR
rhythm-it 1.72a RDM
Mixwaver 1.6 Final & MixWaver][ 1.2 MW
BmDx Millennium Edition M6 (old document) BmDx
bemaniaDX Vision.3 APPEND Vision.4 Skin version 0.95 bemaniaDX
unofficial nazobmplay rev.798 nazo
unofficial nazobmplay rev.798 + Glasopal nazoZZ
BM2DXEmu a20 DXEmu
MacBeat 0.9.8.3 Mac
Aqua'n Beats 1.0.3 Aqua
ナナシグルーヴ ver.1.552 nanasi
forgetalia++ () fgt++ (DL 不可なう)
Body (current):
LunaticRave2 LR2 (現在、日本の事実上の標準)
ruv-it! 2.0 b5p7 test #7 () ruvit (現在、韓国の事実上の標準)
ナナシグルーヴ2 beta (Toy Musical 3 Ver.2.2) nanasi2
forgetalia# () fgt#
ふぃーりんぐぽみゅせかんど Ver 0.8001 pomu2
charatbeatHDX VIOLET (v1.05) HDX
Angolmois 2.0 e5cea53a2cbd Angolmois
Angolmois Rust Edition () Angolmois
Sonorous 0.1.0-pre () Sonorous
Editor:
BMS Creator 2.0b1 BMSC
beditor 1.3.1 beditor
GDA Creator Professional Edition Ver.0.24 GDAC2
GDAC2 ナナシグルーヴ拡張対応レーンスクリプト 774gsc (DL 不可なう)
BMx Sequence Editor 1.3.8 BMSE
BMx Sequence Editor dttvb-1.3.8 ( ver.) BMSE (LN の視覚化)
iBMS BMS Creator 3.0.5 Delta iBMSC
DTXCreator 026 () DTXC
Viewer (obsolete):
BMS Viewer 2.0 BMSV
BME(BMS) Viewer 0.04 BMEV
nBMplay v0.26a nBMplay
in_bm 1.17 (WAview) WAview (plug-in of Winamp ()
o2play o2play
Viewer (current):
uBMplay 1.5.2 uBMplay
PMSee-V v2.2.3 PMSee-V
BMIIDXView2010 v2.14 IIDXv
Others (obsolete):
otama Ver.0.991 otama (弾幕ゲー)
NINJA AGENT GALLI ver1.03 GALLI (アクションゲーム)
BMS Printer Ver.0.01 Pre-Release bmsPRN
bms2wav 0.07b / 0.07c bms2wav (ダウンロード不可なう)
bme2wav BETA 13 bme2wav
BmsToAvi 0.03c bms2avi
BGAEncoder 0.2a BGAenc (ダウンロード不可なう)
in_bm 2.01 in_bm2 (plug-in of Winamp)
BMS/BME/EMS plugin for KbMediaPlayer version 1.0r13 bmse.kpi

KbMedia Player Version 2.63a に同梱

Others (current):
bmx2wav 1.3.3 bmx2wav
PMChr-V v4.0.2 PMChr-V
woslicerII (wav ファイル切断兵器) woslicerII
woslicerII (バグ修正版? ) woslicerII
woslicerIII (要 .NET Framework 4.5 (Windows Vista 以降)) woslicerIII
BMx Outliner (for now, #RANDOM / #SWITCH viewer) outliner (web apps)
Starry Music Beat ver1.03 SMB (for iOS)
BGAEncAdvance Ver0.034 BGAEncAdv
bms diff tool diff (web apps)
lr2_pmsview_helper LR2PMS
to be tested:
o2mania 1.2.0 o2mania
MyO2 MyO2 (怒られたっぽいので載せるのやめ)
D3beat ver1.1 (jubeat style / Windows7 or later) D3beat
不可視地雷コンバータ for LR2 3-4toD-E
Sp2Dp ver_ SP2DP (ダウンロード不可なう)
BMSE ClipBoard Object Data Format to NoteDrop Converter BM-ND (web apps)
Be-Music Helper (beta 4′) (Windows Vista 以降) bmhelper
Mid2BMS Mid2BMS
[仮称] [更新停止] TechnicalGroove techGrv

latest collection:


BMS Format Specification に関するメモ

示されている最小限の要求仕様について:

  • 仕様の要約:

    • このファイルフォーマットは、1998 年に、Urao YaneNBK によって考案されました。
    • 誰でもこのフォーマットを自由に使用することができます。
    • # から始まる行はコマンド行です。 残りは全て無視されます (コメント用)。
    • コマンド行は大文字小文字を問いません。
    • コマンド行にはヘッダー文とチャンネル文の 2 種類があります。
    • この BMS ファイルは実行時にコンパイルされます。したがって、私たちはいかなる行も自由に命じることができます。

      • 引用者注: つまり、ヘッダ文は BMS のどこにでも記述できます。
      • 引用者注: ヘッダ文は必ずしもチャンネル文の前に記述されるとは限りません。
  • しかし、仕様の詳細は実装に依存します。

    • 例えばいくつかの実装は、特殊なケースにおいて大文字小文字を区別します。 e.g., #LNOBJ XX
    • 小文字の <HEADER> をまったく認識できない実装も存在します。(O2play)

仕様が示さない詳細な実装について:

  • ヘッダ文は、コマンドと値を分割するデリミタとして、1 個の半角空白を使用します。

    • #header value = # + header + + value
    • いくつかの実装は、デリミタとしてタブ文字も使用できます。
    • いくつかの実装は、連続するホワイトスペースを、デリミタとして許します。
    • いくつかの実装は、ホワイトスペースによるインデントを許します。
    • それらの特徴をサポートしないいくつかの実装は、BMS の解析を誤るかもしれません。
  • チャンネル文は、コマンドと値を分割するデリミタとして、1 個の半角コロンを使用します。

    • #xxxCH:00112233 = # + xxx + CH + : + 00 + 11 + 22 + 33
    • xxx: 小節番号 [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、あるいはそれ以外かもしれません。
  • 譜面ファイルは本質的にプレーンテキストです。 拡張子 TXTBMS に変更されれば、BMS アプリケーションは譜面を認識するでしょう。

    • BMS ファイルのエンコードを仕様は示していません。 この事実は、DBCS が改竄される問題を引き起こします。 (mojibake)
    • ほとんどの日本の BMS ファイルは 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...

      #TITLE (^^)♥♡♠♤♣♧♦♢♨☀☁☃☄☊☚☠♘☲☸♩♪♫♬♭♮filename: foon♥.bms

一般的な実装の挙動:

  • 同一のヘッダが重複する場合、EOF に近い側が採用されます:

    remarkssample 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 とは: )
      • #OPTION: [nanasigroove] 強制オプション
      • #SUBTITLE: [nanasigroove] 明示的な副題 / [Sonorous に限り、多重定義可能]
      • #SUBARTIST: [LunaticRave] 助力者情報 / [TechnicalGroove と Sonorous に限り、多重定義可能]
      • #COMMENT: [feelingPomu] 選曲画面上の字幕 / [Sonorous に限り、多重定義可能]
      • #LNOBJ: [Rhythm-it] ロングノート終端定義 / [TechnicalGroove に限り、LN 終端音声を複数定義可能]
    • 制御構文はさらに特別です。BMS の記法では、以下に示すコマンド群だけが、ブロック構造を構成します。

      • #RANDOM or #SETRANDOM

        • #IF
        • #ELSEIF
        • #ELSE
        • #ENDIF

        #ENDRANDOM

      • #SWITCH or #SETSWITCH

        • #CASE
        • #SKIP
        • #DEF

        #ENDSW

  • 同一の小節で同一のチャンネルが重複する場合、両方が合成されます。

    • しかしながら、この挙動は #xxx01 (BGM channel), #xxx02 (小節長), #xxxA6 (#CHANGEOPTION) には適用されません。
    • 複数行の BGM は、複数行の BGM として解釈されなければなりません。それらは合成されてはなりません。
    • 複数の #xxx02 チャンネル行が競合する場合、EOF に最も近い行が採用されます。
    • 動的オプション変更チャンネルは、複数のオプションを同時に変更可能にするために、BGM チャンネルと同じ性質を持ちます。
  • 行番号が大きい側が優先されます。 しかし、00 は古い場所を上書きしません:

    remarkssample BMS codecomment
    (行番号 100)#00113:11111111 // 1100110011001100
    (行番号 200)#00113:0022332255224400 // #001 のチャンネル 13 が重複
    (行番号 300)#00113:0066 // #001 のチャンネル 13 が重複
    構文解析の結果:#00113:1122332266224400// 3 行分がすべて合成される

    これは複雑なリズムを書きやすくするために用意された、BM98k の挙動です。

    • (最終的に合成される前提で) 行を分割して記述するテクニック は、とても興味深い表現を可能にします。
    • 最も徹底的にそれを成し遂げた作品は オートメーション工場 () です。
    • 最も控えめにそれを成し遂げた作品は Netzwerkgenen () です。
  • しかしあいにく、実装の約半数はこの仕様を満たしていません。 ( ... そもそもこれは 「要求仕様」 なのでしょうか ? )

    • チャンネル行の重複を考慮しない実装は、オブジェの数を正確には数えられないかもしれません。
    • pomu2 にはオブジェの配列を自動的に変更する機能があります。

      しかし、チャンネル行が重複する場合、この機能は正常に動作しません。

      (元の譜面を 5 回重複させた例: )

    • LR2 には pomu2 に似た機能があり、それは同様のバグを持っています。 LR2 は、重複した地雷チャンネルをうまく処理できません。
  • BMS パーザは、3 種類の改行コードが混在するファイルを読まなければならないかもしれません。 (CRLF, CR, LF)

  • BMS パーザは、改行を間に挟まない EOF を読まなければならないかもしれません。

    • For example: #08401:ZZ[EOF]

    私たちは、予想よりも多くのインライン EOF を見つけるでしょう。

  • 不正な値が与えられたチャンネル行を、どのように解釈するべきか、仕様は定めていません。

    sample BMS coderemarks
    #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
    // アスキーアート ()

    いくつかの実装 (nazo, uBMplay, LR2, etc) は、これらの解釈を試みます。 その方法は不明です。 「適切な解釈」の定義も不明です。

  • BMS パーザは、以下のようなヘッダ文を読まなければならないかもしれません。

    sample BMS coderemarks
    #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

    ()

    #bga01⇥ fz512␣␣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] をサポートしています。
  • いくつかの例外と注意点:

    appsremarks
    BMSV[000-511]
    DDR[000-998]
    bemaniaDX[000-399]
    GALLI[000-399]
    BGAenc[000-249]
    BMEVBMEV は #000 にしか内容が無い譜面を開くと強制終了します。
    RDMRDM は #000 にしか内容が無い譜面をスクロールすることができません。
    GDAC2GDAC2 は #170 以降で「貼り付け」を行うと強制終了します。 (Ver.0.20 にて修正済み)
    LR2

    可視オブジェまたはロングノートオブジェが #000 の先頭に存在するなら、 LR2 は #000 の直前に、#000 と同じ長さの空小節を挿入します。

    (これは、ゲームスタート時にユーザを当惑させないようにする方法のひとつです。)

    この機能は便利ですが、もしオブジェクトが #000#999 に存在する場合、譜面は正常に終了しません。

    pomu2

    キー音が鳴っている間は、pomu2 は譜面を終了させません。

    しかし、譜面が #999 を過ぎてもまだキー音が鳴っていた場合、pomu2 は強制終了するでしょう。

    otama

    otama のドキュメント () によれば: 小節の最大数は 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 由来のフォーマットが存在します。 詳細は を参照してください。

    • 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 シリーズの詳細は公式サイトを参照してください:

  • 譜面ファイルの典型的な拡張子については、次のセクションで詳述します。

BMS:

BMS は beatmania の模倣をその起源とするものです。 ()

それは 5 つの鍵盤 (x2) と 1 つのターンテーブル (x2) を持ちます。

歴史的経緯:

: beatmania が稼働しました。

: Urao Yane は 「Be-Music Data Format」 草案を NBK に提示しました。 これが今日の BMS フォーマットの基礎です。

: NBK は、Urao Yane の草案に基づいてハウスミュージックの譜面ファイルを作成し、 それを Urao Yane に提出しました。

: ゲームセンター 「チルコポルト」 で開催されたオフ会において、Urao YaneBM98 ver 1.00 を示しました。

: Urao Yane彼自身のホームページ を作成し、BM98 ver 1.03 をネット上で公開しました。

: Kazutoshi TakataBMS Viewer Version0.8 を公開しました。

: Urao Yane は BM98 の公開を一時的に停止しました。

: TIXBMS Creator v0.02.02 を公開しました (改版履歴)。 ...私たちは、ついにテキストエディタから解放されました。

: Urao YaneBMS Format Specification を示しました。

originBM98
supportBMS の全実装
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

各ヘッダの詳細は別項にて。

各チャンネルの詳細:
numberobject to changeremarks
#xxx01 BGM #WAVxx に定義したファイルを、自動的に鳴るべき音声オブジェクトとして配置します。
#xxx02 小節長

#xxx02 は拍子を操作します。

  • 小節長は整数または浮動小数点によって指定されます。

    • 値 1 は 4/4 拍子です。 #xxx01:11223344 // 長さは 4 個の四分音符と等価です。
    • 値 2 は 8/4 拍子です。 #xxx01:1122334411223344 // 長さは 8 個の四分音符と等価です。
    • 値 0.75 は 3/4 拍子。 #xxx01:112233 // 長さは 3 個の四分音符と等価です。
    • 値 0.015625 は 1/64 拍子。 長さはたった 1 個の 64分音符と等価です。

      1/64 は BMSE が編集できる長さの最小です。

    • 値 0.01 は、通常の 4 拍子小節の 1% の長さと等価です。

      BMSE は 0.01625 の倍数として長さを扱うので、BMSE はこの値 0.01 を丸めます。

      BMSE rounds a value 0.01 and changes it into 0.01625

    • BMSE と beditor は、長さを音符と関連づけて扱うため、音楽的な観点からの譜面編集が容易です。 つまり、BMSE と beditor は 変拍子 の編集に長けています。
    • BMSC と GDAC2 は、単純な長さとして長さを扱うので、パーセンテージによる譜面編集が容易です。 つまり、音楽と無関係なスクロール速度変更の編集に長けています。

      BPM小節長比率 = 変化後 BPM / 変化前 BPM
      1211.008333333333333121/120 (BMSE は正しく解釈できない)
      1201120/120 (BMSE は正確に解釈できる)
      1190.991666666666666119/120 (BMSE は正しく解釈できない)

      実際の BPM が変わらない状況で、譜面のスクロール速度だけを変更する演出は、日本では俗にソフランと呼ばれます (soft landing)。 これに関するジョーク BMS を ジョークサイト からダウンロードできます。

    • 3.0 以降の iBMSC は、両者のハイブリッドです。 理論上、私たちに編集できないリズムはもはや存在しません。
  • BMS において、#xxx02 の値は、それが指定された小節のみに作用します。

    曲が完全に三拍子である場合、すべての小節に #xxx02:0.75 を指定しなければなりません。

  • DTX において、#xxx02 の値は、別の #yyy02 が現れるまで有効になります。

    曲が完全に三拍子である場合、必要なことは #00002:0.75 を一度指定するだけです。

  • BMS において、デフォルト値 1 は、小節長が省略された小節に対して、暗黙に適用されます。
  • もし #99902 が存在すれば、nazo はスクロールが #999 に達するまで譜面を終了しないでしょう。

    • たとえ音楽が既に終了していたとしても、#xxx02 が音楽の終点以降に記述されれば、 あたかも未処理のオブジェが残っているかのように、nazo は誤解してしまうでしょう。
    • BMSE において、拍子タブの全選択ボタンは #000-#999 をすべて選択します。
    • この状態から 3/4 が指定されれば、#000-#999 はすべて 3/4 表示に変更されます。
    • 例えば、三拍子の譜面を編集する場合、この機能は非常に便利であるに違いありません。
    • しかしながら、nazo が愚かなので、私たちはこの機能に仕事を任せることができません。
    #TITLE test 33 分間継続する機種
    #BPM 120
    #00111:01
    #99902:1
    nBMplay, BMEV, DDR, RDM, nazo, IIDXv, HDX, Angolmois
  • BM98 は小節長チャンネルを実装していましたが、それは仕様書の中で示されませんでした。

    おそらくはそのために、拍子の概念はいくつかのゲームに伝わりませんでした。

#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
  • #xxx17ターンテーブルを自由にスクラッチできる区間 をセットします。

    • 「オブジェを置いた位置」から「四分音符 1 個分」の長さは、1 個の FREE-ZONE になります。
    • FREE-ZONE が閉じる前に、新しいオブジェが #xxx17 に置かれれば、FREE-ZONE は延長されます。
    • #xxx17 がセットした区間内に #xxx16 の SCRATCH があれば、 SCRATCH は FREE-ZONE に重なって表示されます。

      #00611:0011000000000000
      #00614:1400001400000000
      #00616:0000000000160000
      #00617:0000000017000000

      “u gotta groove” #006 (from beatmania 2ndMIX)

    • 1 個の FREE-ZONE は、長さが何であれ、1 個の演奏するべきノートとして数えられます。
    • FREE-ZONE 内のターンテーブルオブジェは、個数が何であれ、演奏すべきノートには計上されません。
    • 1 個の FREE-ZONE 内に 1 個以上のターンテーブルオブジェがある場合、判定は 3 種類に分岐します。

      1. それらをすべて最良のタイミングで演奏した場合、「オブジェ 1 個分のベストスコア」を得ます。
      2. FREE-ZONE 区間内で一度もスクラッチがなされない場合、点数は得られません。
      3. 他の場合、オブジェ 1 個が悪くないタイミングで演奏されたことになり、そこそこの点数を得ます。
    • 1 個の FREE-ZONE 内にターンテーブルオブジェが無い場合、判定は 2 種類に分岐します。

      1. FREE-ZONE 区間内で一度もスクラッチがなされない場合、点数は得られません。
      2. 他の場合、オブジェ 1 個が悪くないタイミングで演奏されたことになり、そこそこの点数を得ます。

      スクラッチ無しの FREE-ZONE が譜面内に 1 箇所でも存在する場合、「パーフェクト」は絶対に取れません。

    • #xxx16#xxx17 に割り当てる音と、実際に鳴らされる音には、どんな関係があるでしょうか? 私は以前これについて調査したはずですが、その結果を思い出すことができません。
    • FREE-ZONE をサポートする実装は、beatmania と同じレンダリング が期待されます。
    • BM98, BMSC, BMSV, nBMplay, Aqua (?), fgt (最初の版) だけが、この仕様をサポートしています。

      • あまりにも複雑な仕様は、プログラマに非常に大変な仕事を要求します。
      • スコアの概念と FREE-ZONE は、共存が困難です。
      • FREE-ZONE は beatmania 3rdMIX にて削除されました:
    • 私はモダンな FREE-ZONE に興味があります。 それはどんな仕様を定める必要があるでしょうか?

      • それはロングノートに似た専用チャンネルを持ち、始点と終点によって区間をセットするでしょう。
      • FREE-ZONE は、ターンテーブルだけでなくキーのラインにも適用可能でなければなりません。
      • FREE-ZONE は、点数やノート数の計算からは完全に分離されなければなりません。

      しかしながら、よりよいフォーマットが現われるでしょう。 なぜならすべてのオブジェクトは点だけでなく区間を持つことができるべきだからです。

  • 近年、チャンネル #xxx17 が FREE-ZONE として使われることはほとんどありません。

    • nanasi と Angolmois は、このチャンネルをフットペダルオブジェクトとして使います。
    • nanasi, pomu2, および Angolmois は、このチャンネルを 18KEYS (PMS-DP) のボタンのひとつとして使います。
    • LR2, PMSee-V, pomu2, および Angolmois は、このチャンネルを 9KEYS (BME 型 PMS) のボタンのひとつとして使います。
#xxx21-27 2P-side Visible object

右側のプレイヤーが演奏するべきオブジェ。

21-25 は鍵盤、26 はターンテーブル、27 は FREE-ZONE に相当します。

#xxx31-36 1P-side Invisible object

不可視オブジェは表示されず、判定されず、スコアに計上されません。

これはキーに割り当てられた音を別の音に変更するために存在します。

  • プレイヤーによるアドリブ演奏のために。
  • イースターエッグのために。
  • 2 つの不可視オブジェで 1 つの可視オブジェを挟めば、プレイヤーのタイミングのずれを野次ることができます。
  • 空っぽの不可視オブジェクトを置くことによって、演奏を無音化できます。 例えば静かな場面で有用です。
  • Angolmois では、不可視オブジェクトと地雷を同じ位置に重ねることによって、通常は変更できない爆発音をある程度変更することができます。
#xxx41-46 2P-side Invisible object
  • その特性上、FREE-ZONE は不可視オブジェクトを持ち得ません。
  • したがって、チャンネル #xxx37 および #xxx47 はサポートされません。(BM98 ではコンパイルエラーが出ます)
  • しかし、#xxx17 を FREE-ZONE でなくキーとしてサポートする実装は、#xxx37 をサポートします。
  • 18KEYS をサポートする nanasi と pomu2 は、#xxx47 も不可視オブジェとしてサポートしています。
  • Angolmois は “--key-spec” オプションによって、#xxx[1-6][0-Z] のすべてを演奏可能レーンとしてカスタマイズすることができます。 したがって、Angolmois は #xxx[30-4Z] のすべてを不可視オブジェとしてサポートします。
  • いくつかの実装は、不可視オブジェに関するバグを持っています。

    • pomu2: DOUBLE 系 LIGHT オプション適用時、スコアは理論値を超過することができます。
    • 同: オートプレイ中、不可視オブジェは鳴らされるでしょう。
    • RDM および古い版の ruvit: 不可視オブジェが無視されます。
    • 同: 不可視オブジェが存在する位置でプレイヤーがアドリブ演奏すると、あたかも可視オブジェを処理できなかったかのように、それが判定されるでしょう。 すなわち、グルーヴゲージは減少するでしょう。

BME:

beatmaniaIIDX は、7 個の鍵盤 (x2) と 1 つのターンテーブル (x2) を持っていました。 ()

歴史的経緯:

: beatmaniaIIDX が稼働しました。

7KEYS をサポートするため、BMS の拡張フォーマット Project2DX が、Urami によって提案されました。

  • このフォーマットは、チャンネル #xxx21 を「7KEYS mode における 1P 側 KEY6」として使用します。
  • このフォーマットは、チャンネル #xxx22 を「7KEYS mode における 1P 側 KEY7」として使用します。
  • #ExtChr を用いることによって、譜面は、BM98 の視覚的なアイテムを直接的に変更します。 つまり、 5K-DP7K-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 )

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」より有用です。

originBMSC
supportBM98, BM98k, BMSV 以外のすべて
header

BMS のコマンドに加えて、ほとんどの実装は以下の拡張コマンドをサポートしています。

(これらがサポートされていることは、BME のレギュレーションとは無関係です)

name & valuesummaryBMSCorigin
#STAGEFILE imageFilename640x480 のスプラッシュスクリーンYesBM98k 拡張
#BPMxx n255 以上、または小数NobemaniaDX 拡張
#BGAxx BMPnum x1 y1 x2 y2 dx dy 部分的なトリム & 表示 No BM98de 拡張

多くの実装が #MIDIFILE#ExtChr をサポートしなかったため、それらは事実上、非標準のコマンドになりました。

channel

BMS のチャンネルに加えて、ほとんどの実装は KEY6 と KEY7 をサポートしています。

number変更すべき対象BMSCorigin
#xxx07BGA-LAYERYesBM98k 拡張: #xxx04 の上に重なるイメージオブジェ
#xxx08拡張 BPMNobemaniaDX 拡張: #BPMxx によって定義された実数 BPM オブジェ
#xxx18-191P-side Visible KEY6 / KEY7YesFlashTerminal 拡張
#xxx28-292P-side Visible KEY6 / KEY7YesFlashTerminal 拡張
#xxx38-391P-side Invisible KEY6 / KEY7YesFlashTerminal 拡張
#xxx48-492P-side Invisible KEY6 / KEY7YesFlashTerminal 拡張

多くの実装が #xxx[1-4]7 をサポートしなかったため、それらは事実上、非標準のコマンドになりました。

BML:

EZ2DJ は、5 個の鍵盤 (x2), 1 つのターンテーブル (x2), 2 個のエフェクタボタン (x2), 1 個のフットペダル (x2), およびロングノートという特徴を持っていました。 ()

ロングノートについて:

日本の BMS シーンにおいて、一般的にロングノートは LN と省略されます。 この文書もその習慣に倣います。

LN は、指定された一定時間が経過する間、入力状態を維持する必要のあるノートです。例えば、キーを押した状態を維持します。

各 LN には始点と終点がセットされます。 多くのゲームで、各 LN は可変長ノートとして、ちょうど長い棒のように表示されます。

プレイヤーに要求される動作は、譜面が倣うゲームの文脈に依存します。

LN は入力状態を保持する操作ですが、別のゲームは高速に入力を繰り返す操作を要求するかもしれません。

本家のゲームでは、LN に対して別の名前や特徴が与えられるかもしれません。 いくつかの典型的な種類は以下のとおりです:

formal namethe first appearanceremarks
ロングノート : Ez2DJ THE 1st TRACKS

始点で keydown して、それを保持してください。

終点での Keyup は不要です。 かつて必要でしたが、不要になりました。

ロングノート : KEYBOARDMANIA 始点で keydown して、それを保持してください。終点での Keyup が必要です。
キープ君 : pop'n music MICKEY TUNES

可変長ノートではなく固定長ノートが表示されます。

押されたノートは、プログレスバーのように表示されます。これは時間ゲージです。

(Name unknown) : 太鼓の達人

長さを持つオブジェクトはすべて、連打されるべきオブジェクトです。

これは一挙動を 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 が稼働しました。 ()

: pop'n music が稼働しました。 ()

: Dance Dance Revolution Internet Ranking Version が稼働しました。 ()

: GUITARFREAKS が稼働しました。 ()

: beatmaniaIIDX が稼働しました。 ()

: Ez2DJ THE 1st TRACKS -R U Ready to Insida DJ Box?- が稼働しました。 ()

: drummania が稼働しました。 ()

: pop'n stage が稼働しました。 ()

: KEYBOARDMANIA が稼働しました。 ()

: Dance Maniax が稼働しました。 ()

: ParaParaParadise が稼働しました。 ()

: 太鼓の達人 が稼働しました。 ()

多くの BMS 由来フォーマットが、この時期に現われては消えました。おそらくは、LN に倣うアイディアもいくつかには含まれていたでしょう。

上記の全ゲームの譜面を包括的に表現するために、BMS の拡張フォーマット MGQ が、 2001 年に quest によって提案されました。

  • このフォーマットは、チャンネル番号を 16 進数に拡張しました。 なぜなら KEYBOARDMANIA が 24KEYS (x2) を持っていたからです。
  • このフォーマットは、新しく LN のためにチャンネルを確保しました。なぜならいくつかのゲームが LN を特色としたからです。
  • このフォーマットは、LN の記法を定義しました。しかしながら、MGQ 形式の LN 記法は直観的でなく、書くのが困難でした。

: MGQ の問題点を解決するために、NvyURDM 形式の 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 のサポートを継続しています。

    1. MGQ が LN のパイオニアであるため。
    2. RDM (1.2 以前) が一時的に MGQ-LN を使用していたため。

    ほとんどの実装は、もはや MGQ-LN をサポートしていません。 できれば MGQ-LN はもう使わないでください。

#LNOBJ xx をサポートしない実装のうちいくつかは、拡張子が BML である譜面を認識します。

  • これは厳密にいえば BML の仕様に違反していますが、チャンネル#xxx51-69 を知らない実装に対しては有用です。
  • #LNOBJ is BML --- それは厳密な意味で正しい。 しかしながらその正しさは、最近もはやそれほど有用ではありません。
  • LN is BML --- それは誤解です。 しかし、それはシンプルで、分かりやすく、実際的です。
厳格な BML:
originRDM
supportRDM, nazo, nazoZZ, bme2wav, LR2, nanasi, ruvit, fgt++, fgt#, pomu2, uBMplay, PMSee-V, bmx2wav, iBMSC (3.0 or later), Angolmois
channelBME と同じ
header
name & valuesummaryoriginremarks
#LNOBJ xx #WAVxx を LN 終点として使う RDM 拡張 私たちは大文字で番号を指定するべきです。(互換性のため)
ルーズな BML:
originWAview
support

RDM, nazo, nazoZZ, bme2wav, LR2, nanasi, ruvit, fgt++, fgt#, pomu2, uBMplay, PMSee-V, bmx2wav, iBMSC, Angolmois

DDR (only DDR mode), WAview, in_bm2, BMSE, IIDXv, HDX, O2play, Aqua (?)

  • DDR は Arrow モードにおいて、#LNOBJ xx ではなく、RDM 記法 #xxx51-69 をサポートしています。
  • DDR は 拡張子 BML の要求仕様を満たしていないので、拡張子 BML をサポートしていません。 (= DDR は仕様に厳密に準拠している)
channel

BME のチャンネルに加えて...

numberobject to changeoriginremarks
#xxx51-59 1P-side LN Object MGQ 拡張 #xxx57#xxx67 のサポートは、実装依存です。
#xxx61-69 2P-side LN Object MGQ 拡張
#LNTYPE 1:: RDM 記法:

00 でない番号が見つかれば、LN 始点になります。

00 でない番号が次に見つかれば、LN 終点になります。

#LNTYPE 2:: MGQ 記法:

00 でない番号が見つかれば、LN 始点になります。

00 でない番号が続く間、LN が持続します。

00 が見つかれば、その直前が LN 終点になります。

headerBME と同じ

PMS:

pop'n music は、9 個のカラフルなボタンおよび踊るキャラクターを持っていました。 ()

歴史的経緯:

: pop'n music が稼働しました。

: KEYBOARDMANIA に倣ったトレーナーとして、doremimaniaKoutaro Izumi によってリリースされました。

  • このソフトウェアは、独自拡張として接尾辞 PMS を提案し実装しました。
  • 私の推測では、この PMS は Piano-Music-Script の略です。この記法は BMS とはまったく異なります。それらは別個のフォーマットです。
  • したがって、「doremimania がサポートする PMS」と、「BMS のサブセットである PMS」との間に、互換性はありません。
  • 本稿では doremimania-PMS について触れません。 (doremimania の代理配布: )

: 9 ボタン (9KEYS) をサポートするため、Nekomifeeling 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 に変更しなければなりません。

: LR2 beta3 090916 は、「譜面の拡張子が PMS である場合、解釈されるべきチャンネル」を拡張しました。

  • 要するに LR2 は、BMS-DP だけでなく BME-SP も適切な PMS として解釈します。
  • pomu2 は当初からこのキーマップをサポートしています。 nanasi はこのキーマップをフットペダルモードとして解釈します。
  • このバージョン以降、LR2 はエディタから呼べるようになりました。 しかし、編集中の 9KEYS 楽譜をプレビューしたとき、LR2 は 9KEYS 表示を適用しません。

    : この問題を解決する方法が、Misty.ls04 によって提案されました。 ()

    : この問題を解決するために “lr2_pmsview_helper” が Misty.ls04 によって公開されました。私の記事を参照してください。

originpomu
support
9KEYS (BMS-DP):pomu2, WAview, in_bm2, LR2, nanasi, fgt++, fgt#, GDAC2, BMSE, uBMplay, PMSee-V, bmx2wav, iBMSC (3.0+), Angolmois (2.0a2 or later)
9KEYS (BME-SP):pomu2, LR2, GDAC2 (774gsc), PMSee-V, bmx2wav, Angolmois (2.0a2 or later)
18KEYS (BME-DP):pomu2, nanasi, GDAC2 (774gsc), bmx2wav, Angolmois (2.0a2 or later, by --key-spec)
header 互換性のために、PMS は #PLAYER 3 を指定することが推奨されます。
channel
1 2 3 4 5 6 7 8 9 remarks
9KEYS (BMS-DP): 1112131415 22232425標準的な PMS
9KEYS (BME-SP): 1112131415 18191617あまり知られていない
18KEYS (BME-DP): 1112131415 181916171P-side (left)
2122232425 282926272P-side (right)
  • 不可視 #xxx31-49 と LN #xxx51-69 と 地雷 #xxxD1-E9 は、可視オブジェクトのチャンネルマッピングに準じます。
  • 18KEYS は、FREE ZONE のためのチャンネルだった #xxxX7 を使用します。

    • BMSE: BMSE は #xxxX7 を捨てるので、編集は困難です。
    • GDAC2 + 774gsc: 今のところベストな選択です。 しかし GDAC2 のレスポンスは、あまり快適ではありません。

    • BMSC: 編集は最も早く始められます。 なぜなら BMSC は、FREE ZONE を標準でサポートする唯一のエディタだからです。

      18KEYS_by_BMSC


<CONTROL FLOW>

origin: BM98 ()
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), 等々よりも早期に)
    • この特徴は、beatmaniaDJ BATTLE をエミュレートするために提案されました。
    • 私が知る範囲で最古の無作為化 BMS は、FANKS "Anthology" COLLECTION (cranky, )
    • 今なお、無作為化 BMS はリリースされ続けています。 e.g. DJ BATTLE 2011 (2106, )
    • 詳しくは別項の作品リストを参照してください: [#RANDOM BMS list]
  • 重要な点は、譜面の内容すべてを無作為化できる ということです。

    • プレイ・オプションの 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
    #00112:00220000
    #00114:00000044

    #00111:11000000, #00113:00003300, #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 が適用されます。
    • #RANDOM をサポートしていない実装は、4 つのノートを表示するでしょう。
  • 悪い例 推奨されない例: 共通部分の孤児化

    BMS code:生成値 1 なら:生成値 2 なら:
    #RANDOM 2
    #00111:11000000
    #00114:00000044
    
    #IF 1
    #00112:00220000
    #ENDIF
    
    #IF 2
    #00113:00003300
    #ENDIF

    #00112:00220000

    #00112:00220000

    #00113:00003300

    #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

    #00111:11000000, #00112:00220000, #00115:00550000, #00114:00000044

    (pattern A)

    #00111:11000000
    #00112:00220000
    #00115:00550000
    #00114:00000044

    #00111:11000000, #00112:00220000, #00116:00006600, #00114:00000044

    (pattern B)

    #00111:11000000
    #00112:00220000
    #00116:00006600
    #00114:00000044

    #00111:11000000, #00113:00003300, #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 (部分的なサポート):
    BMSC (サポートしていない):
    iBMSC 3.0 (部分的なサポート):

    「拡張コード」タブへの隔離は正確に行なわれます。 このタブは少なくとも 700,000 文字以上を確実に格納できます。

    しかし現在の隔離は不完全であり、「編集パネル」にもフロー制御表現を表示してしまうでしょう。

    • この BMS は、#026-033 で、40 個の #RANDOM 文を使用して、音符のリズムを無作為化します。
    • 概念図:
    • BMSEは、#RANDOM のセクションを解析することができ、「拡張命令」 タブにそれを分離することができます。

      しかしながら、この BMS のあまりにも多くの #RANDOM ブロックは、BMSE の 「拡張命令」 タブのキャパシティを超過するでしょう。

      この BMS によって、私は、「拡張命令」 タブが最大 65535 文字までであることを発見しました。

  • 他のあらゆるコマンドよりも先に、コントロール・フローを解析する必要があります。
  • コントロール・フローは、ヘッダも含むあらゆるコマンド行を、変更する能力を持っています。

    • e.g. オートメーション工場 (automation factory) (John "De Bello" Cage, ) ()
    • この 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 が入っています!!
  • コントロール・フローの問題は、構文エラーをいともたやすく書けてしまうということです。
  • 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, MW (固まる), pomu2, IIDXv, HDX
最後の #IF が一致する場合に限り解釈される:nanasi
  • 誤字に対処するために。
  • e.g. Velocity Magic 3 [Aren't you lucky?] (Speed Magician / Transfero, ) () (現在 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 exampleremarks
    // #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 coderemarks
    #SWITCH 5
      #CASE 1
        #00111:XX
      #CASE 2
        #00112:YY
        #SKIP
      #CASE 3
        #00113:ZZ
      #DEF
        #00114:AA
        #00115:BB
    #ENDSW
    1. 生成値が 1 なら、以下が適用されます: #00111:XX + #00112:YY
    2. 生成値が 2 なら、以下が適用されます: #00112:YY
    3. 生成値が 3 なら、以下が適用されます: #00113:ZZ + #00114:AA + #00115:BB
    4. 生成値が 4 なら、以下が適用されます: #00114:AA + #00115:BB
    5. 生成値が 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 で開いた場合」と同じ結果がもたらされます。 ()
  • コントロール・フロー自体を編集することができる 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:
Apps タブ文字 (U+0009) 半角空白 (U+0020) 全角空白 (U+3000)
fgt, fgt++, fgt#YesYesYes
IIDXv, HDXYesYesYes
iBMSCYesYesYes
outlinerYesYesYes
PMSee-V (v1.10.5+)YesYesYes
BGAEncoder (HEADERs only)YesYesYes
BGAEncAdv, TechnicalGrooveYesYesYes
Sonorous (UTF-8)YesYesYes
uBMplayNoYesYes
bemaniaDXNoYesYes
LR2YesYesNo
BMS List Sorter, BME2WAV, BMX2WAVYesYesNo
Angolmois, Sonorous (non-UTF8)YesYesNo
  • タブ文字あるいは半角空白によるインデント。(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 parsingafter parsingremarks
    #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) は、エスケープされることなくそのまま出力されるように変更されました。

テストケース

  1. BMIIDXView2010.txt から:

    BMS coderemarks
    #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+)
  2. オートメーション工場 ()

    • 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 もパスします。 ()

  3. 20,november "club edit" [random ver.] (cranky, )

    • #RONDAM は誤字です。
    • テストをパスする: uBMplay, BMSE, outliner, Sonorous, BGAEncAdv, TechnicalGroove
  4. Velocity Magic 3 [Aren't you lucky?] (Speed Magician / Transfero, ) () (現在 DL 不可)

    • lovetricks.ogg » lovetricks.bms
    • #END IF は誤字です。
    • テストをパスする: nazoZZ, RDM, ruvit, fgt++, fgt#, LR2, uBMplay, PMSee-V, outliner, Angolmois, Sonorous, BGAEncAdv, TechnicalGroove
  5. kitchen twies (Orange Strophe, ) ()

    beforeafterremarks
    #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>

チャンネル割り当て表

numsummaryremarksorigin
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 割り当て表

formatVisible Object Channel Mapping
BMS
KEY1 KEY2 KEY3 KEY4 KEY5 SCRATCH (FREE ZONE)
11 12 13 14 15 16 17
KEY1 KEY2 KEY3 KEY4 KEY5 SCRATCH (FREE ZONE)
21 22 23 24 25 26 27
BMS (nanasi-FP)
KEY1 KEY2 KEY3 KEY4 KEY5 SCRATCH
11 12 13 14 15 16
FOOT PEDAL: #xxx17
KEY1 KEY2 KEY3 KEY4 KEY5 SCRATCH
21 22 23 24 25 26
FOOT PEDAL: #xxx27
BMS (Angolmois-FP)
SCRATCH KEY1 KEY2 KEY3 KEY4 KEY5
16 11 12 13 14 15
FOOT PEDAL: #xxx17
KEY1 KEY2 KEY3 KEY4 KEY5 SCRATCH
21 22 23 24 25 26
FOOT PEDAL: #xxx27
縦連打測定器 (WayBack)
SCRATCH KEY1 KEY2
? ? ?
DDR Arrow 6
11 12 13 14 15 16
DDR Arrow 4/8
11 13 15 16
21 23 25 26
Project2DX
SCRATCH KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7
16 11 12 13 14 15 21 22
BME
SCRATCH KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7
16 11 12 13 14 15 18 19
KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7 SCRATCH
21 22 23 24 25 28 29 26
BME (nanasi-FP)
SCRATCH KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7
16 11 12 13 14 15 18 19
FOOT PEDAL: #xxx17
BME (Angolmois-FP)
SCRATCH KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7
16 11 12 13 14 15 18 19
FOOT PEDAL: #xxx17
KEY1 KEY2 KEY3 KEY4 KEY5 KEY8 KEY9 SCRATCH
21 22 23 24 25 28 29 26
FOOT PEDAL: #xxx27
DSC / FPP
SCRATCH KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7 SCRATCH
16 11 12 13 14 15 18 19 26
OCT/FP
SCRATCH KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7 KEY8 KEY9 KEY10 KEY11 KEY12 KEY13 SCRATCH
16 11 12 13 14 15 18 19 22 23 24 25 28 29 26
FOOT PEDAL: #xxx21
PMS
KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7 KEY8 KEY9
11 12 13 14 15 22 23 24 25
PMS (BME-type)
KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7 KEY8 KEY9
11 12 13 14 15 18 19 16 17
KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7 KEY8 KEY9
21 22 23 24 25 28 29 26 27
PMS (5button)
KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7 KEY8 KEY9
13 14 15 22 23
PMS (pomu-battle)
KEY1 KEY2 KEY3
11 12 13
O2mania (?)
KEY1 KEY2 KEY3 KEY4 KEY5 KEY6 KEY7 (KEY8)
16 11 12 13 14 15 18 19
MyO2 (?)
KEY1 KEY2 KEY3 KEY4 (KEY5) (KEY6) (KEY7) (KEY8)
16 11 12 13 14 15 18 19
未調査:

GDA 9btn (feeling Pomu second),

16panel (D3beat),