currently, the ranking criteria states:


i propose changing this from a rule to a guideline:



the problem

there are two main issues with the current rule:

1. when timing songs with a variable bpm (such as tracks without a clicktrack), mappers can only choose one "active rhythm" as the basis for their timing points. in this set, various mappers chose different instruments as their active rhythm (i.e., drums vs. guitar), but were forced to compromise with a single set of timing points. this is just one example of many maps that have struggled with this limitation—numerous sets have been gatekept from ranking simply because this is currently a rule rather than a guideline, despite their varied contexts and musical needs.

1. for variable bpm maps, this rule creates technical problems with lower difficulties. when a repeat slider crosses multiple redlines, it becomes impossible to snap properly, making it technically unrankable according to other snapping rules. this becomes a bigger issue the more timing points there are in a phrase.

why this should change

what we often consider "objective timing" is a choice about which instrument or element represents the song's "active rhythm." in songs with variable bpms, recorded instrument tracks occasionally vary in their timings—a guitar track might play slightly ahead of or behind the drums, or drift in tempo for a bar or two.

the fundamental purpose of timing in osu is to provide a framework that allows mappers to accurately place objects according to the music as it is actually performed. when we restrict mappers to a single set of timing points for all difficulties despite musical elements having different timings, we're forcing an artificial consistency that doesn't reflect musical reality.

while expanded snap divisors (1/5, 1/7, 1/9, 1/12, 1/16) have been suggested as workarounds, they're fundamentally inadequate for certain musical scenarios where:

1. precision limitations: even with expanded snap divisors, mappers are still limited to specific grid points that may not align with the actual timing of certain instruments, especially in songs with wildly fluctuating tempos or instruments with significant offset variations. as demonstrated in this tool i made, these divisors create an inconsistent grid with highly variable intervals between snap points. at a common mapping bpm like 200, the intervals between adjacent snap points average 7.50ms, peak at 18.75ms, and vary significantly throughout a beat—critically important when considering online offset adjustments address offset errors as small as 5ms.

1. approximation vs precision: using expanded snap divisors only allows approximating the correct timing positions rather than directly placing objects where they should be. the visualisation in my analysis tool clearly shows that despite having multiple divisor options, the resulting combined grid still has substantial gaps where no snap point exists, which forces mappers to compromise on timing accuracy. at slower tempos, the issue becomes even more pronounced.

regarding clayton's point in this discussion that this is

"more an issue with the editor than rc,"

(if this is even still relevant today) maps are currently being gatekept from ranking while waiting indefinitely for adjustments in future updates. changing this rule to a guideline provides an immediate solution without depending on potential editor improvements in lazer.

pishifat previously stated in this thread that

"timing should be consistent because it's a factor of the song, not the way it's mapped."

however, this viewpoint doesn't for songs where different instruments follow distinctly different rhythms, or instruments having varying offsets with multiple valid interpretations of the active rhythm. differences in active rhythm interpretation often occur when representing different musical elements across difficulties, as different mappers may interpret the active rhythm in different ways. even the same mapper may recognize multiple "accurate" active rhythms, each following different instruments or elements with varying offsets or bpms within certain songs.


impact on mapping and playing

converting this rule to a guideline would:

1. allow mappers to accurately represent multiple active rhythms across difficulties under different circumstances due to contexts of variable bpm timing

1. solve technical issues with slider snapping in variable bpm maps in lower difficulties

1. improve playability by letting each difficulty follow its most natural rhythmic interpretation

1. enable more maps that currently cannot be ranked due to this technical limitation

1. make it easier to create gds where mappers want to follow various active rhythms under different contexts

in practice, most maps would still maintain consistent timing across difficulties—this change only affects the specific cases where musical accuracy requires different approaches.

the nuke he calls it

HI THIS IS GOOD AND COOL!!!!

this should've been implemented years ago ffs, really hoping this gains traction

I'm against this

App wrote: 32eg

I'm against this

bro is against increasing the quality of variable bpm mapsets

as someone who does a lot of variable timing, i have to agree this just makes a great deal of sense to change. as a bn, too, i can attest it would fit pretty seamlessly into our current workflow. it should be inherently obvious when different timing between diffs is intentional/necessary - checking this should be a similar process to checking different snaps/hitsounds between diffs. if it's helpful for me to elaborate, i will, but for now i'm just gonna say i'm in full .

also if you're reading this, please please please don't let the website (linked in the initial post) get buried in this discussion! it's a great visual demonstration of the problem

the last time we discussed this internally peppy vetoed it

