forum

[Proposal | General RC] Remove prohibition on AI timing tools

posted
Total Posts
13
Topic Starter
niat0004
This is a continuation of the discussion in https://osu.ppy.sh/community/forums/topics/2095517.

Proposal


The recently amended Ranking Criteria states that:

A beatmap's hit objects, hitsounds and timing must be created exclusively by direct human input without the use of any generative tooling. Creating beatmaps is a fundamentally creative process, so using shortcuts like generative AI is unacceptable for ranking.

And the reasoning for this is, as peppy and Ephemeral put it, about preserving creativity and not discouraging new mappers:
Forum post quotes

peppy wrote:

From *day one*, osu! has always been about the creative process of mapping—it's the reason I made the game and, to me at least, a core gameplay loop. Allowing use of AI to generate (or assist in generation) of maps undermines the spirit of what makes osu! unique, turning a creative and skill-based activity into something automated and impersonal.

I'd go as far as saying that I see use of AI for mapping as form of cheating, bypassing the discovery process, challenge, and final satisfaction that come from crafting a beatmap by hand.

Ephemeral wrote:

RC wording notwithstanding, the major existential threat AI/generative mapping poses is the "scooping" of entry and mid-level creators. posit that you're a new mapper dude looking to get started: how likely are you to continue learning a new (and rather difficult) craft when content close to your technical capabilities for the next few months/years can be generated in seconds?

the answer for most people is "not very", which in essence turns the acceptance of generative beatmapping into a Faustian bargain that gets us more mediocre beatmaps now for a significantly contracted and disengaged mapper scene later. in internal discussions it has been described as analogous to cheating software in terms of the disruption and damage it causes to osu! as a community, and while some might consider that classification extreme at a surface level, it really isn't that far off the mark if you think about it

While I generally agree with this reasoning, it shouldn't apply to timing, which is entirely objective in the vast majority of cases.

Therefore, I propose that the Ranking Criteria rule be amended to the following:
A beatmap's hit objects and hitsounds must be created exclusively by direct human input without the use of any generative tooling. Creating beatmaps is a fundamentally creative process, so using shortcuts like generative AI is unacceptable for ranking.

Defence against opposing arguments


The arguments against it, in my opinion, do not hold up. The main arguments being:

1. AI timing tools are ineffective

Ephemeral wrote:

we've had "AI timing" in like five different iterations over the 15 years i've been a part of this community and they've all largely been almost complete dogshit. timing is complicated and practically requires human nuance and assessment at every level (complex timing gets into the realm of making spot 'best fit' judgements in tracks w/o quantization, it's a highly underrated skillset) and there simply aren't any shortcuts for it
Which may be an argument for why individual mappers shouldn't use it, but not an argument for why it should be prohibited under all circumstances. If it isn't effective, maps using it simply won't pass Quality Control. In addition, the rule may imply that even AI draft timings which are edited by mappers later could be prevented from ranking.
As another user put it:

Givikap120 wrote:

If the reason for why AI timing shouldn't be used is just simply it being bad - then it means that there shouldn't be explicit ban on it, because it will just not pass normal quality control.
2. Allowing AI timing is a "slippery slope"

peppy wrote:

Arguing that AI should be allowed for the "menial" or "boring" portions will not only lead to a slippery slope and mappers and modders becoming complacent, but I'd argue that it's simply *not required* with the number of competent mappers we have in the community in 2025 – more than ever.
I do not believe AI timing will lead to complacency on the part of mappers, since they should still check the tool's output makes sense, as with any other tool they didn't manually and directly control; some might not, but such timing tools should have notices to check outputs.
If the mapper checks and misses something, that's just the mapper not having a very good ear for timing, which is a problem for any timing method, AI or not.
In any case, for Ranked beatmaps, timing will be checked by BNs and modders.

While AI timing not being required would be a valid supplemental argument were there other strong arguments against it, there aren't, as I see it. Something not being required is not, on its own, a valid argument to prohibit that thing.

