Creating this thread per request of peppy (thanks for the engine clarifications!)

Problem Details:

Glitches

Timing display flags lower framerate significantly.
If there are a lot of inheriting sections or timing sections, the timing window will experience significant lag.
A possible solution would be to simply allow those flags to be turned off. I personally don't find myself using them so a checkbox would be nice.

Rounding error can cause 1 ms shifts when adding timing sections
This is something that happens when a lot of timing sections are added due to the way sections snap to the nearest ms.
After much timing work, rounding error can cause dramatic shifts, causing timing to become inaccurate.
I'm not sure how this would be fixed, but it is a problem that affects maps that need lots of signature resets or BPM changes.
If I recall, "delta max" was an early victim of rounding error.

A low framerate can cause the first click of a timing section to not play its sound
Often when I have a low fps when timing, a timing section won't play its first click when passed over by the metronome. This bug is why I stress people to increase their framerates before timing, but it wouldn't matter if it's fixed.

Issues

Playback rate is misleading
I see a lot of people timing with playback rate slowed down. If it is really a disaster (a large inaccuracy when used), a disclaimer should probably be displayed warning any timers before they make a mistake.

Video or screenshot showing the problem:
Some of these problems happen in the tutorial video I made recently. http://www.youtube.com/watch?v=Pyat7XWe2kg
The video was built around workarounds, which isn't good for the long term, so that's where this thread comes in.

1.

I couldn't find any performance issues with the flags. Perhaps it is a render issue?
2.
Charles is right. This issue is due to a rounding error. The problem is that BPMs that require strange decimal ms are being inaccurately determined. Take 165 BPM for example. There is a 90 ms distance to the first blue tick, and a 91 ms difference between the next 10 and then there is another 90 ms distance. Each reset is causing an extra ms to be lost between 1/4th distances for every reset that is added within the 10 91 ms shifts. This behavior varies across the BPM spectrum. 166 BPM has 180 ms for an entire 1/2th and then shifts 1 ms for the next 1/2th at 180 ms, and repeats like this.

The screenshot shows my selection bar at the start of a 165 section. The next one is weird.

After 4 resets at the same BPM snapped correctly and the notes are off by 3 ms at 5.5 seconds


3.

This certainly happens. I didn't think it was because of my framerate, but because of timing lines that are very close together in the timeline and the clicking noise can only be triggered so much time after the previous sound. I will try to confirm whether your assumption is true though.

I.

The playback rate is inaccurate when it is slowed down. I have to playback many times to get a proper timing and always like to double check with a friend timer. There is timing lag that affects where the ticks are to the sounds or the other way around. I always assumed it was the sounds that lag and the metronome lags differently than the music.

Starting at different points in the timeline while the music is slowed can produce different sounds, which I believe are dependent on where the sound is relative to where you start the music. Starting the music before a sound starts will produce a different sound output than if you start in the middle of the sound for example. If there is two conflicting sounds in the same place, sometimes you can hear one sound dominating over the other sound, possibly due to an imperfect translation into a slowed form.

Your offset can sometimes lag temporarily. I'm not sure whether it is related to framerate or whether your sound card is just producing output at a different rate than the metronome. It can affect gameplay. It will fix itself if you restart osu! or by taking a short break from interacting with the editor.

1. somehow zooming in is not useful ? (if lazy, it's ok)
2. yes it is, see the difference between 90bpm and 180bpm.
4. the lower the playback rate, the later the timing? if i remember correctly..

i wonder if this also has to do with the weird timing issue on this map:

https://osu.ppy.sh/b/57365

there's an uninherited timing point at around 27 secs which has exactly the same properties as the first one except the offset. it looks harmless when playing with no mod, but if you turn HD on, the circle on that exact point is almost impossible to 300 for some reason.

yeah it's an old map, but it's still interesting to note.

Charles445 wrote:

Rounding error can cause 1 ms shifts when adding timing sections
This is something that happens when a lot of timing sections are added due to the way sections snap to the nearest ms.
After much timing work, rounding error can cause dramatic shifts, causing timing to become inaccurate.
I'm not sure how this would be fixed, but it is a problem that affects maps that need lots of signature resets or BPM changes.
If I recall, "delta max" was an early victim of rounding error.

TheVileOne wrote:

Charles is right. This issue is due to a rounding error. The problem is that BPMs that require strange decimal ms are being inaccurately determined. Take 165 BPM for example. There is a 90 ms distance to the first blue tick, and a 91 ms difference between the next 10 and then there is another 90 ms distance. Each reset is causing an extra ms to be lost between 1/4th distances for every reset that is added within the 10 91 ms shifts. This behavior varies across the BPM spectrum. 166 BPM has 180 ms for an entire 1/2th and then shifts 1 ms for the next 1/2th at 180 ms, and repeats like this.

SPOILER

The screenshot shows my selection bar at the start of a 165 section. The next one is weird.

After 4 resets at the same BPM snapped correctly and the notes are off by 3 ms at 5.5 seconds

This happens if you get offset by tapping from what I know.
If you got for example offset of 1000 by tapping, it will not be 1000, it will be 1000.something, or even 999.something (>999.5 and <1000.5). When you manually input numbers, that problem gets fixed. This is also why normal metronome resets can really screw up timing.
This also screws up when you need to place green lines over the first offset to make the SV different to the base SV, because if the offset is 1000.1 or bigger (from the above example), the green line will come first while having "same" offset, which breaks everything pretty much.
Never experienced the rest of the problems above when manually inputting an offset though, but then again it could be recent since I didn't really touch this game in the past few months.

The first issue can be related to the soundcard I think. You have no idea how much I suffer from that actually, my timing gets screwed by the point of 10+ ms when i have multiple timing sections, depending how my soundcard feels at the time haha (which is why my timings are simply way off sometimes, and why I stopped timing in general).

Koko Ban wrote:

i wonder if this also has to do with the weird timing issue on this map:

https://osu.ppy.sh/b/57365

there's an uninherited timing point at around 27 secs which has exactly the same properties as the first one except the offset. it looks harmless when playing with no mod, but if you turn HD on, the circle on that exact point is almost impossible to 300 for some reason.

yeah it's an old map, but it's still interesting to note.

That's a reset. It's made to tweak the offset and attempt to get the timing back on track. These are usually very bad form as it effectively means the BPM is wrong somewhere.