+2

I'm all for it, it will work on types of map where vocals, percussion, or melodies, which are generally mapped to an active rhythm, aren't coordinated with the same timing.

And I think this kind of idea will only work on difficulties above Insane, otherwise it's useless lol.

+1 what nao said im pretty sure this is a no-go

Im pretty sure i had this problem many times. Like on Come in by weather day or at Latitudes by Good Game (02:17:550)

Open up this discussion!!!!! Stop ignoring this issue, this is an easy fix to change it. Give this real counter-arguments or else just do it

hi spoony

leaning on not agree, tbh feel like it would be an added complexity to checking maps and would only consider if there was a map with a lotttt of variable bpm with simplification only on lower diffs (not to mention how much subjectivity would be an issue) buttt i honestly wouldnt be opposed to this bc it would making mapping variable stuff much easier especially on collab sets or gds, only backset is that mappers would then have to check each gd to make sure that timing is correct which would be an absolute headache

while it seems good in theory i feel like it would be really hard to implement without some form of controversy when put into practice cuz people may argue on timings that are technically correct/allowed, not to mention the amount of people already pretty quick to reject music theory in a music game 😶‍🌫️

imagine rankable object placement by the ms in the editor lol

chidodou wrote: 34592f

hi spoony

leaning on not agree, tbh feel like it would be an added complexity to checking maps and would only consider if there was a map with a lotttt of variable bpm with simplification only on lower diffs (not to mention how much subjectivity would be an issue) buttt i honestly wouldnt be opposed to this bc it would making mapping variable stuff much easier especially on collab sets or gds, only backset is that mappers would then have to check each gd to make sure that timing is correct which would be an absolute headache

while it seems good in theory i feel like it would be really hard to implement without some form of controversy when put into practice cuz people may argue on timings that are technically correct/allowed, not to mention the amount of people already pretty quick to reject music theory in a music game 😶‍🌫️

imagine rankable object placement by the ms in the editor lol

subjectivity in variable bpm timing has always existed, just as it does in many other aspects of mapping. this proposal acknowledges that reality rather than introducing new complexity. its the current enforcement of the rule itself that creates an artificial consistency that doesn't reflect actual musical nuance.

gders changing timing for their individual diffs without informing the mapset host or timer would be an issue of general miscommunication rather than a problem with the guideline itself.

chidodou wrote: 34592f

tbh feel like it would be an added complexity to checking maps

this is just not true and i think we need to put the nail in the coffin on that idea as early as possible in this discussion. as i said:

it should be inherently obvious when different timing between diffs is intentional/necessary - checking this should be a similar process to checking different snaps/hitsounds between diffs

for additional clarification on this, different timing between diffs is something mapset verifier can detect along with the other things listed above, and it'd just be another very simple sanity check 99% of the time.

also, the potential argument that "checking multiple timings per set is more unnecessary work" is arbitrary. if you don't want to check variable timing, you're free to not nominate songs that require them, and many people simply don't.

chidodou wrote: 34592f

not to mention the amount of people already pretty quick to reject music theory in a music game

yes, and that is a methodology that needs to change. change is the whole purpose of these discussions

Good change, hopefully it gets changed and not kept as a way of shifting mappers over to lazer or something

yeah, am also for this! i think people who're against this have never personally felt the pain of manually changing slider-length by altering its diameter in fucking pixels in notepad

not that i'm against the premise because there's been quite a few times where keeping universal timing has been an issue,

but adding more workload to checking timing-heavy maps rather than just compromising on something like in the past, when a lot of people already don't know how to check them properly, kind of strikes me as concerning

we already have to tell ourselves to ignore mv because it still thinks .ogg q6 files are illegal, having not seen an update in almost 4 years (not sure if lazer's " tab" is feature complete, have not tried it)

again i am not against the premise of the proposal, but i think it's too soon to say it will not cause a lot of pain in unintended ways - considering the amount of people responsible for each part of the ecosystem this will affect...

i agree with the premise here but this has been personally vetoed by peppy in an earlier thread here: community/forums/topics/1675476

there's been plenty of for different timing but as it stands this is an issue of convincing peppy more than any of us combined

I'm all for this and, as Kataryn already pointed out, this would not add significant workload.

This isn't something that would happen on every other red line in every difficulty and those specific edge cases where it does happen would be communicated by the mapper/GDer (given that there's any communication at all). I don't see how this alone would make anyone willing to nom variable timing sets less likely to do so.

SupaV wrote: 1g335n

