Yeah, in large projects, one sound can cause a bit of a lag spike. Mostly it’s just latency (and by that, I mean it causes the code to freeze for a fraction of a second).
Multiple sounds played at once can also cause this to happen.
Take Awesome_E’s lag test project for example, it played so many sounds at once, it caused FPS to drop to 3 (even on a 2021 iPad Pro M1). In the web browser, it’s not an issue since it can handle it.
Waterfall is made to have the best fps, but Falling Up isn’t. It has an average fps of 45 with an minimum for 30, which is extremely critical for a musical project
Every music coder struggles with this. My solution is to add a wait block (or any equivalent) to the start to try to stop any lag at the beginning, though this could end up with a “lurch” effect when the music begins to play (for a non-mathematical but questionably practical solution)
I think it also depends on the device, as my old iPad Air 1st gen (I think) couldn’t keep up with Hopscotch anymore (rip ) so newer devices most likely work better.
also don’t play a bunch of random sounds in a project if you want your device to survive the night fyi
In my project STAR-LINK, I play a Low-C and wait for a second at the beginning of the project, which, surprisingly, was the only way to prevent music lag. The wait block alone didn’t help much for me.
Crazy theory, but maybe the real reason the FPS is poor when reading music is because it is unable to keep up with the refresh rate. Sometimes notes can play in less than 1 frame (especially at very high tempos), which Hopscotch is not designed to do (except for certain blocks such as set variable, increase by, and comment).
Well it’d have to be a difference between Safari and the app if you’re talking about 4-5 notes at a time – I think maybe how the sound files are loaded(?). But once you get past a certain point, it just becomes the limits of how fast the device can run the code.