BWとSMで第3バージョンではなく同じ世代のマイナーチェンジみたいなよく分からんことやってたけど

まあ実際プラチナ以降第三バージョンは一切出てないから、そこはゲーフリも意識してるだろうな

Q.こまめに貯金をしている天気モンスターってだ～れだ？ (ヒント:お金を「貯める」ということは……？) A.いない(妖精に金は必要無いので)

尻尾は尾骨の延長にあるべきだし腕と別に存在する翼は肩甲骨から伸びるべき

背中から生えてない？

天気、「『後攻は誘発がなければ負け』の世界で誘発をろくに積めない」だけならまだしも、ほとんどの場面で2ターンかけないと盤面が作れないから先攻を取れても実質後攻になるから完全に終わってるんだよね

欲しい：

「ンィー」までは良いと思うけど「ンィーﾞ」って略してる人わざわざ「だくてん」まで入れて変換してんの？

マハフトダイン

【BMS動画作成テストアプリ】 コマ落ちや音抜けを発生させずに譜面動画を作成できるやつ(テスト版)です。 こないだの自称Xでのポストに意外と反応があったので、もう少し使いやすくしたバージョンを公開しておきます。 github.com/Kuroki-Narum...

エアライダーのアレに関しては「ゲームに使われている音楽」ってだけで、そもそも「ゲーム音楽」の範疇じゃないと思うけどな～。どちらかといえば映画の主題歌に近いもので、そういう意味では「音楽性の変容」ではなく「映画みたいなゲーム」の文脈。まあそっちも異論を呼ぶものだけど。 それとは別の話として、作品のテーマを言語的に明示すること自体への忌避感は分からんでもない

ツイッター死んだ？

まあ私はしばかれる側なのですが…

スプラもスマブラも全くやってなかった俺氏、ついにフレンドしばきが可能なゲームを手にする

カタカナあるモンスター達はともかく、罠は全部後半の漢字そのままで呼んでるわ(れっかく、こうえん、しどく)

せいしんそうしゅルキアス せいしんほうしゅファイメナ せいしんりゅうパーン/ウルグラ/ムルル せいしんそうりゅうアルザリオン せいしんほうきゅうグラメル けいとせいしん らこうせいしん せいしんのれっかく せいしんのこうえん せいしんきょうしゅプリクル せいしんのしどく せいしんきょうりゅうシャウラス 指定通りの読みよりそのまま読んだほうが全体的に語感が良い

dominoで1枚目のように設定して.midとして保存、したものを開くと2枚目のようになる。3枚目はもしBM3で同じ事をやるとどうなるかという表。 ちなみに2枚目の.midファイルをBM3(0.7.44)で開くと全く同じ数値になるので、dominoが保存時に書き込む値自体をなんか加工している模様。 当然ながら、.dmsとして保存されたdomino楽譜ファイルは保存後開き直しても1枚目の状態が復元される。

ちなみに「dominoで」512を保存して再度開くと512.002と書いたが、FLで512bpmをmid exportした場合は511.998になる。 512bpm -> 117187.5us -> 117188(四捨五入) -> 511.9978bpm -> 511.998(四捨五入) なのでdominoでの処理がなんかキモい。

dominoで1bpmを保存すると6.206になったりするので保存時にどういう処理が施されているのかだいぶ謎。

とはいえSMFは数十年前から普及しきってしまったしMIDI2.0はどうなりたいのかよくわかんねえまま数年過ぎたし、283.999問題は恐らくこの先も解決しないであろう……

例えばMIDIでは「ノートオン」と「ノートオフ」が個別のイベントとして扱われるけど、楽譜データとしては単一のノートイベントに長さの情報が含まれているほうがはるかに合理的(五線譜ではそうなっている)だし、各イベントの位置を「直前のイベントからの時刻差分(デルタタイム)」で記述するのもあんまり美しくない

なんかこう、YAMAHAとかが主導して全てのDAWがサポートするべき楽譜データ用のファイルフォーマットを作ったりしてくれませんかね……

ていうかMIDIはそもそもリアルタイム通信を前提としたプロトコルで、SMF(.midファイル)はそれをそのまま永続化したものなので、楽譜情報を保存するためのコンテナとしてはそもそも不向きなはずだったんだよな

