hi

As part of the Ranking Criteria's reconstruction, the United Beat-Knights of Ranking Criteria have been discussing subsections (such as timing, metadata, skinning, etc.) with the experts of each field. I'm here to announce what kind of rules and guidelines we agreed upon for the Timing subsection in this draft. Notice this is not the final result, as we need the feedback of the community first before getting it officially bumped into the wiki!

Glossary

Make sure to read the entire draft! It will be up to discussion for two weeks and close on the 18th of March!

A map’s first uninherited point cannot be used to toggle kiai. Doing this will cause the kiai to flash before objects appear. An inherited point in the same position as the first uninherited point must be used to toggle kiai instead.

Guessing we will have to mention this when amending the rules about green and red lines having to be consistent.

--


An inherited point cannot be placed before the first uninherited point. Without having any settings to inherit, an inherited timing point does not function properly.

Might be helpful to mention something about anacrusis, and pushing a redline back a measure (or four) if one needs to change the SV/hitsounding/etc... for objects that occur before the first red line.

--

Would you consider songs with occasionally off-beat drums Single-BPM? I'm thinking of bands like supercell, where the drummer is notorious for being drunk, and similar songs, where the BPM is constant, with occasional offset changes.

Adding to that, what if a song is 99.9% accurate to one BPM, but has random off-beat drums? It would qualify as a single-bpm timing, which requires it to be "perfectly timed" however lets say timing those off-beat drums will cause negative gameplay effects. How would you proceed then? Because the rule basically forces you to time your map.

"iintuitive"


Besides, using an object before an uninherited point is fine, right?

How about we are having a negative offset value on the uninherited point? afaik there's several maps on past use that method to find the timing. Shouldn't there's an explanation on that one as well? maybe as a guideline or even a rule?

Edit:

Also,

Uninherited timing points must be used to accurately map the song's time signatures. If an incorrect time signature lasts for more than one bar, a timing point must be added on the next downbeat to reset the time signature.

Agree with Doyak, maybe a timing point should be specified to uninherited point instead to avoid confusion and about the rule above, how about a case on a map with single bpm but with multiple offset reset, if the actual reset time signature of the music is not on the downbeat, should we stick to reset it on the next downbeat? yet the actual reset probably not on the downbeat (like second or third white line). Maybe it's just me, but the wording on that one a bit confusing orz.

1.

Uninherited timing points must be used to accurately map the song's time signatures. If an incorrect time signature lasts for more than one bar, a timing point must be added on the next downbeat to reset the time signature.

Wouldn't this be better if we clarify "an uninherited timing point must be added on the~"? Since a timing point can mean an inherited timing point too, which doesn't work in this case.

2. So now we can use a green line on the same spot with a red line, while the audio setting is different from each other?

3. What do you think of adding a guideline, that even when a part of the song is not mapped, if the bpm/offset changes, you should add an uninherited timing point? Like when the song slows down on the end, many people would not map it at all, without timing that part at all. This still causes the main-menu pulsing desynchronizing with the song.

(edit) 4. Some parts on the proposal says just "uninherited points" and "inherited points" without the word 'timing', is this intentional?

Doyak wrote:

2. So now we can use a green line on the same spot with a red line, while the audio setting is different from each other?

Speaking with some QAT's, the general argument for that is "why do they have to be different?" Since the only time where different audio settings actually does anything is for kiai's that occur at the start of the song, or in anacrusis when notes occur before the first timing line (but even then, a timing line can be placed further back too).

Hey, just passing by since I saw this posted recently

Case 1) Universal offset issue: I know there's a function to let you guys set global offset in the map itself, but at what point do you guys dq these

Case 2) Disagreement with offset/BPM: Some people have offset/BPM disagreements at times, though they do revolve around the actually correct BPM/Offset, how big of an issue must this be for a DQ to happen

Case 3) Note Specific offset issue (Snaps): Some maps require you to do 1/5, 1/24, 1/32, 1/64 and so on for perfect timing of the notes. Technically, they are snapped correctly, but just not supported in the editor, is this a problem? (This is quite important for low BPM maps)

Case 4) Note Specific offset issue (Offset): Some notes can be mapped to instrumentals that are not snapped at all, but when does it become a snapping issue and when can it be overlooked if people argue that some notes are 1/16 and some people argue that it's 1/12 while there is negligible difference. This is a rather apparent problem when people time vocally snapped maps.

