How does "processing" work?

First of all, we have to check the architecture. Based on reactable 's principals we need to separate  the part that is responsible for the connection of the patches (depending on their position), from the part that makes the sound and the part that makes the graphics. In this way, we can improve every part without having to change anything to the other two parts.
This way we can change / improve the pd - objects so to get better sounds (ex. use filter from another pd-library), we can improve the graphics (ex. make better sliders or new controllers that control the same sound parameters) or change the connection options (ex. we have circular and linear reading of the table, but the patches have the same code, or change connectivity settings such as the limit connection distance, angle etc.).
As we have seen the Spyractable's architecture is compiled someway like this:

This means that the hole project is made in "processing", and even though the sound seams to be created outside "processing", it's still controlled from "processing" and in the end it is synthesized by "processing 's" libpd library, that is reading and exchanging data with the pd-patch.
So we have "processing" inletting data, from computer vision program, translating from OSC messages to Java classes data and elements.
Then depending on this data, after calculations, it sets the parameters of connection, as well as the parameters of the visuals and the sound.
"Processing", also, draws the graphics on the screen and exchanges numerical data with the pd-patch, setting, this way, the parameters of the sound and the parameters of the waveforms.
So we firstly have to see how "processing" is working...

The reading of the code in linear, meaning that every complete "command to do something" is executed just when the reading by "processing" is ended. Then the next complete command is executed and so on...
The code is being separated in 5 parts. The first part is the firsts reading lines, so there we can declare global (to our program) objects and the importing of the libraries.
After that "processing" is expecting to read a "setup()" method. What is commanded in "setup()", is only executed one and only time. Also, anything declared in "setup()" can only be seen in "setup()" (as expected from a common method). This method is a good opportunity  to initialize all objects and variables.
If "setup()" ends, "processing 's" 3rd part of code is the standard "draw()" method. "Draw()" method is the one that makes "processing" 'running', since it can be read in a loop, executing again and again the same commands and methods. We just change these commands' and methods' parameters and we take the outcome. If a method commands the picturing of a circle with center (x,y) and every time this command is read, these coordinates change  price, then we see a circle moving...
The 4th part of the code is constituted from some callback methods. These methods are called automatically by "out - processing" factors, such as mouse clicking, midi-in order, joystick sensing. and others. Most of them are libraries orders, in Spyractable TUIO - data from computer vision program and midi orders from keyboard. When the multi-touch table changes its state (finger on, fiducial is being moved / added / removed, we take this data from TUIO library callback methods and used from the connection manager to set up the connections, or used to change the parameters of the classes.
5th and last part, is all the code of  classes and methods (patch methods, visualizing methods, connection manager, etc.).
When "processing" starts the compiling of the code, it does a short reading of the complete code (part 1 to 5), in order to inspect code errors and set the classes and methods in memory (short of).
Then it starts reading again part_1 and execute it.
Then part 2_and execute it
and tHen part_3 in the loop.
Part_4 is executed whenever is called a method and just changing the parameters of the code executed in constant, by part_3 - "draw()" method.