I've recently encountered a bug with the music extension.

When you set the tempo and play a little song, what do you expect? Well, I've been playing around with the music extension recently and found a simple, yet problematic glitch. If a sprite is in motion (Note that it can be any sprite even if it's not using the music extension) the tempo slows down and is inconsistent.

I have known about this glitch for a while now, but it just came up again while making a new project for my birthday. The first time I found this glitch was on the app: V 3.29.1.

I've never seen this glitch in any other extensions but this one.

Here is a link to one of the projects I made using the music extension.Birthday Time! #art It may not seem bad, but follow these simple steps:

1: Enter the editor of the project.
2: Find the music script (it should be to the left)
3: Click on the script and listen.
4: Now click the green flag and listen again.

Did you notice it? The music was a bit slower! If you keep listening for long enough, you may even hear that the music will occasionally bug out with a big or smaller space between notes.

That's it for now. Hopefully this glitch gets fixed. This is my first actual forum post on this account, and I tried to follow along to this forum and I think I included everything. Thanks for reading!

Although strange, this is intentional and is just how Scratch manages scripts.

Scratch only progresses through code 30 times per second while the project is running (which is the same as the stage's refresh rate). That means if your project has things that are updating the screen (like moving sprites) and something makes a script pause until something happens or for a certain amount of time, that script can only resume the next 30th of a second, so, for example, a wait time of 0.08 s would get increased to 0.1 s.

Basically, wait n seconds, wait until, repeat n, etc. can only continue before each screen refresh, which means you can only wait for time in increments of 1/30 seconds.

Additionally, any following blocks that pause execution are only initiated after they are activated. If you have a bunch of blocks that you set to wait for 0.08 s, and they all actually wait 0.1 s because of the aforementioned behavior, each block ends up having to wait an extra 0.02 s before it will run, adding 0.02 s of extra time per wait block onto the script's procedure.

And that's all assuming everything stays perfectly consistent. Often, intensive processes that slow down your project will throw it off even more.

Did I explain that okay?


If you want to keep the rhythm together even if the timing of your code becomes offset due to this behavior, one thing to try is keeping track of time yourself. I also made a Music extension framework called SongBlocks for this purpose if you don't want to do the hard work. Any solution won't solve the problem entirely, but music made with SongBlocks will catch up as needed, in order to keep the music as in-sync as possible.

D-ScratchNinja wrote:

I also made a Music extension framework called SongBlocks

You explained how that all works very well, and I checked out SongBlocks and it seems really cool! I'll be sure to use it whenever I do work with the music extension. Thanks for your help!

define SongBlocks is cool!