BMS-on, a transitional format to convert BMS to bmson

[dtinth]

ℹ️ If you are here from Twitter, I have put the wrong link 😅.
ℹ️ Please read about my fork here: https://github.com/dtinth/iBMSC

---

BMS-on

BMS-on is a backwards-incompatible extension to the BMS file format to allow artists to use BMS tools to author a bmson file.

• Must work with BMS previewers.
• Must be able to easily modify existing BMS authoring tools to support this extension (this PR is an proof of that).
• Must be easy to convert from BMS-on to bmson.

I have been using a BMS-based format similar to BMS-on to create the note charts for “Only love”, “Reminiscentia” and “Everyday evermore.” It works pretty well for me, so I want to document it.

Use case

• Author a bmson using µBMSC (or any BMS authoring tool), and preview using any BMS previewer.
• Use mid2bms of BMHelper to generate a BMS which can be converted into bmson.

Example

In the above example, #WAV04 C-03 is a continuation of #WAV03 01-ARP1.wav. When converted to bmson, the #WAV03 and #WAV04 will be converted into the same sound channel with filename 01-ARP1.wav. The 03 objects will have the continue flag (c) = false, where 04 will have the continue flag = true.

Extension

• #WAVxx C-yy

  Marks the object labeled xx as a continuation of another sound yy.

Compatibility implications

A BMS-on can be played in normal BMS players. However, continuation keysounds will become a non-keysounded note. To make the song fully-keysounded, the BMS-on file must be converted into a real bmson first.

Code

This PR makes µBMSC, when clicking on a note with sound assigned to filename #WAVxx C-yy plays the sound at #WAVyy, starting at where the slice would continue. This allows bmson authors to easily check the sound of their chart.

• STOP isn’t supported (can lead to sound inaccuracies).
• Code is copypasta

[zardoru]

I want to request a few improvements (or adding a branch so we can work on this together, I think it's a nice idea)
Can you make it so continuation objects have a different color in he BGM lane, and that they display the label C: "WAV" if filename display is disabled, and C: "filename" when it is enabled?

In addition to an option to enable the BMS-on features - that way we can avoid possible incompatibilities if someone decides to actually name their WAVs C-whatever.wav.

That's probably an improvement I think would be critical in regards to user interface.

In addition, adding the ability to account for STOPs properly is critical, as it's standard bmson.

[dtinth]

@zardoru You can push commits directly to my branch because I already set up the pull request to allow that ;)

I am not aware about any coding standard in this project. I’ve seen camelCase, PascalCase and xHungrianNotation. That’s why you see all of them in this PR; I try to adapt to surrounding code.

I copied the time calculation code from https://github.com/zardoru/iBMSC/blob/master/iBMSC/MainWindow.vb#L1256-L1266 which also lacks STOP support. So to implement a STOP support, that part should be fixed as well, I guess.

As for possible naming collision, the specification is strict about the #WAV filename. The filename must be exactly 4 characters long, without a file extension. I don’t think it will clash with any file. I have scanned with 10,518 BMS files, and don’t found any BMS file that would conflict with this.

[zardoru]

I'm going to try and add some UI code into this later, and try and fix that time calculation.
Don't worry about the coding standard. I think a major effort would be required to clean that up - but I think we should use CamelCase as that's what people use in .NET languages, if I recall.
Good job on the dilligence of the C-xx thing, that clears up that concern.
I would like a file to test the UI stuff by that point.
That's about it, I think. I'll poke you on twitter if something's up.

[dtinth]

I used > to represent continuation instead of “C:” to make it easier to see visually.

[zardoru]

> is fine. f9f63f6 seems to use C: though?

[dtinth]

@zardoru Yup, I forgot to push it 😅

[zardoru]

I added the 89194d9 branch with a new way to calculate BPM + Stop time, based off what I do with raindrop.
More specifically, 89194d9#diff-920b09be569b1ef8bac9aaa99ec5aebbR2223
I believe this probably is good for this purpose. the branch also adds time display if you wish to check the method's effectiveness.
If it is, I think you can add those changes to this, then we can finally merge this, and the stop time not being accounted would be done.