doubledepth

のI-shaped balance

Windows Me/2000/XPのExplorerは音声の主要なpropertiesを一覧できた（画像のBMSは“evening”）。Windows Vista以降、私はそれらを知るためにMediaInfo CLIを自前のscriptと組み合わせているが、たとえば“”という名前のBMS folderをこのscriptにdropすることはできない（System LocaleがUTF-8である場合を除く）。一般的な用途なら真空波動研Liteとかが使いやすそう。

Simple BMSON Tips

以下のcode snippetsをWeb browsersのJavaScript Console上で実行すれば、BMSON fileをメモ帳などで直接編集する際に役立つかもしれない。BMSON仕様を理解している人向け。

((r,b,m,n)=>{for(var i=0,o=[];i<n;i++){o.push({y:r*b*i+m})}console.log(JSON.stringify(o))})(240, 3.5, 24000, 32);

((d,f,t)=>{for(var y=f,o=[];y<t;y+=d){o.push({c:true,l:0,x:0,y:y})}console.log(JSON.stringify(o))})(60, 24000, 28000);

_wsh_bms2bmson.js v0.2.7

• [Qwilight v1.10.12対策] "info"配下の主要な情報を省略せず出力するよう変更。
• [Qwilight v1.10.12対策] 設定項目OMIT_FALSYを隠蔽。
• 必要なImageMagickの最小versionを5箇月前の7.0.10-3から最新版7.0.10-34に変更。
• BigNumber.jsのversionを9.0.0から9.0.1に変更。

ゐＷﾉﾚﾉムんｲ（筆記体）

Qwilight v1.10.12の調査の続き。

BMPのほとんどを描画でき、JPEG圧縮BMPやPNG圧縮BMPを食わされても強制終了しない。強い。

[追記] まとめには載せなかったが、WebP形式の画像も#BANNER/#STAGEFILEでのみ描画された。

#RANDOMは入れ子もsupportされるが、indentされた行の内容は無視される。Song list上で“オートメーション工場”の内容が毎回変わって楽しい。入れ子版emulated randomは正常に働かない。

[追記] “sevenscape”の入れ子版emulated random（たぶん未公開）も正常に働かない。

正確にいえば"c": falseと"l": 0は省略できたのだが、私は今後こういった省略をしないことにした。修正版BTS差分のBMSON filesizeは元の1.6倍に肥大した。Falsy key-value pairの取り扱いは仕様に規定されていないので、省略を許さない実装が間違っているわけではないのだが、"back_image": ""や"preview_music": ""を持たない状態でさえ選曲画面に列挙されない場合があるのは不思議だ。

Ɋ 山 丨 ㄥ 丨 Ꮆ 卄 ㄒ

Qwilight v1.10.12を試した。選曲画面で図表を右clickするとText encodingを変更できたり、chartをreal timeで入力できたり（この特徴を私はまだ確認していないが、いわゆるKEY音なしBMSをものすごく作りやすそうな感じだ）、高い独自性を誇るBMS player/editor apps。以下私用備忘。

• Qwilightを起動したら、適当にBMS events単位でfolderを画面内にdropして、画面右上の歯車iconからkeyconfigを行い、歯車iconの真下のlistboxからfolderを絞り込む。
• 画面下部の“Delete directory”は選択中のsong list itemをマジでfolderごと削除するので注意。
• 選曲画面にて、Window上部のPreview用progress barが青くなった後、progress barの任意位置を左double-clickすると、任意小節からAUTOPLAYを開始できる。o2play.exeとか思い出す。

私はQwilightに関するfeaturesをまとめた。私の調査には誤りが含まれるかもしれない。

拙作BTS差分が選曲画面にさえ現れなかったので、慌てて修正して当site上に再度uploadした。しかし現段階ではこの差分をQwilightで演奏することは推奨しない。Layered Notesは高速連打しないと判定されないし、AUTOPLAY中にLayered sound slicesのLongNotesがとんでもない雑音に化ける。

寒くて手と頭が働かない