10ナノ秒っていうのはC#における時間の最小単位と同じなのでとても都合がよい。今からmidi1.0でもテンポ指定だけこの仕様にしてくんないかな。

イマイチ詳細が分からないmidi2.0での仕様を雑に調べたところ、どうやらテンポ(四分音符の長さ)指定は10ナノ秒単位の32bit整数で指定するみたいなので、 155bpm -> 38709677×10ns -> 155.00000167...bpm となって、小数第四位くらいまでは信頼できる精度になるようです。 またこの仕様においてBPMの下限(四分音符=4294967295×10ns)は約1.3970bpmです。まだ1以下にはできない。

よくある質問のほうに書いておこうかな

v0.7.44において整数に再解釈されない整数bpmの一覧 - 254 -> 254.001 - 277 -> 277.001 - 284 -> 283.999 - 289 -> 289.001 (以下省略。+0.001か-0.001のどちらか) - 290, 291, 292, 294, - 301, 302, 304, 306, - 310, 316, 317, - 322, 323, 325 - 334, 335, 336, 337, - 340, 344, 346, 347, 以降も多数

それはそれでなんか不思議な処理がされているな…

指摘されるまで気付いてなかったんですが0.7.43の仕様だとかなりの頻度で.999になってしまうようでしたので報告感謝

.43では155bpmは154.999bpmになります。

特に「テンポが速すぎるとMIDIで正確に表現できない」は覚えておくとよいでしょう。DAWなどでテンポの上限が500などスピードコアには物足りない値となっているのはこのためです。 スピコアBMSを作りたければ切りのいい値(500以下では480がベスト)にするか、音源自体は半分や1/4のテンポで作成して、BMS譜面化する際に2倍とか4倍とかに引き伸ばしましょう(BM3ならワンパンです)

155bpmが154.999bpmと扱われる件、厳密な話をすると「期待した挙動ではない」という意味では「不具合」なのだが、「バグ(意図しない挙動)」ではない。 MIDIにおいてテンポはbpmではなく「1拍あたりの時間」をマイクロ秒単位の整数値で表現する。例えば150bpmならMIDIデータには 400000(=1拍0.4秒) と記述される。 ここで 155bpm は1拍につき 387096.774...us であり、整数とするため四捨五入して 387097。これを改めてbpmに直すと 154.999909...bpm となる。

TLの民がｽﾋﾟｷに侵食されている

unityroom.com/games/20251227 Leap Yearフォロワーって感じのひとくちゲーム

WPFくんがUI要素の加算描画に対応してくれたら描画は10倍軽くなるのですが……

github.com/Kuroki-Narum... ちなみに動画作成テストアプリはこちらから開発状況を確認できます

BGAと下の情報欄を消せばある程度軽くなるし、譜面作成中のプレビュー目的ならわりとアリかも

まともに作られた再生機(mbmplayとか)に比べて圧倒的に重いんだけど、これをBmsMaker3に組み込むと、一時ファイル無しラグほとんど無しでプレビューできるという利点が得られる(mbmは初回起動に十数秒かかる)

やってみたら意外といけたリアルタイム再生(CPU負荷激重)

動画作成を中止してもその時点までにエンコードされた部分はそのまま動画ファイルとして残るの、地味に便利な点かもしれない

演奏時間68年のBMSも映像化できる(※)ようになりました。 ※フル尺で保存するには約22PBの空き容量が必要です。 以前の実装では音声を先に全て合成し、後から映像と合成していたので、非常識な演奏時間のBMSでは音声合成に失敗して動画ごと作成不能だった。 このバージョンでは音声も(映像と同じく)毎フレーム逐次合成に変えたため、非常識な演奏時間のフル尺動画を作れない点は変わらないものの、エンコードを中止(Abort)することで「一部分の切り抜き」なら作成できるようになった。

フーリエ変換しても再生できないだろ！いい加減にしろ！

人間が似合う萌え袖

×9年○10年

この話ももう9年前なんやねぇ

ついにあの「tonkatsu.bms」を映像化することに成功しました

停滞の匚庭、曲が良い

確実にキー押してるのにMISSになる

横断歩道の曲判定ぶっこわれてないか？