Having a real hard time with a single OSC script in OSCII-bot that is misbehaving causing flaky functionality of a Midi Control Surface.
On what basis does OSCII-bot schedule its @oscmsg, @midimsg and @timer code sections?
The problem is that key global variables needed to communicate/share data between @sections appear to be being updated & read asynchronously on different threads of execution. Unclear or undefined scheduling or re-entrancy of the @midimsg and @oscmsg sections is giving timing overlap related functionality bugs.
Assuming that every variable is truly global (except when explicitly declared as local) as stated here
http://www.cockos.com/oscii-bot/oscii-bot-doc.html then how does the scheduling of the @sections work?
If a thread is part way through processing slowish code in @midimsg how and when does @oscmsg get called?, or is there a scheduler based on
a) all code is single threaded on a time slice that allows an @section to complete along with periodically running @timer
or perhaps
b) thread is interrupted and another thread executed as OSC data comes in to the network port's buffers
Given the functional but rudimentary OSCII-bot runtime and debug environment (a statement: but not a complaint!) it would be really useful to know this scheduling from "as documented behaviour" rather than spend a very long time experimenting and reverse engineering timing behaviours. The OSCII-bot source code suggests an answer somewhere in the mainProc function of midi2osc.cpp : but code reading has not yielded what is going on! Thanks