先月のLNs（LongNotes）に関する考察記事に書ききれなかったtopicsを落穂拾い。

この動画はToy Musical 3のトラッピーハードコアから音声を引用し、patternの一部を引用・改竄したもの。最初の4小節は元の通り。次の4小節は残響音の解釈を変更したもの。後半はkickと“Feel the beat”を加えたもの。

元図表において最初のLNは全音符相当の長さを与えられている。が、このKEY音の「波形自体のrelease point」はおそらく四拍目にある。末尾一拍分は残響成分。残響をLNに含める作例は珍しいが、演奏者が「notesを押すべきtiming」を決定するために視覚に頼らざるをえない曲頭4小節において、元図表の最初のLNは理想的な正解のひとつだろう（視覚への依存度が最も低い形）。

残響音はspeakersとhead-phonesで聴こえ方が異なる場合がある。また同時に鳴っている音声次第ではBGMに埋もれる（KEY音として視覚化するに能わざる）場合もある。視覚化できる閾値が明確なら図表著者としてもplayerとしても都合がよい。BMSにおける音量の標準化が待たれる（？）

レミニッセンスの最後のLNは視覚に頼るしかないように見えて、じつは65 BPMのmetronomeを頭の中で働かせ続ければrhythmとして処理できるのではないだろうか。これを思いついて実践してみたところ、いきなり最良判定で最後2個のnotesを処理できてFULLCOMBOを達成した。それが数箇月前の話。先月の記事を書く際にレミニッセンスの最後数小節を再現しようとしたが、元のrhythmがよくわからず断念した。結局のところ、私のFULLCOMBOは偶然に過ぎなかったようだ。

この動画は件の最後のnotesをrhythmとして処理する方法の概要を示したもの。ただし、この動画のLN終点および最後のnoteのrhythmはおそらく正しくないので、そのまま参考にはしないでね。FULLCOMBOできたとき私は、音階ではなくdrumsを脳内で刻んでいたかもしれない。

ジャングルの最後も似たような仕掛けだが、こちらは視覚に頼るしかないように見える。

トラペゾヘドロン(H)の最後のLN区間内に#STOP sequenceが仕込まれている。私はFULLCOMBOを達成していたにもかかわらず、MOK2氏の動画を観るまで最後の#STOP sequenceに気が付いていなかった：

• いちおうEX図表に触っていれば「最後のLNの長さとKEY音の対応関係」に気付くことはできるようになっているのだが、私は難しい図表を避けていた。
• nanasigroove2がおそらく変動pixel判定であるため、#STOP eventに気付かないままでも最後のLN終点で緑GREAT判定は取れてしまった。「叩いて光るならそれが正しいrhythmである」という原則は時間軸判定でしか通用しないことに気付くべきだった。
• #STOP eventに気付かないまま最後のLNをすぐにKEYUPすると「scrollingが停止中であることを示す視覚的な指標」が画面内に一切存在しなくなる。小節線も描画されないし。

と理由をいくつか挙げてみたが、結局のところ私は「あのKEY音を即座にKEYUPすること」について特に違和感を感じてはいなかったのだろう。というか最初から最後まで私にはわからなかったので、最後だけとりたてて奇妙に思うようなこともなかった。私は目押しが苦手だが、そんな図表もありだろう。

BMS vs. 48000 Hz

Pulsus 0.5.3のsettings.json内の"resampleQuality": "Low"（既定値）を"Highest"に変更すると、48000 Hzの音声がほぼ演奏されない。BTS差分の全曲版（readme.bmson）がこの影響を受ける。

Angolmois 2.0 alpha 2版のWindows用EXE file（1.7 MB）はSDL_mixer 1.2.12を用いる。この頃のSDL_mixerは48000 Hz系列の音声を酷い雑音や不正確なpitchとして演奏する。以下の“#128”の動画において、どちらか片方はBMS resourcesを44100 Hzにresamplingしたもの。

