I’m new to the scripting language of Bome Midi Translator but have a lot of experience in C and many other scripting languages.
I need to store all the CC messages from a device and that is being manipulated from a control surface to facilitate 2-way communication. In a C or other full languages, I would create a structure variable to hold all the information in various data types of sizes as required. Here we have the limitation of using a relatively limited number of variables. I have seen other replies from Steve about bitmapping to maximize storage. Let me describe my requirements and maybe I get a better understanding of how to approach to my need.
The device I’m controlling has 8 virtual machines each of which has 8 faders and 8 parameters controlled by V-pots. In total that would be only 96 parameters which I could just do globals but I prefer to have the ability to address the stored locations programatically which normally I would use a two-dimensional array. Simple enough. I’m wondering if we can automate the task of storing and retrieving values using bitmapping so it functions in a similar way.
Well Bome MIDI Translator Pro is not really a language per se. More like just rules.
There is only one data type; 32 bit unsigned integer.
You could use 1 global variable to map 4 7 bit CC’s but I really don’t think it is worth it unless you are running out of global variables (there are 720 of them).
I usually use bitmapping when there are a lot of buttons with an on/off state. So my APC MINI I use 2 global variables to map the matrix buttons.
There are no constructs like arrays either. The global variable names are fixed (you cannot use your own names). I usually document all global variables used in a single translator.
See this tutorial.
8 virtual machines 16 controllers would be 128 global variables. I’m not quite sure where you got 96.
You can press F1 or help within Bome MIDI Translator Pro to view the PDF manual where it talks about both global and local variables and naming conventions for each.
Local variables are private to a specific incoming trigger. They are best use for temporary storage specific to a given translator.
You aught my mistake. Bad math. 128 values not 96!
I imagined perhaps using the Perform command someone might have created functions to simulate more robust storage and indexing for retrieval. Perhaps such a thing is possible albeit the perform does not have a method for implicit return of values although manipulation of globals could be used.
I always look for ways to form tight code by programmatically referencing data structures using index values.
Yes both named variables and arrays are on the list of things we would like to add.
I guess you could create perform names, each which manipulate a different variable but you would need a perform translator for every variable that you use.
You could use a timer outgoing action to set a global variable for the return value when done, but care would need to be given to ensure you don’t get a race conditions with multiple performs updating the same global variable.
All of this is kind of clunky though so for now I would just stick with using global variables and the pre-described naming. I try to use sequential variables to keep things straight. For instance for 16 faders I might use g0-gf.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz