Folks, I’ve been experimenting with adding first-class processes to Snap! and I’d love for you to give them a banging and let me know any issues you encounter (here, in this thread).
In the current v.12.1-dev version there is a new library called “Processes”, along with a new selector in the “my” (attributes) reporter:
You can use these blocks to programmatically launch, suspend, resume and terminate threads, and to inspect their properties, such as their current state, their procedure-script, their current block (stackframe) etc. You can keep track of processes in variables and lists, and I’ve made some new “gears” symbols to visualize their state. Some of these are animated and can also be used elsewhere in your custom blocks.
Here’s a rough demo of how the blocks work:

First-class processes is - I think - among the last first-class things Snap! is missing, so this addresses that.
What’s the use case I have in mind for this? Some extensions (and projects) can be greatly improved by one or more helper-processes that always run “in the background”. For example, if you want your project to track your hand and fingers in your webcam’s video feed you need to constantly take single snaps of the video and compute the body / face / hand landmarks on them, before you can even do something interesting with them. If more than a single script follow different body features every script needs to make sure to keep track of the relevant landmarks all the time. This can be a pain to program and a significant strain on performance (as I’ve found out when I tried to do just that with kids last week at SAP).
Here’s an example. Nevermind the state-machine of that custom event block, even the simple script on the left that makes the sprite follow the hand is really complicated:
this is where - I think - first-class processes can help: Every custom block that relies on a certain feature can first call a block that constantly tracks them. This way, the “center of hand” reporter doesn’t need an input slot for the “hand landmarks” anymore:
That block, in turn, checks if a tracking process is already running, and only (re-) starts it if it isn’t (either because it hasn’t been started or because the user has pressed “stop” at some time).
The tracking process constantly analyzes the current webcam frame for certain body features and publishes them in a global variable (which can be hidden, but the other custom blocks query it). And that lets us build really easy-to-use custom blocks for such domains:
Here’s how that project-in-the-making looks right now:

And here’s a link if you want to give it a try yourself:
Thanks!









