Multiple Instances—what to watch out for?


I’d like to expand some of the functionality of a Bome app I’m writing but am running out of global variables. I’d like to use another instance of Bome to get access to additional global variables.

Will multiple instances decrease the stability of Bome (crashes, unexpected results, etc…)?

Both instances of Bome will need to use Bome Virtual MIDI ports. Any issues with that?

Any best practices I should follow when running multiple instances in terms of programming?

Anything I should avoid/watch out for?


There are 780 available global variables. I’m surprised you are running out but if you are, you are. Maybe you should, however look at a strategy to reduce the number of global variables. For instance, I use bitmapping for simple on/off state. With this I can map up to 32 toggle button functions with a single global variable. A variable is 32 bits.

I have not had any stability problems and I run multiple instance all of the time. I use a APC-MINI to control voicemeeter while my Win 10 PC is powered up. Then I do support on a separate instance. Sometimes I have to run 2 instances for support using one as an emualator and the other as a test target. I have heard recommendations against multiple instances but maybe these are based on older version of MT Pro as I have not ever tripped over any stability issues.

Not if they are using different virtual ports. On Windows, a given port (virtual or otherwise) can only be opened by a single application or device at a given time. You have up to 18 virtual ports on MT Pro (9 in and 9 out). If you need more, you would need to purchases Unlimited Named MIDI Ports.

Beyond using different virtual port, I would say watch out for keystroke and mouse sequences and make sure they are different on each instance as they are not differentiated between instances.

Here is a reference to bitwise operations if you are interested in exploring better use of global variables. As I say, I am currently using 2 global variables to control 64 LED’s on my APC-MINI to track Voicemeeter channel status.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:


You use multiple instances in your rig don’t you. Anything to add here in your experience?

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

Many thanks Steve.

I used several strategies to reduce global variable use (which saved me about 40). Based on my analysis, bit wise operations would have saved me roughly 10 variables while adding additional complexity as compared to just setting a global variable to 0 or 1. In the end I felt it not worth it just to save 10 variables.

What is really causing me to use global variables is my inability to 1) send a midi request that will return a MIDI cc value, or 2) force the VST I’m using to dump all MIDI CC values when the program changes.

If I could figure out how to do that I could eliminate a few hundred global variables from my Bome app and massively simplify it’s algorithms; unfortunately, it does not seem possible in my case.

The purpose of what I’m doing here is to expose most all of the parameters available in an Access Virus TI2 synth (roughly 100) via MIDI cc. That would allow me to use external midi controllers to adjust those parameters (instead of menu diving to access them). I use the Mystery Island VST (Virus HC) plugin which allows midi map almost every parameter on the Virus to a MIDI cc. I use one Ableton Push 2 and three launchpads as external midi controllers.

I ran into an issue when I want to access different sound patches on the virus. While program change commands do indeed change the active patch sound on the synth, it causes the values stored on the midi controllers to go “out of sync” with the midi values currently active on the virus. This results in the “parameter jumping” effect because the midi values on the external controllers no longer match the values in the new sound patch. I tried adjusting Ableton’s mid tracking to “catch” and some of the other options they had but the results were inadequate.

I could not discover a way to “request” MIDI cc values from the Virus HC plugin, nor force it to “dump” all the midi cc values on a program change.

To get around that I use the multi timbrality of the virus. I place different sound patches on 8 different Ableton tracks and use Bome to 1) store MIDI CC values on each track as they change, and 2) synchronize the display of the three launchpads depending on which track is currently being used.

Works well, but storing roughly 100 midi values across 8 different track uses up a tons of global variables.

It not pretty….but I don’t think there is another way for it to work.

Any ideas?

Yes, it looks like it has to do with the inability to query the Virus HC plugin for parameter changes. You just have to ‘catch’ them as they are sent from the plugin I guess. I assumed you asked them about this. If they have a SysEX query that can be used to query the plugin for a given parameter at will, that would be ideal. Not many devices or plugins have this type of capability.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: