Are 0ms timer triggers multithreaded?

Are multiple translators set to trigger on a 0ms timer executed in separate threads?

I am just trying to sort out if I make a change to a global variable in one translator if it will be seen in a different translator triggered by the same timer event.

If they are indeed multithreaded, I assume that there is no simple way to directly have a translator wait until all translators that were triggered have completed their own threads.

Thanks for the great product and all of your help.

Ken

According to page 90 of the Bome MIDI Translators users manual (press F1 within MT Pro to open it), they are indeed multi-threaded.

Could you please let me know what you are trying to accomplish and maybe I can figure a way that you can do it. My guess is that you want to ‘block’ some sort of incoming triggers until series of events compete. Normally this can be done by setting a global variable when starting the timer, and and then resetting it upon timer completion, however multiple translators trying to update the same variable could be problematic since there is no ‘locking’ of variables for updating and you might end up with race conditions. There may be a way to get around this, however I’d like to ensure I know what you are trying to do (in a non-programming sense) before trying to tackle it.

Steve Caldwell
Bome Customer Care


Also available for paid consulting services: bome@sniz.biz

Thanks!

So sorry that I missed that in the manual. I’m trying to create a series of routines that allow me to switch between specific physical controllers via the device itself. For instance, switch between a mod wheel on a keyboard, a slider on a different device and an expression pedal (each on a different channel other than channel 1) for sending cc1 values on channel 1. So I trigger the change when the device goes higher than 120, less than 7 and then higher than 120 within 1500ms. It changes then sets two global variables to that channel and cc# to grab the incoming values and out put them on cc1/channel 1 with my DAW only receiving on channel 1.

This allows me to arbitrarily switch which physical device im using without having to fiddle on the computer, interrupting creativity flow.

I have it working for the above example but was thinking of extending this to other cc’s like expression and sustain. Which was when I began thinking about multi threading. I don’t want to introduce latency as my routines become more complex, so using the timer method, I send the message along using the current state of two global variables but if I am receiving messages on multiple channels for potentially multiple cc’s I was trying to figure out a way to ensure that one thread isn’t changing the same global variable as another

But I like the idea on setting a lock flag. That may cause some missed events but given the inherent sampling rate I doubt it would cause an issue.

Thanks again.

  • Ken

Yes, it is better to only have one translator handle updating a given global variable.

You might need to have each thread have it’s own updater on their own global variable and then have rules to check the state of various global variables to determine if all threads are done.

So thread 1 busy flag is ga, thread 2 is gb etc.

In general, I have not had to worry too much about synchronizing between things when changing devices. I generally use ‘activate preset’ and ‘deactivate preset’ outgoing actions to turn on or of sections of the project.

If the devices are the same then each preset would talk only to a given MIDI CH. Otherwise, you could have different device routing at a preset level as shown in this video tutorial.

Steve Caldwell
Bome Customer Care


Also available for paid consulting services: bome@sniz.biz

Great advice. I”ll rework my structure to ensure I have separate global variables for different threads and duplicate some common code in each thread to avoid potential conflict.

Thank you!

  • Ken