Angolmois 2.0 alpha 3以降はSDL_mixer 2.x系を用いるので、48000 Hz系列の音声もほぼ正確に演奏できる。しかしそれは慰めにはならないだろう。Angolmois 2.0 alpha 3以降の版を自前でcompileするWindows usersは多くないだろう。BMSへのimpressionsにおけるchords workへの言及は、48000 Hzの音声によって的外れにされうる。48000 Hzの音声を用いるBMSは推奨環境を示すのが無難だろう。

Be-Sequence Object Placer (BSOP) Ver.0.50

BMSのchannel変更に特化した単機能tool。Notesの書込・削除・rhythm変更が不可能なので、このappsを使う限り音ずれや音抜けは絶対に発生しない。これを通して作られた差分にはその種の誤りが存在しないことが確実に保証される、とても心強いtool。

μBMSC 3.3.0.22以降で「オブジェを縦移動させない（Disable vertical moves）」optionを有効化したうえでShift + [1–8]を押下すれば、BSOPとほぼ同じことができる。ただし、

• BSOPは32-bit Windows環境では働かない。
• そのかわり、BSOPは少なくとも分解能215441までは正確に読み書きできる。

  #00101:0000000000000000000000000000000017
  #00101:00000000000000000000000000000000000019
  #00101:0000000000000000000000000000000000000000000023
  #00101:0000000000000000000000000000000000000000000000000000000029

  このBMSを読み込み、全notesを列zに移動させて保存すると、「小節を215441等分するrhythm」が正しく出力される（17等分 vs. 19等分 vs. 23等分 vs. 29等分）。ここに「小節を31等分するrhythm」まで加わると、私の環境では正しく書き出すのは無理であるようだった（30分以上待っても処理が終わらなかったのでprocessを終了させた）。

  ちなみにiBMSC/μBMSCの分解能は最大でも10000までなので、前述のnotesを一列に並べて保存すると絶対にrhythmが狂う。分解能が192に固定されているBMSC/GDAC2/BMSEも同様。

  ---

• BSOPはkeyconfigができる。
• BSOPはいまのところLongNotesを扱えない。

という違いがある。

BSOPのprocess名“LÖVE”はどうやらFree 2D Game Engineであるらしい。氏が制作されているrhythm-action gameはいまや珍しくなった読譜（solfège）型であるように見え、個人的に興味深く感じている。

BMX2WAV 2.0.0

大型BMS eventの開催を前に、満を持して正式公開された。v1.ZZ.05からの大きな違いはManual。旧BMX2WAVからの大きな違いは変換性能強化・Script搭載・Searcher搭載。Windows 7以降の64-bit Windows OS上で働く。まずは「出力ファイル指定テンプレート」に適当な値を指定するとよさげ。

1. bmx2wav.exeを実行する。
2. 上部menu barから「編集」を選択する。
3. 「共通設定の編集」を選択する。
4. 開かれた「変換設定編集」windowの上部から「出力」tabを選択する。
5. 「出力ファイル指定テンプレート」。「使用できる変数一覧を表示する」も適宜参照する。

「出力ファイル指定テンプレート」が空欄の場合、変換時に出力先を毎回指定しなければならない。それで不都合がないなら空欄のままで構わない。私はD-drive直下にBMX2WAV出力用のfolderを作成し、そこに変換結果をまとめている。私の「出力ファイル指定テンプレート」の値は以下のような感じ。

D:\bmx2wav_output\@@input_bms_basename_auto_extension_change@@

他にはlogを出力したり、後処理でFLACに変換したり。

今回command-line引数は“bmx2wav.exe "bmsFilePath"”くらいしか反応がない。他に用意されていたとしてもsource codeを読まないと分からないだろうけど、そもそもscriptを組めるv2系ではcommand promptをわざわざ使う必要もなさそう。BMS editor appsとの連携ならv1版で済むし。

プナイプナイえんそう ver.0.05

BMSE/μBMSCと連携でき、MIDIに基づく自動裁断も可能なBMS音切り支援tool。

Ver.0.03から怒涛の連続更新。同梱sampleは「使いまわせる音声」の判定が分かりやすかった。ここまで自動化できるなら重複定義まで任せられるともっと便利かも……重複定義すればよいというものでもないから難しいかな……

