What is the correct mental model for how this code executes if the sprite is clicked multiple times?
Based on how the variables change, it doesn’t seem to be spinning up a new forever loop each time the sprite is clicked. But it does seem to keep one loop running. Does a second click somehow stop the first execution?
TL;DR: Yes.
The long version: You can decide how you want Snap! to handle overlapping events, with the “Thread safe scripts” setting:
When the box is unchecked (the default), a new matching event while an event-based script is running will stop the old process and start a new one from the top. The main reason for this non-intuitive (I think) default is to support playing music, because you want a new note to start over if the old one is still playing.
But if you check the box, then a new event while the script is (still) running will just silently be ignored. This avoids overlapping events, but at the cost of missing some events.
Of course the really right behavior would be to put the new event in a queue, and make it fire when the previous one finishes. So we don’t offer that option. :~/
I’m confused. Won’t this thereby terminate the previous note?
Regardless, you can get two other behaviours using LAUNCH.
1) Allow multiple threads for the single script, no inputs get ignored and no processes get terminated prematurely.
Won’t this thereby terminate the previous note?
Yes, but notes starting on time, on the beat, is more important than their duration. (I should have said, clearly if this situation arises it’s because this voice has gotten out of sync somehow and we are recovering.)
Note that this implementation can be messed up by pressing the stop sign prematurely. With the advent of processes in 12.1, this can be fixed
I sure hope it doesn’t turn out that users start routinely finding a need to subvert the stop button. It’s only because of the risk of smashing an expensive physical robot into a wall that we reluctantly made it possible to run code after the user pushes stop, so you can shut down the robot’s motors.
I think they really meant that processes could be used to continue the queue after the green flag is clicked again, so pressing the stop button would still stop them. But even then, this could be done without processes, just store the queue of grey rings in a global variable list, which does persist between project runs.
Yeah, sorry, that wasn’t clear. When a user clicks the stop sign and then clicks the sprite again (before or after pressing the green flag), the “running?” flag will remain true indefinitely, resulting in any new queued programs never running. In Snap 12.1, we can simply store the process itself in the block variable and check if it has terminated instead - this way pressing the stop sign won’t break the queue block permanently, instead immediately starting any new queued script.