i agree with the premise here but this has been personally vetoed by peppy in an earlier thread here: community/forums/topics/1675476

This is part of the reason this is being reposted. I truly believe in this change, and the edge cases that would be fixed is more important (currently, with denny's tool, you can see the issue as it stands right now quite clearly.)

I also see the for this change being shown throughout the years, and it obviously is a point of contention, but I would rather have proper quantization than whatever the beat snap workaround is.

tilda wrote: 5n595f

not that i'm against the premise because there's been quite a few times where keeping universal timing has been an issue,

but adding more workload to checking timing-heavy maps rather than just compromising on something like in the past, when a lot of people already don't know how to check them properly, kind of strikes me as concerning

we already have to tell ourselves to ignore mv because it still thinks .ogg q6 files are illegal, having not seen an update in almost 4 years (not sure if lazer's " tab" is feature complete, have not tried it)

again i am not against the premise of the proposal, but i think it's too soon to say it will not cause a lot of pain in unintended ways - considering the amount of people responsible for each part of the ecosystem this will affect...

If the usage of this rule change isn't justified, mappers should be obligated to swap. This is meant for the edge cases where it improves playability and changes accuracy for the better.

turffff wrote: 6j204f

yeah, am also for this! i think people who're against this have never personally felt the pain of manually changing slider-length by altering its diameter in fucking pixels in notepad

real as fuck peppy i know you may not understand the pain of this but surely you can see the reasoning behind this proposal and allow for a change that will only benefit future ranking outcomes going forward

agree with boden, its just specific instances which would result in a quality of life update for mappers.

agreeing on this - it just benefits on having more choices and making maps better in quality AND song representation (especially when confronted with stable’s technical limitations like previously mentioned)

no good reason to not add this imo

repeat sliders: if editing the timing so theres room for repeat slider would be still fairly accurate and rankable then... just use that for all of the diffs? what

multiple intstruments: very edge case, in most cases no matter which layer of the song you map you still do timing to the drums as they're essentially songs metronome. even if lets say guitar is offset by 20ms from the drums, you still put the object on the drum instead of shifting the offset for the guitar, because thats just so much more intuitive. polyrhytms and such can be resolved with simply using different snapping (spoiler: it's also way easier than doing seperate timing)
also, if you insist on mapping the instrument with crazy high precision instead of just streamlining to whatever snapping intended, then you're just wrong - one of your point is literally about improving playablity. overly accurate timing does not improve playability, man

so frankly i don't even know why people keep bringing this up, as someone who dealt a lot with variable timing over the years i really don't see where's the issue
if this was implemented itd literally create more mess in my honest opinion

EDIT: never mind, there is one valid case for this that (somehow) didn't even get mentioned in the thread, while being probably the most important - consistency between MODES. as different modes require different amount of precision (as seen with 21st century schizoid man), it would make total sense to not have the timing be consistent between them
but for same mode, no, it's not needed

regarding the repeat sliders case, i've had the reverse scenario actually happen to me: due to changes made to improve accuracy on the higher difficulties, it caused repeat sliders in lower difficulties to become unsnapped and therefore unrankable. if the old timing could be kept or modified on those diffs, then the lower diffs could still retain those repeat sliders without negatively affecting the higher diffs.

SaltyLucario wrote: 2r6s3u

even if lets say guitar is offset by 20ms from the drums, you still put the object on the drum instead of shifting the offset for the guitar, because thats just so much more intuitive.

why would it be intuitive to follow the drums instead of the lead instrument that the player pays more attention to? in my opinion, it would make more sense to follow an instrument accurately than having to compromise with other rhythms/parts in the song. and while yes, this is seemingly an edge case, it affects all genres of music that aren't quantized, which are mapped more and more each year, so the number of cases where this is an issue will increase. this rule will be useful to the few who need it, and not necessary for the majority of sets. i see no downside in enacting this proposal.

20ms missnap should NEVER be allowed, regardless of if the timing is to the drums or not. Is the point of timing not to accurately reflect what is going on in the music?

not to mention mappers' interpretations of the music vary wildly in some cases where the instruments are quantized differently, this change gives mappers more control over what they can map to.

Also +1 to quantum. I truly believe you are missing the point in this, lucario, and accurate timing = better map in MOST cases (overtiming is bad).

SaltyLucario wrote: 2r6s3u

polyrhytms and such can be resolved with simply using different snapping (spoiler: it's also way easier than doing seperate timing)

as shown in spon's tool, and in practice, polyrhythms are usually NOT directly correlated to the snap divisors (in live music). It's a workaround, and one that barely works at that. The rule change fixes a longstanding issue that many people have had, in using improper snapping "because it's easier". Sure, wrongly snapping notes might be easier, but for those that value precision to the things they're mapping, this workaround simply doesn't work.

Unless peppy change his mind, any logic and facts we may have regarding this topic will lead to nothing. He already voiced his opinion against this.

Edit: I hate variable timing and hate osu! precision with offsets and stuff. No rhythm game is this harsh and lower diffs (insane and below) don't require crazy timing to be enjoyable to be played by the casual player that plays OD 8 and below. I'd love to this change, but peppy is against x.x

I'd actually like to know the exact wording of peppy's response to this change, as it would make it easier to make an argument for/against + doing this whole disconnected governance isn't super chill

fuck pepy

SaltyLucario wrote: 2r6s3u

repeat sliders: if editing the timing so theres room for repeat slider would be still fairly accurate and rankable then... just use that for all of the diffs? what

timing different difficulties with variable bpm involves a fundamental balance between timing accuracy and playability that shifts based on the density and complexity of each diff. easier difficulties (with their lower hitobject density and longer sliders) benefit from simplified timing that prioritises playability more than accuracy, where multiple timing points create awkward or unusable slider positions. conversely higher difficulties with greater object density demand more precise timing to maintain musical accuracy at that level of detail. the "just use that timing for all diffs" argument completely misses this nuance. a timing solution appropriate for one mapset diff often creates technically unrankable objects in another. this whole proposition is about acknowledging that the relationship between timing accuracy and playability naturally evolves across difficulty levels, and giving mappers the flexibility without resorting to technically invalid workarounds.

SaltyLucario wrote: 2r6s3u

multiple intstruments: very edge case, in most cases no matter which layer of the song you map you still do timing to the drums as they're essentially songs metronome. even if lets say guitar is offset by 20ms from the drums, you still put the object on the drum instead of shifting the offset for the guitar, because thats just so much more intuitive. polyrhytms and such can be resolved with simply using different snapping (spoiler: it's also way easier than doing seperate timing)

the claim that "you always time to drums" represents outdated conventional wisdom that doesn't match musical reality. genres like prog rock, math rock, and especially jazz intentionally feature instruments playing with different timings. reemphasising what careless said—there is no context where a 20ms missnap should ever be allowed, regardless of whether the timing is to the drums or not, especially considering online offset adjustments address errors as small as 5ms.

forcing all elements to conform to a single instrument's timing completely disregards timing priority and active rhythm representation. most players subconsciously identify the lead or prominent instrumental elements in a song and expect hitobjects to align with those elements, not blindly following drums in every context. this is particularly evident in songs where the drums themselves have variable timing or aren't even the primary rhythmic anchor of the track.

i have no idea why polyrhythms was brought up in this thread.

SaltyLucario wrote: 2r6s3u

also, if you insist on mapping the instrument with crazy high precision instead of just streamlining to whatever snapping intended, then you're just wrong - one of your point is literally about improving playablity. overly accurate timing does not improve playability, man

the point has been missed. this proposition hasnt been made to highlight overtiming.

Does this "peppy veto" have any explanation from him, or it's just a literal "no" and "don't care to elaborate" situation?

Skubi wrote: 4f5xq

Does this "peppy veto" have any explanation from him, or it's just a literal "no" and "don't care to elaborate" situation?

disclaimer: i may be wrong on ing this stuff

i think if anything the direction w/ mapset management was to move stuff like metadata, timing and tags into a single file which is kinda counter to this entire proposal

Wouldn't that just kill mapsets with multiple songs? for example, stream practice maps and things of the like, or timing difficulties that aren't implemented yet?

Also, this for sure still could be in the maps file, it would just need to designate timing differences in some way.

Edit: I really don't see the point in that change, as the timing points are designated inside the .osu file separately already.

Agree with this change - If someone maps a a set of a song that has been ranked previously, using different instrumentals, they likely would change the timing anyways (or be forced to), so I really don't see why it shouldn't be allowed within the same set when instrumentals vary enough.

I think also hybrid sets getting this treatment would also be important (i.e. 21st Century Schizoid Man) with how different standards are for timing between modes.

i ed this guideline years ago, i still do.

agree w op

+1000 for this. You have no idea how annoying it is to map 2* with a gajillion timing points. (Actually you do have an idea. That's why you proposed it in the first place th am I on about)

We just have to convince peppy, pishi & 2% of the mapping base that's against this.

+1

+1