Case 4.1) What about persistent instrumentals with no clear starting point, such as a violin fading in, do we have a larger margin of error?

Case 5) You might want to include a guide on how to know if the BPM should be doubled/halved or when this error isn't a problem. Not too sure but I think there are cases where osu!standard allows doubling/halving bpm for specific intentions, not sure(?)

Case 6) Wasn't there problems with specifying some time signatures that the editor doesn't support? think some guidelines on how to workaround would be cool

For some of these cases, think specifying a threshold of error would be good

Edit:

Think if you add green line and red line as alternate names in the glossary it'd be good, uninherited timing points and inherited timing points aren't really said that much I believe, kinda makes it confusing and complicated haha

Monstrata wrote:

Doyak wrote:

2. So now we can use a green line on the same spot with a red line, while the audio setting is different from each other?

Speaking with some QAT's, the general argument for that is "why do they have to be different?" Since the only time where different audio settings actually does anything is for kiai's that occur at the start of the song, or in anacrusis when notes occur before the first timing line (but even then, a timing line can be placed further back too).

I was just wondering, that as this is a ruleset, if now that is not a "must-fix" issue, since that alone has been a DQ issue so far. So, I guess that's not a real problem anymore?

can we have something that handles cases where you need to put a slider going through a timing point?

i remember one map (sorry i forgot which one) which it was heavily discussed that there was an unsnapped slider end due to it passing through a red line, but since the timing differences were rather minimal, and its a really unhelpable case, it was accepted and allowed to be ranked.


actually i really just wish peppy made it so that sliders snapped similarly to spinners where it will just snap to a tick your on lol

pishifat wrote:

There must not be extra uninherited points in any difficulty. These can affect main-menu pulsing, the Nightcore mod, and cause timing to shift due to millisecond rounding errors.

What about adding uninherited points to make NC mod sound not broken?

Kibbleru wrote:

can we have something that handles cases where you need to put a slider going through a timing point?

i remember one map (sorry i forgot which one) which it was heavily discussed that there was an unsnapped slider end due to it passing through a red line, but since the timing differences were rather minimal, and its a really unhelpable case, it was accepted and allowed to be ranked.


actually i really just wish peppy made it so that sliders snapped similarly to spinners where it will just snap to a tick your on lol

That would be awesome, lol, especially if slider ticks would be calculated through the new timing sections, too. But since it's probably not going to happen soon (until osu! lazer I suppose), I'd suggest a rule / guideline about this, too.

wait is the "there must not be extra timing points in any difficulty" prohibiting resetting metronomes which align with downbeats for the sake of having the Metronome count accurate and, on generic songs with weird resets, the shit the NC mod adds line up

Okorin wrote:

wait is the "there must not be extra timing points in any difficulty" prohibiting resetting metronomes which align with downbeats for the sake of having the Metronome count accurate and, on generic songs with weird resets, the shit the NC mod adds line up

Unless I'm understanding you wrong, that falls under this doesn't it?

pishifat wrote:

Uninherited timing points must be used to accurately map the song's time signatures. If an incorrect time signature lasts for more than one bar, a timing point must be added on the next downbeat to reset the time signature.

Logic Agent wrote:

.

technically it doesn't, but the ubkrc will discuss it/try to make it clearer

Kibbleru wrote:

can we have something that handles cases where you need to put a slider going through a timing point?

i remember one map (sorry i forgot which one) which it was heavily discussed that there was an unsnapped slider end due to it passing through a red line, but since the timing differences were rather minimal, and its a really unhelpable case, it was accepted and allowed to be ranked.


actually i really just wish peppy made it so that sliders snapped similarly to spinners where it will just snap to a tick your on lol

I remember these were occasionally handled by editing this value in the .osu file. I think it should be made clear if this is still allowed or not.
Example: 03:24:123 (4) - https://osu.ppy.sh/b/694384

The object in .osu file looked like this:

392,284,204123,2,0,B|344:303|314:295|314:295|253:349|198:323,1,211.5

Changing the last value (211.5) is making the slider longer, so you can calculate the end of the slider or do a trial and error. I personally believe that if there is a slider passing through a timing section, it should be recommended to manipulate this number to get it relatively accurate, if the difference is notable.