Arguments in favor


  1. Since AI timing is objective, it does not harm creativity. You can't be creative on timing in most cases.
  2. When AI timing tools do not suffice, humans will. For Ranked maps, timing issues are caught very often, and if the mapper doesn't notice, modders and BNs will.
  3. For many songs, AI timing lowers the barrier of entry. Many songs are difficult to time (e.g. rock songs from the '80s without a metronome), and having an AI help will make many of these songs easier to rank.
I'd additionally like anyone reading this to consider the following hypothetical:

Mapper 1 times a map with AI tools, which gets the timing exactly right, and uploads it, leaving it in the Graveyard. Mapper 2 uses the same .mp3 as Mapper 1 and therefore has the same correct timing. Mapper 2 then tries to rank their map. Since it is unclear whether Mapper 2 used Mapper 1's timing, which was done by AI, it is unclear whether Mapper 2 (indirectly) used AI timing tools. Therefore, Mapper 2's map may be unrankable even though they had exactly correct timing (and did not use AI to create the actual map).
While this is unlikely, it is implied by how this rule is written.

Note: While I agree with the concerns on the lack of codification of the term "generative tooling", this is not a proposal with any stance on that. That should be a separate thread.
-Mo-
Very much a personal opinion but I think saying "tools that time for us will always suck" is a naive opinion to have.

In terms of "Allowing AI timing is a slippery slope" the slippery slope seems to be around AI tooling in general rather than specficially timing. I can see it eventually leading to discussions about "what about AI for hitsounding" and whatnot, even though the answer to some of these applications should probably be obvious.
Purplegaze
I hate what AI has done to society and would be one of the last people to be pro-AI on something, and I myself even enjoy timing songs by hand, but I completely agree this shouldn't be banned.

The usage of generative AI for mapping and hitsounding is fundamentally different from AI-assisted timing. The former taints an expression of human creativity, while the latter is just technological assistance for something simple and objective. I feel like "AI" when applied to an objective context like timing is nothing more than a buzzword. What's to differentiate an AI timing tool from, say, looking at the waveform on Audacity and doing math to figure out the BPM? (This is how I time any e.g. VGM song where the peaks are very visually clear.) Is it morally different just because a neural network is the type of math being done instead? Timing is nothing more than a measurement/calculation. There is no human element being lost.


Also, considering the argument of quality:

If AI timing tools are improved and become very reliable, then all they'd do is make complex songs more accessible to mappers - a net positive.

If AI timing tools are unreliable, then they wouldn't be recommended to mappers pursuing the ranked section, and anyone using them will be caught in modding, just the same as any other inaccurate timing is now - a net neutral.

Neither leads to a negative result, so I don't see why we should be artificially limiting what technology gets made here.


Lastly, how would you even detect AI timing? It's literally just a measurement. Feels like the current rule would just encourage people who are too lazy to follow the rules to lie about it anyway.
Riverism
yeah the closest timing gets to creativity is stuff where you actually have to pick an instrument to time to based on your rhythm choices, but even then, the creativity is in the rhythm choices themselves. timing is purely a technical consideration that enables you to execute those choices. this is like the one part of mapping where I don't think generative neural networks are able to hurt the community

the slippery slope is real, though, in a very specific way: regardless of any logic presented here, the accelerationists among us will eventually start going "but this was allowed for timing so why not just allow it for <other thing> too"

these arguments should be fairly trivial to dismiss, but they will come up, and I think it's good to be prepared
Topic Starter
niat0004

Riverism wrote:

the slippery slope is real, though, in a very specific way: regardless of any logic presented here, the accelerationists among us will eventually start going "but this was allowed for timing so why not just allow it for <other thing> too"

these arguments should be fairly trivial to dismiss, but they will come up, and I think it's good to be prepared
Agree. I had considered this repeatedly when writing my post, but it's hard to come up with a tough barrier to these accelerationists.
The best counterargument to them (that I can think of) is variations and extensions of "Timing is objective, placing hit objects/mapping/hitsounding/etc. is not".
SupaV
timing manually is still possible with the aid of tools like Tempora that exists now, and I personally time with that tool whenever I need to.

while time consuming, the same can be said about mapping, modding, and other things. and i'll present a take where timing isn't necessarily objective, it depends on what you're trying to follow the more complex the song gets. sure, when the song is simple it's easy to time, but when the song gets complicated the timing can vary from one person to the other.

while making proposals like this, you need to consider heavily the slippery slope argument, as allowing this will naturally lead to other AI forms being allowed, regardless of whatever is going on.

sure, the pros outweighs the cons, but that's the schtick of AI innit? and by now i'd much rather that the staff stick strictly with their stance of having no AI used whatsoever in the beatmaps made. i also need to add that such rule isn't enforceable (yet) so take it at face value.
McEndu
I personally think the AI timing rule is non-enforceable; it would be extremely difficult to differentiate AI timing from human timing, as long as the timing is correct enough.
Purplegaze

SupaV wrote:

i'll present a take where timing isn't necessarily objective, it depends on what you're trying to follow the more complex the song gets. sure, when the song is simple it's easy to time, but when the song gets complicated the timing can vary from one person to the other.
as Riverism said earlier, the creativity here is the rhythm choice itself, not the timing that measures where those instruments land. the sentiment of "timing is objective" isn't meant to imply there's one correct way to time each song, just that there is no element of subjectivity/human creativity in figuring out which milliseconds the instruments you've decided to follow actually land on.

the same can't be said for object placement and hitsounding, so any follow-up arguments on the "slippery slope" are pretty easy to throw out imo. i just think it's nonsensical to say AI timing crosses the line when AI backgrounds, storyboards, and even the diffname related to a song are processes that involve more human creativity than timing but have no rules in place prohibiting them
yaspo
one issue I can see in AI timing is that it'll start feeding into itself
people start using early AI timing -> some poorly timed maps slip through the cracks as they always do -> unaware of this, AI gets further trained on this data -> AI timing now becomes progressively worse instead of better

the same happens when generically training AI on programming and it's not pretty, I've heard

the "slippery slope" idea kinda doubles down on this, the more often people use AI timing -> the less capable hands we have to fix timing -> the more AI will feed itself nonsense and become worse

meanwhile as we humans understand the necessary techniques and become more skilled it'll be a consistent or improving trend, rather than a downwards one

I'm all for using software to address technical problems like timing, I just don't think AI will be able to offer the precision that is required here, let alone improve it
Ephemeral
for full disclosure, can people lay out what generative AI timing tools they're using? things like Tempora (and other lazer-like timing assistants) and most BPM finders are NOT generative and thus not covered by the ruling (aka you're free to use them).

