-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reset playback speed to 100% on entering test play #31445
Conversation
Intends to stop people from mutating it directly, and going through `EditorClock` members like `AudioAdjustments` instead.
I hate to be the guy from xkcd 1172, but this worked very well for practicing hard parts of a map at slower speeds, is there any chance that we could bring this back under a toggle somewhere, or would it be too much work? |
That use case is in scope of the eventual implementation of a real practice mode which is planned for the indeterminate future. |
This was very useful for several reasons:
Can you please restore this functionality until the practice mode is implemented? Or reconsider the decision regarding this change altogether? |
@bdach Gentle ping - not sure if you're subscribed to this issue. Any feedback on my previous comment when you have a moment? |
I saw it and have nothing to add at this time. Maybe this will be offered in the editor via adding the ability to test play with mods active in some manner. I am however not feeling compelled to act on this anytime soon. |
Just uncomment one line in editor.cs->onsuspending()->clock.UnbindAdjustments(); if you still want this "feature". This is the only convenient way to practice difficult songs at slower rate. Kind of a hassle that you now need a dev build to do it. For those that decided to get their own builds like me , since you already have a working dev env why not add this too? This allows you to get much more fine grained speeds than the defaults(>1 works too for dt). osu.game->screens->edit->components->playbackcontrol.cs |
RFC. There's no issue thread for this, it was reported internally.
This ended up being way more annoying to write than I initially had hoped because the playback control could just beeline for the audio track to apply adjustments to it and that just completely breaks any hope of layering it with the screen system. It's one of these weird things wherein the audio subsystem is just completely parallel to everything and you can have stuff that isn't drawn or even updating affect the ambient state of the game.
To that end I ended up rerouting the audio adjustment via
EditorClock
(a5036cd) and doing some extra encapsulation to ensure nobody gets to touch the track directly viaEditorClock
in 98bb723.