I'm getting right into programming up reasonably complex actions now... just wondering on tips for using variables, and general best practices.
If I want to use one control (e.g. sending cc1) to control multiple actions/parameters, I'm generally setting the first trans incoming to e.g. 'oo', then using that variable in the same trans to modify the first parameter. I'll then duplicate that trans and modify another parameter by changing outgoing message...
but I'm realising that this means that the second trans then searches for cc1, and reassign it to 'oo' which is a variable that already exists thanks to the first trans.
I'm having no issues using it this way, but this seems... not right.
So: is this acceptable no-harm-done practice?... I'm assumng its best to not do this...
should I:
Use one trans at the start to set the variable (no outgoing); then use all other trans commands with no incoming, but just refer to that variable??... that seems cleaner code-wise...
Or perhaps something else altogether?! :)
Any guidance from seasoned users is greatly appreciated!
Hi, the way you are doing it is OK if you us local variables oo,pp,qq,rr,ss,tt,uu,vv,ww,xx. No harm done because local variables are meant for just that (use within a translator). It would be poor practice, however to put global variables on incoming actions as global variables are meant to be shared and the second translator incoming action would override the first. Global variables start with g-n, y and z and have a letter or number as the second character.
Now if you have the same incoming action that you want to trigger say 100 outgoing actions and you later decide to change the incoming action, I would recommend you use a local variable for input then within the first translator rules, copy it to a global variable. Then use an outgoing action as a timer to trigger your other translators. That way you will only need to change the incoming trigger only once instead of 100 times. However it will consume a global variable as local variables from other translator will not be visible within your timer translators.
The main advice about global variables is to only use 1 translator to modify them and then multiple translators to read them. You don't want more than one translator trying to modify a global variable at the same time as you will get unpredictable results.
You can find more information on local and global variables in the user manual (F1 or help from with MT Pro).
Also there is a section on the use of timers. There is also a lot of tutorials on various subjects.
And of course, I'm here to answer any questions as needed.
I hope this helps.
Steve Caldwell Bome Q and A Moderator and Independent Bome Consultant/Specialist bome@sniz.biz
Oh... oh ok... cool thanks... I don\'t think I\'d quite put that connection properly to the meaning of \"local\"... I\'ve now been trying to name each variable independently for each translator in a given preset!... lol *face palm*
So just to be clear, in one preset if I have 2 translators and assign the incoming as variable \'oo\' for each, that value for the first trans is completely independent of the second trans?... because \"local\" is for just one translator row?...
I think (hope?!) I\'m understanding things better now... Thanks Steve :)
So on my QU16 with 16 faders, as I\'m looking to set-up weird and wonderful things for each fader, it may be a good idea to setup e.g. 16 global variables (one for each fader) to recieve it\'s value, and output to a zero-time timer (e.g. name the timers Ch1-Ch16)... then actually trigger my functions with a timer input... The benefit being that if I fancy swapping fader functions around for e.g. ergonomics then that saves me from entering each translator and editing the incoming action (I just need to reconfigure the 16 global setup translators)... is that kind of right?!
If that\'s correct, then I can see it also being handy for adding new functions, as I\'ll just need to add timers with clear naming at the incoming point...
I\'ll fiddle around with this approach and be intouch if I hit any issues.
Update... Yes - that workflow of using timers and one initial set of globals seems to be really clean and easy. I like it!
Unless there's some issues to watch out for, I'll aim to setup up a first preset in my project to grab and define key globals and output a zero-delay timer too. The conventional naming of timers makes it really easy to navigate around using these to trigger new translations too :)... e.g. I'm calling channel 1 "Ch1 ga" so I can easily see what it it and what it's variable is...
The other thing you can do is put something like faders all within the same translator instead of a different translator for each fader.
For instance if you incoming CC's are 0-7 for faders you could monitor for any incoming CC using variable pp as the CC number and then have a rule like this
if pp>7 then exit rules, skip outgoing action
Then you can use math on the variable pp to direct your outgoing action to a different midi message. Say your outgoing need 8-15 then in rules
pp=pp+8
then send the outgoing message to pp 8-15
If you need to track the values of each fader within MT Pro you will need to use global variables for that.
You have 10 local variables to work with within the translator.
As far as scope of local variables, you are 90% right, however it should be understood the the local scope is really based on the incoming trigger and not the translator itself. Most of the time you don't have to worry about this, but I thought I would point it out. If you just assume your translator is going to be discarded when it is done, you can use the same local variable for other translators with the same incoming action. Just keep in mind also that local variables are not initialized so they will be an unknown random value unless:
You set them in the incoming trigger
You set them in rules
The value is inherited from the last triggered translator with the same incoming trigger
I hope this helps.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz
Yes - I was starting to wonder about the use of variables to also pick up the CC# (or similar) and then use that to as a means of selecting parameters in another translator (as the Qu series seems to be fairly straight forward with channel functions and their assignment MSB LSB type stuff).
The mind literally boggles at the moment with some of the things I can now do. I'm obvisously very fresh still; but as I think I said somehwere else; I'm all in ;)