alright, closing time

we'll go over your concerns and open back up for another round of discussion soon! thanks!

changelog:

1. included informal names of inherited/uninherited points in glossary
2. clarified usage of time signatures unsupported by the editor in the "Uninherited timing points must be used to accurately map the song's time signatures." rule
3. clarified usage of red lines for nightcore/metronome resets in the "There must not be extra uninherited timing points in any difficulty. rule
4. clarified how to handle volume/sv changes before the song's first downbeat in the "An inherited timing point cannot be placed before the first uninherited timing point." rule

added 3 rules to account for feedback from evening and kibbleru:

1. If objects cannot be snapped using the editor’s supported beat snap divisors, a change in BPM must be used to accommodate for it. Objects cannot be unsnapped.
2. Objects which are wrongly snapped due to passing through a new uninherited timing point must have their ends snapped within the new timing section. For spinners and osu!mania Long Notes, this can be achieved through dragging an object’s tail in the timeline. For sliders, this can be achieved through slider velocity manipulation or editing of the .osu file.
3. Objects which are wrongly snapped due to ending slightly before a new uninherited timing point must have their ends snapped to the new timing point. For spinners and osu!mania Long Notes, this can be achieved through dragging an object’s tail in the timeline. For sliders, this can be achieved through slider velocity manipulation or editing of the .osu file.

and various wording tweaks to make things more readable


specific responses:

Evening: Think if you add green line and red line as alternate names in the glossary it'd be good, uninherited timing points and inherited timing points aren't really said that much I believe, kinda makes it confusing and complicated haha
→ added

Doyak: make “timing point” in second sentence “uninherited timing point”
→ fixed

DakeDekaane: What about adding uninherited points to make NC mod sound not broken?
Okorin: is this prohibiting resetting metronomes which align with downbeats for the sake of having the Metronome count accurate and, on generic songs with weird resets, the shit the NC mod adds line up
→ added clarification sentence

Monstrata: A map’s first uninherited point cannot be used to toggle kiai. Doing this will cause the kiai to flash before objects appear. An inherited point in the same position as the first uninherited point must be used to toggle kiai instead. Guessing we will have to mention this when amending the rules about green and red lines having to be consistent.
→ yes

Monstrata: Might be helpful to mention something about anacrusis, and pushing a redline back a measure (or four) if one needs to change the SV/hitsounding/etc... for objects that occur before the first red line.
→ added clarification sentence

Monstrata: Are supercell-like songs single bpm or variable bpm? What about songs that are consistent except for a few sounds?
→ if songs have variations of any kind, they are variable bpm. if they’re like supercell and would be more playable not having red lines to adjust, they fall under what the guideline says

Sonnyc: Besides, using an object before an uninherited point is fine, right?
→ yes

Mako Sakata: Thoughts on negative offsets?
→ they’re ok

Doyak: So now we can use a green line on the same spot with a red line, while the audio setting is different from each other?
→ yes

Doyak: Guideline about timing points during breaks? Main menu pulsing/nightcore reasoning
→ doesn’t affect much so not really worth it. it’s still a valid thing to do if you want though, as labeled in the guideline’s description

Doyak: Some parts on the proposal says just "uninherited points" and "inherited points" without the word 'timing', is this intentional?
→ added timing to all of them

Evening: Universal offset issue: I know there's a function to let you guys set global offset in the map itself, but at what point do you guys dq these
→ universal offset is best used only for ranked maps. if a qualified map has an offset issue and it’s reported, it’ll probably be dq’d

Evening: Disagreement with offset/BPM: Some people have offset/BPM disagreements at times, though they do revolve around the actually correct BPM/Offset, how big of an issue must this be for a DQ to happen
→ an amount that could affect gameplay. for single-bpm songs, anything noticeable should be adjusted, since it only benefits a map. for variable bpm songs, it depends on how timing variations are handled, and whether or not the community thinks an issue (what the guideline explains)

Evening: Note Specific offset issue (Snaps): Some maps require you to do 1/5, 1/24, 1/32, 1/64 and so on for perfect timing of the notes. Technically, they are snapped correctly, but just not supported in the editor, is this a problem? (This is quite important for low BPM maps)
→ rule added about that

