forum

[Proposal] Clarify Rules Covered by BPM Scaling by writing time length in milliseconds

posted
Total Posts
9
Topic Starter
Chromate
In the RC, there is a concept called BPM Scaling. it is written aside the main RC as the main RC is written assuming 180BPM, and we need an idea on how the rule applies on higher/lower BPM. However this makes the RC harder to understand as users need to calculate this through themselves, and there is no clarification on which rules are covered by BPM Scaling and which rules are not.

so my proposal is as follows:
We should write the exact time length in milliseconds next to the note length on rules where BPM Scaling applies.

for example-
on rules where BPM Scaling doesn't apply - 1/2 gap, 1/2 sliders, ...
on rules where BPM Scaling does apply - 1/2 (166ms) gap, 1/2 (166ms) sliders, ...

this change will make the BPM Scaling rule easier to understand, and make the RC easier to understand as people can see the note length both in the editor (with the timestamp) and the RC.
honne
Don't you mean guidelines?

There aren't really rules solely based off of bpm.

You may have not noticed but there's a page that goes into detail with some more specifics for those who don't understand how bpm may vary with some guidelines.

I feel like it's fine the way it is already, the rc tries to use 180 bpm as a middle ground for things so that you can apply common sense with the other things.
Annabel
i rlly don't see this happening because the rc is written to be as simple as possible without overcomplicating things and this sounds like it wld overcomplicate it a great deal when not every situation is the same. i also think that it's fine as-is.
Topic Starter
Chromate
I understand this, so my idea is to write the note length in milliseconds (Note: STILL BASED ON 180BPM!) to give them a rough idea on how long the notes may be. mappers can calculate the length by subtracting two timestamps by their last digit

ex) 3:01:976 - 3:01:810 = 166 ms
Ferretface
could also just write that its based on 180bpm and also clarify that its 333ms per beat
QuintecX
How does this make it easier to understand, mappers are way more likely to understand and have a good idea of what "1/2 at 180bpm" is rather than "166ms"

Also no one wants to subtract timestamps, that just takes extra time and does nothing to supplement BPM and rhythm length information
Topic Starter
Chromate
ok what is easier for you, multiplying 1.5 or smth to a lot of numbers (which I do not know exactly which among all numbers) in the rc or just subtracting two timestamps.

look, main focus of this rc proposal is for clarifying what rules/guidelines the BPM Scaling applies to, and to intuitively explain how the BPM Scaling applies. We should get a consensus on both.
August
nothing really unintuitive about current rules there tbh
Noffy
Using milliseconds would be more complex (doing math...) and strict. The current BPM scaling article is not strictly mathematically based - it is based off what is appropriate overall for those BPM speeds. Being exact to a ms would be an issue for most BPMs where it doesn't quite fit the snapping, which would result in using the general area of the ms amount, which.. would be about the same as we have now, but with more steps.

I think it is clearly covered already to allow for gray areas the come from numerous different options in a song's BPM, speed, and rhythm.
Please sign in to reply.

New reply