[16日追記] 起動直後の状態から設定を変更せず、同梱sampleを「重複なし」で切り出して、そのまま「BMS出力」すると、#00001は00010102になる。演奏されるtiming次第では、0101において同一音声のreloadingが発生しうる。このときnoiseが発生しうる。これを避けるために、#WAV01の定義内容を#WAVZZとかにも定義して0001ZZ02のように不連続に並べたい。不連続に並べるところまでプナイプ先生に任せられると便利かも。そうでもないかも。という文意でした。

BMS vs. America

BMS書式は³⁄₄拍子と⁶⁄₈拍子と¹²⁄₁₆拍子を区別しない。前述の動画では#SCROLL定義を用いて「見かけ上」拍子と判定線明滅間隔を整合させている。#SCROLL非対応環境では直感と異なる見え方になる。

“Ceebu Yapp”の“Sound Only”は一小節につき四回跳ねる。判定線は三回光る。元のBMS filesは「『101 BPMにおける16分音符』を三個連ねて一拍に見立てた¹²⁄₁₆拍子」として書かれている（#025–#032のみ⁶⁄₈拍子）。四つ打ちdance musicの感覚なら約135 BPMとなる。

むおおおぉ〜ん❣

「『演奏者側のRANDOM option』の挙動をemulateする図表」

これを実践した譜面を最近見かけたので、ご紹介したくweb拍手を送らせて頂きました。

http://www.dream-pro.info/~lavalse/LR2IR/search.cgi?mode=ranking&bmsmd5=968d17b52500bc20415d9669f11e69f5

すべての同時押し配置が#RANDOMによって抽選されることで、プレイヤーに事実上S-RANDOMを強制する譜面となっています。

極めてノーツ密度の高い超高難易度譜面では同時押し配置の無作為性が演奏感の問題にはならず、むしろ上達練習の意味で実用的である、という文脈のもとこの譜面が成立していると考えています。

特殊な文脈ではありますが、無作為性を実践的に取り入れたBMS譜面として興味深く感じました。ご参考になれば幸いです。

教えていただきありがとうございます！　これはきっと固定運指さんの準備運動にお誂え向きな図表なのでしょう。全押しを基準状態とした「休符（穴）の無作為化」とも受け取れました。全小節に無音notesを追加するこの差分、特に先頭8小節は全部が無音同時押しですが、これをあえて『音を鳴らすgame』の文脈に載せるなら「BGMの倍音成分まで演奏したい気持ちの表れ」という感じになるでしょうか。さすがにそんなお気持ちでは説得されませんか。ならばいっそのこと“Burn”の序盤のvocalのように、BGMをまるごと4つぐらいの周波数帯別に分離し、それぞれを16分音符間隔で裁断して「4個同時押し」として実際にKEY音にあてがっても面白かったかもしれません。

ちなみに44380–44386行目のように、#RANDOMを伴わない全押しもちょくちょく現れます。このあたり、機械的に出力されたのかhand-codingの産物なのか絶妙にわからないですね……

倍音成分で思い出したけど、“Egypt”の動画1:23–1:48とかは鍵盤列が不定でも楽しそう。この区間のpianoは音階楽器というよりはむしろ打楽器的に感じられ、それは当然「全力でぶっ叩く」というsituation/tensionによるところが大きいが、波形としても複数の音階が複雑に重なり合って打楽器に近い鳴り方になっているからではないか。そうであるがゆえに通常の音階配置の慣習から容易に解き放たれうるのではないか。「常時RANDOM適用状態が説得力を持つ曲」とか言い出した数日前の私の関心はそんなようなあたりにありました（偶然性と音楽性と演奏性が交差する領域みたいな）。

入れ子の分岐を見直す

先日の日記のBMS差分の動作確認中に、演奏しやすそうに見えるpatternが降ってきた。通常の7鍵盤BMS図表の正規の鍵盤列内容を便宜上ABCDEFGと表すなら、件のpatternはGFBCDEAとなるように列内容が並べ替えられていた。このpatternを#SETRANDOMで再現したい。

