Portability of scripts for different hardware

Bome Products
1

I have a 4x8 button grid that sends Note On/Off info to MTPro/BomeBox that is then translated into combinations of CC messages and sent to a sequencer. I am using the fact that the incoming Note #'s are sequential as part of my code. That is, I test to ensure the range of the incoming Note On msg, then I do some math stuff on the Note # value to determine Row & Column, which is used to calculate what the outgoing info is going to be.

However, I'm working on a section that I may need a bit more flexibility because: reasons, and I'm thinking about that time when I want to use a different button controller, or even build my own controller - it'd have to be in the same sort of sequential button/Note convention.

I'm pondering updating my code to define a series of Global Variables for Inc Note #. That is, "Hey, this button here that does this thing. Right now it's looking for Note 48. But I'm going to make it look for note KA (Global Variable)"

I recognise this means I will have to either put in at least 32 If/Then statements to assign values to variables at the top of my existing Translator or copy my Translator 32 times for the different Incoming Note Values entombed in Global Variables, but in my head this makes the whole thing super flexible and applicable to ANY button controller or group of button controllers or even keyboard controller Note Ons. (Plus, where the Note Ons don't have to be sequential - where Button 1 and Button 2 are next to each other, I can just as easily have any actions that were previously Button 1 be a "C' and Button 2 which was previously next to Button 1 be an "A", thereby allowing me to construct 'chords' to do a thing, rather than discrete button presses...but I digest.)

Note: I already use plenty of Globals in my script for things like "Button Colour On" and "Button Colour Off" because I prefer flexibility, and I change my mind about what colours I like (next step is to define 'themes' for the button controller! LOL).

I'm just wondering if I'm overlooking some sort of 'under the hood' functionality that's going to lead me to tears, frustration, and an unending sense of dramatic, yet pervasive ennui. Should I avoid doing this (and not 'waste' the hours (days or weeks in my case)) because ultimately it will be problematic?

2

Hi Jim,

I’m sure there is a question in there somewhere. 😉 I guess you are asking if you could set up a matrix controller where you define rows and columns and depending on the controller you are using translate them into different note numbers (depending on the controller you use).

I’ve done something similar in the past. You create a few routines:

  1. Note to RC Converter (for taking incoming notes and convert them to RC (Row and Column) format. This is later passed as a set of global variables to a different translator to determine your outgoing action)
  2. RC to Note Converter (usually for LED feedback and again passed to another translator to determine which LED to turn on based on the R and C variables.

The trick then is to put these converters into their own presets (for each controller) and only enable one preset at a time (depending on the controller you are using).

Then all other translators trigger on a the timer output of the Note to RC or RC to note converter for final execution.

It is not for the faint of heart to set up, but yes it can be done. I’m still on the fence as to whether the effort is worth it or whether just simpler to recreate the project for each controller type.

Every time you define a new controller, you just create a new preset and translators for the converter routines. Of course controllers in a sequential matrix format are easier as you can calculate R and C using math. If they are not sequential, then yes, you need to do a bunch of if statements in rules.

 

I hope this answers your question and that this is the question you were asking!

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

3

Thanks for the response, Steve.
Actually, I’m going the other way around.

I currently convert the Note# into a column and row value and use that to calculate the outgoing values. However, this creates a system that is dependent on incoming notes being a specific range *and* ‘sequential’, or related in some respect.

I’m thinking I’m going to take my scripts that are written in that respect and change them to an absolute value. Right now my Incoming is Note On, set value to pp, any velocity
Then I test for pp being in range of my button controller.
Then I covert to a column and row value.
easy peasy

 

But instead I want to do Incoming: 90 KA pp (example only, basing this on one way to achieve the results I want)
where KA is a Global Variable that has the Note value stuck into the Init Translator for variable definitions.

(Truth be told, i’m probably going to just allow all Incoming Notes and then test against the 16 possible Globals, with an exit if there’s no match…because I think that will require less ‘ground up’ coding. There’s only 3 sets of 16, and each set is a different Translator.)

I recognise this changes my error correction tests, and adds either more Translators (one for each button) or a bunch of If/Then {assignment} lines to my existing Translators. But it means that eventually each button is independent of the others and don’t have to be sequential numbers, etc, etc. Also means I can just pop in any controller, put some values into the Init routine, and done-done.

So…think that’s going to barf on some accepted practice or under the hood process that will nerf the whole thing?

I’m only asking because I don’t want to spend months developing something (because I’m an idiot, it takes me a long time) and then have it ‘not work’ because I overlooked a functionality in my ignorant zeal.

BTW – This is expansion of the script I chatted you up about.
That script runs beautifully and I’m just taking it to another level with swapping temporary play masks, and expanding the Melodic/Alternate melody features.

All of this would be so much easier if MTPro had arrays. heh heh

4

Certainly this can be done. Probably best to use an IF construct on the given note with 16 different possibilities. Set the outgoing to -1 initially and then use the IF statements.
If you get to the end and the incoming global variable is still -1, then abort the translator, otherwise use the calculated outgoing value.

5

Wow, that’s a much better way of implementing it than I was thinking. THANK YOU!

This makes me happy.
I have a bizarre fantasy of something like a Zen Drum but controlling my sequencer and synths in ‘that weird way’ that I relate to things.

well, until I can get my hands on a vintage Buchla Lightning system. heh heh

THANK YOU Steve! 🙂

6

Glad to help as always, Jim!