Evening: Note Specific offset issue (Offset): Some notes can be mapped to instrumentals that are not snapped at all, but when does it become a snapping issue and when can it be overlooked if people argue that some notes are 1/16 and some people argue that it's 1/12 while there is negligible difference. This is a rather apparent problem when people time vocally snapped maps.
Evening: What about persistent instrumentals with no clear starting point, such as a violin fading in, do we have a larger margin of error?
→ both are essentially what the guideline explains -- depends on a mapper’s reasoning and whether or not the community agrees with that reasoning

Evening: You might want to include a guide on how to know if the BPM should be doubled/halved or when this error isn't a problem. Not too sure but I think there are cases where osu!standard allows doubling/halving bpm for specific intentions, not sure(?)
→ doesn’t really seem appropriate for the ranking criteria, since tutorials aren’t related to this

Evening: Wasn't there problems with specifying some time signatures that the editor doesn't support? think some guidelines on how to workaround would be cool
→ clarified in first rule

Kibbleru: can we have something that handles cases where you need to put a slider going through a timing point?
→ added 2 rules about situations related to that


this will be open for community revision until march 18th!!

I'd love if there was anything about accurate time signatures and explicit permission to edit these restricted by UI into .osu (say, 10/4). I'll leave the exact wording up to you, or anyone else.
edit: turns out I can't read

probably subject to be added to the list of things of "people may edit these directly in the .osu" which is part of the general part of general rc... i guess

changelog wrote:

clarified usage of time signatures unsupported by the editor in the "Uninherited timing points must be used to accurately map the song's time signatures." rule

draft wrote:

For time signatures unsupported in the editor, metronome resets or editing of the .osu file are acceptable.

i think we already got that

-An inherited point does not need to be snapped to the timeline currently. Is it worth mentioning this in this document?

changelog:
added multi-bpm to the glossary and inserted it into the "single-bpm maps must be perfectly timed" rule (as per kinghenry's suggestion)


the other stuff:
kinghenry's other concerns have to do with how poorly time signature changes are handled in the editor, which the ranking criteria has no control over. when those eventually change, the ranking criteria will change accordingly too!

bor wrote:

-An inherited point does not need to be snapped to the timeline currently. Is it worth mentioning this in this document?

there's no reason to restrict inherited point snapping, so no


considering the only change this round was minor, we can probably go ahead and bubble this

Assuming I have a variable bpm song and a spot that suggests a multi-repeatslider (say 4 repeats).
2 of the repeats are slightly off by say +10ms.
Could it be considered acceptable to use a modified hitsound that has more delay for these 2 repeats so the hitsounds are on time while the repeats are slightly off?

The repeats would be unsnapped then since slider-length is absolute across repeats, so you should use a different rhythm instead xP.

Late answer but: I was assuming a short snapping of 1/4 to 1/12, say on soli parts where it wouldn't be feasible to use a different rhythm due to the difficulty of prediction (meter changes/quintols/septols/...) and also due to a possibly unwarranted amount of tapping that doesn't complement the song in terms of emphasis.
So a spot where the only other thing you can imagine to map being a break.

Probably better if you gave an example. Right now though, using purposefully delayed hitsounding sounds counterintuitive since it doesn't actually give players accurate feedback.

Endaris wrote:

Assuming I have a variable bpm song and a spot that suggests a multi-repeatslider (say 4 repeats).
2 of the repeats are slightly off by say +10ms.
Could it be considered acceptable to use a modified hitsound that has more delay for these 2 repeats so the hitsounds are on time while the repeats are slightly off?

You just leave the hitsounds as they are. If it doesn't sound off ingame, it's fine. If it sounds off ingame, you map a different rhythm.

This draft has been amended to the General section of the Ranking Criteria and can be found here!

As this whole thing involves a lot of changes, the usual 6 month ruling applies:

1. maps that are submitted from this post onward will be handled according to the new criteria.
2. maps that were already submitted may be handled according to the old criteria for the coming 6 months.

Once 6 months have passed, all maps will have to comply with this ruleset regardless of submission status!


I'm actually not 100% sure why you would choose to hold yourself to the old criteria for this section of the Ranking Criteria because it seems to allow less in its previous state, but half a year to transition seems fair - so transition, ho!

thread moved because finalized amendment