非（non-）入れ子（nesting）版では“#RANDOM 5040”を“#SETRANDOM 4954”に書き換えれば件のparrernが再現される。『AからGまでの順列』を先頭から列挙した際に『GFBCDEA』の並びが現れるのが4954番目だから、（概要さえ理解していれば）わかりやすく、（各分岐内に適切なcommentさえあれば）探しやすい。

分岐の構造を把握している私自身にとっては、入れ子（nesting）版のほうが読みやすい。BMS codeは機械に読み書きさせるほうが安全かつ高速なので「人間可読性なにするものぞ」って感じではあるけど。

『演奏者側のRANDOM option』の挙動をemulateする例（part 2）

先日の日記の続き。“morning 06”の7 keys HYPER図表を疑似的にRANDOM化した。入れ子（nesting）版はcharatbeatHDX/nanasigroove/mBMplay/uBMplay1.5.xなどで試すことができる。Anzu BMS Diff Toolも入れ子（nesting）やindentをsupportしている。BMX2WAV v2も同様だが、設定から入れ子（nesting）を有効にする必要がある。

「入れ子（nesting）をsupportし、indentをsupportしないsoftwares」は、私の調査が正しければnanasigroove1・BM98・DDR（Delight Delight Reduplication）・MixWaverのみ。これら古いsoftwaresへの対応が不要なら、入れ子（nesting）図表のindentは残しておいたほうが安全だろう。[10月27日追記] Qwilightも入れ子可・indent不可。

そしてindent styleの入れ子（nesting）図表は、少なくとも今回のような構造なら非（non-）入れ子（nesting）版と大差ないfilesizeになる。入れ子（nesting）を外せばbeatorajaやLR2でも遊べるようになるのだから、あえて入れ子（nesting）にするべき理由はどこにもなかった。私は間違っていた。

無作為な小節線の実験

“(^^)”のこのBMS差分は各小節を#RANDOMに8分割する。各小節内では以下の8種類の分割間隔が一度ずつ選ばれる。ありうる組み合わせは8 * 7 * 6 * 5 * 4 * 3 * 2通り（を4小節ぶん）。

(1/2) + (1/4) + (1/8) + (1/16) + (1/32) + (1/64) + (1/96) + (1/192) = 1

「小節長さの合計が1になる間隔」を恣意的に選び、それらに対して「元のnotes配列」を機械的に分配しただけなので、あらゆる組み合わせ結果がAnzu BMS Diff Tool上で元のBMSと一致する。

無作為さはそれ単体では面白くもなんともなく、音や映像との関わりを持たない限り「ふ〜ん」で済まされる代物なのだなあ。なので192分音符間隔の小節線が唐突に出てくるよりは、この曲の最小rhythmたる8分音符間隔の小節線が音声に同期して降ってくるほうが、まだしもplayersを幻惑する効果が期待できそう。この曲なら(1/2) + (1/4) + (1/8) + (1/8)程度の分割が最適だろうか。

あと、この方法だと必ず4拍おきに小節線が降ってくるので無作為感が弱い。本気で取り組むならもっと作為的に無作為さを演出する必要があるだろう。使える小節線の上限は1000本と決まっているので、これを演奏時間内の高密度地帯から優先的に分配していく、とかだろうか。

そしてそもそも分岐を入れ子できない環境でこれをやるのは筋が悪すぎる。たとえば同じような発想で「『演奏者側のRANDOM option』の挙動をemulateする図表」は普通に成り立つが、入れ子なしで7鍵盤のRANDOM optionを模するなら7 * 6 * 5 * 4 * 3 * 2通りの組み合わせ全部を予め記述しておく必要がある。常時RANDOM適用状態が説得力を持つ曲って“sevenscape”くらいしかなくない？

体調不良につき小休止中

Atopic eczemaで滅茶苦茶痒い！

Allergic rhinitisで涙と鼻汁が垂れ流し放題！　目まで痒い！