-
Notifications
You must be signed in to change notification settings - Fork 93
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
After numerous changes of volume/pitch, they became less responsive #130
Comments
We have no expectation that behavior seen using tools other than Scratch will represent the behavior using Scratch. Can you experience this behavior using Scratch? |
Okay, I put the project playing for 2 hours in the vanilla Scratch to see how the behavior is noticable, and here's the result. 2021-01-29_19-46-00.mp4 |
I made a test for a quick reproduction of the behaviour: https://scratch.mit.edu/projects/481050174/ However, when the audio assets removed and the same audio reuploaded again, it became more responsive again. |
Here's an even more minimal version of @Kouzeru's project. It no longer makes much noise, but it still calls "set pitch effect" as fast as it can. You can watch the "set effect calls per second" drop very quickly after startup. Stopping the project and starting it again does not restore initial performance, but reloading the page does. |
Here's GarboMuffin's approach upon tackling this problem by doing optimisation upon sound effect changes |
When is this fixed? Is anyone allowed to contribute? |
Hello, from testing, this actually appears to be an issue with your code. Since loops without a screen update have zero delay at the end of the loop, it will take an indeterminate amount of time, anything you run in the loop will eat into that loop (so it takes longer to loop). It is jot regulated to take some specific amount of time because that would break frequently and often if it was. The biggest problem is the if statement where you check the time. Since this would end up running each time you run the loop (for example 1,000s to 10,000s of times per second. Conditional statements (not maths) cause a higher amount of CPU time than other instructions. To not have this random delay, you should instead use the "repeat until" block, which only checks every reasonable amount of time. But that will be too fast (1/10,000 usually) so you should do something like this instead
|
Cwilisf already got the issue right. The purpose of the quick loop in the project is only to hasten the effect, so you don't need to wait for the performance drops to build up. You see you got the 10000 loops per secs at the initial, then it drops lower. And resetting the project does not restore the performance. This seems to have an insignificant effect for simple projects that don't use the sound blocks intensively. This however causes some problems for the complex project of mine, and the others. |
Expected behavior
Not far after the page loaded, (play sound, set volume, set effect) are quite responsive
2021-01-22_21-49-34.mp4
Actual behavior
After a while, they became less responsive, slowing down the project...
2021-01-22_21-47-46.mp4
more clear demonstration:
Untitledvid.mp4
Though restarting the project after the lag still doesn't make it more responsive until the invoke of [set volume] and [set pitch] removed. The project became responsive again when the page is reloaded.
Steps to reproduce
I used turbowarp to demonstrate them, assuming turbowarp still uses the same branch from the vanilla Scratch for this part, hence they inherit the behavior.
Project A
Start the project, and restart when the music done. After a while, the lag became noticeable.
Project B - (shared)
Set Synthesis Mode to 1 to enable the synthesizer mode which uses the volume/pitch effects to play the song.
Restart when the music done, the lag became noticeable too just after few minutes.
Operating system and browser
e.g. Mac OS 10.11.6 Safari 10.0
The text was updated successfully, but these errors were encountered: