Refactor, improve code to deal with threads in a cleaner way

[hamoid]

Processing sketches follow a specific sequence of steps: setup() first, followed by draw() over and over and over again in a loop. A thread is also a series of steps with a beginning, a middle, and an end. A Processing sketch is a single thread, often referred to as the "Animation" thread. Other threads' sequences, however, can run independently of the main animation loop. In fact, you can launch any number of threads at one time, and they will all run concurrently.

You cannot draw to the screen from a function called by thread(). Because it runs independently, the code will not be synchronized to the animation thread, causing strange or at least inconsistent results. Use thread() to load files or do other tasks that take time. When the task is finished, set a variable that indicates the task is complete, and check that from inside your draw() method.

Our main program and control panel run in different threads. This introduces complexities that need to be solved.

[hamoid]

I'll try to describe the issue to myself here.

We have two sketches. Each has its own setup() and draw(). Each can send data to the other. This data should not trigger any direct changes, but should be stored and accessed later from inside draw(). If the data has immediate side effects (drawing stuff on the screen, or modifying data that the draw loop needs) errors occur. The way to deal with this seems to be: a sketch can receive data from the other sketch, store it, and set a flag that indicates this data has been received. The draw() loop will act on that flag, maybe imitating openFrameworks' update() method: if(newData) { update(); }. This enforces that visual side effects are only run from inside draw(), and not in a different thread.