i think it is also important to note that generative AI in every format across every medium does precisely nothing 100% correctly and timing will be absolutely no different. there will never be a tool that attains 100% perfect timing on every track in one click with no modifications needed - music just does not work that way.

using a generative AI tool to estimate the kind of segmentation needed for a complex timing task and then tidying it up (and making it actually correct) by hand is probably fine (even though it is against the wording as expressed) and about as real of a usecase as the technology will ever get, and nobody will really be able to ever tell anyway as long as you actually make real, human edits to it (which you will NEED to). it's the equivalent of using the magic brush tool to vaguely select an area of an image in photoshop - if you use just the wand, you're going to get caught out by people who've actually vectored things before.

"as is" use of generative tooling output in lieu of checking to see if it actually works and fits will get you dragged into the shadow realm, as is intended, both for violating the no generative statute and also for trying to push incorrect stuff
killian

Ephemeral wrote:

can people lay out what generative AI timing tools they're using?
At least one publicly known tool that's based on actual AI is Olibomby's Mapperatorinator, where it can output just timings and not the actual map. Timings might vary in accuracy and often require manual adjustments tho
Topic Starter
niat0004

yaspo wrote:

one issue I can see in AI timing is that it'll start feeding into itself
people start using early AI timing -> some poorly timed maps slip through the cracks as they always do -> unaware of this, AI gets further trained on this data -> AI timing now becomes progressively worse instead of better

the same happens when generically training AI on programming and it's not pretty, I've heard

the "slippery slope" idea kinda doubles down on this, the more often people use AI timing -> the less capable hands we have to fix timing -> the more AI will feed itself nonsense and become worse

meanwhile as we humans understand the necessary techniques and become more skilled it'll be a consistent or improving trend, rather than a downwards one

I'm all for using software to address technical problems like timing, I just don't think AI will be able to offer the precision that is required here, let alone improve it
Again, Ranked maps (this is an RC rule) are thoroughly inspected for timing, and any mistakes made will be caught by modders, BNs, or playtesters. Whether these mistakes are made by AI or a human doesn't matter; saying "an AI timed this map" doesn't make your map subject to less scrutiny; in fact, it might have the opposite effect, since people are aware that AI timing is fallible.
This presumes the AI tool is trained on Ranked maps, but if the tool were trained on unranked maps, that's a fundamental problem with that tool.

Purplegaze wrote:

Also, considering the argument of quality:

If AI timing tools are improved and become very reliable, then all they'd do is make complex songs more accessible to mappers - a net positive.

If AI timing tools are unreliable, then they wouldn't be recommended to mappers pursuing the ranked section, and anyone using them will be caught in modding, just the same as any other inaccurate timing is now - a net neutral.

Neither leads to a negative result, so I don't see why we should be artificially limiting what technology gets made here.
peppy
Hi, I'm here to close out this discussion for now.

- Using generative AI tooling to create raw timing output which is pasted into an .osu file is outright disallowed, no questions asked.
- Using generative AI tooling as part of your workflow and inputting and testing the results in the editor via *standard gameplay flows* is not disallowed, but I'd strongly recommend against it as it will make you dumb and not understand music theory. IN the majority case, timing should be a two minute process and enjoyable at that.

The reason this is disallowed is because generative AI, even for "non-creative" tasks like timing is unreliable in a convincing way. We will see maps with 50 timing points which only require one, but to the average modder they may look at it and be like "hmm, sounds correct, the song must have been recorded non-quantised".

We can revisit this at a later time, but I'm going out on a limb and shutting down conversation here as counterproductive as things stand.

Also, the only tool which does this currently is arguably the tool which created this AI ruling shitstorm in the first place (olibomby's whatever), which we're strongly against people even so much as installing.

"Oh yeah, totally agree that using AI for creative parts is super bad. But let's embrace AI timing in the same tool where you can click another button and have the tool map for you. That won't go wrong ever. It's fine dude."

If you have any thoughts on the matter feel free to email me or discuss on your socials.
Please sign in to reply.

New reply