I haven't given up
Local and global variables can be used as you described, replacing pieces of a MIDI message. You are 100% correct. Either type of variable can also be used to create conditions for completing a translation. Think of a translator as a complete process, right? It responds to the conditions set in the incoming message (cannel, message type, message value, message position), goes through all of the rules and, if all conditions are satisfied, goes to the outgoing message.
The only difference, really, between a local and global variable, is that global variables retain their value between translators. So if a global variable is set in Translator 1 to a value of 4, Translator 2 can use that to change its messages. Like a shift key.
If you replace a byte of data in the incoming message with a variable, that translator will proceed regardless of the value of that byte. So, for example, if your incoming message is 90 30 pp, the conditions are met if that last value is 01, 40, 7F, 5E, etc. But if the incoming message is 90 30 7F, then it will only be satisfied if that specific value is met. Since we want the timer to be triggered ONLY when the button is pressed, and not when released, we want the value to be 7F only. If it was pp it would trigger on 7F AND 00. And we want to avoid that.
The rules are then calculated. It's just a basic form of code, really. Whenever the incoming message is received, the translator begins processing the rules. So, 90 3C 7F is received by MT Pro, and it moves to the next step, the rules. So whenever that message comes in, gc gets its value increased by 1. If gc is greater than or equal to 2, then it remains 2. This is a control to prevent gc from ever becoming more than 2, since those values are important for future translators.
When the button is pressed, and gc is 0, gc becomes 1. This is used as a reference later in the code. So the incoming message is processed, the rule is processed, nothing is stopping it from getting to the outgoing action, so that is triggered. This sends out a timer message with an initial delay of 300ms. When using a timer, ALWAYS use the timer delay values unless you know why not to. You want the timer to fire 300ms after the button press. You can play with this range, because it's how much time you have to press the button again.
So the first translator fires. Then the second translator comes in. After 300ms MT Pro calculates the value of gc. If you've pressed the button once, it is now 1. The timer goes off, completing the incoming message, and moving to the rules. GC=1, so the first step is ignored. If gc did not equal 1, then the outgoing action would be skipped. Since gc DOES equal 1, it now equals 0 and then the outgoing message processes. If you had used a local variable, this wouldn't work because translator 2 can't see what the value of pp (as an example) was in translator 1. Because we used a global variable, Translator 2 can use its value as set in translator 1.
Let's say you pressed the button twice within the 300ms window. So now gc=2. So the timer goes off, which satisfies translator 2. But gc=2, and not 1. So the first rule can't be satisfied and the translator is aborted. The rules are canceled and the outgoing action never completes. But it also triggers translator 3. Since gc=2, we skip the next two rules, which reset gc AND exit the translator. Instead gc=0 (so it can be started again from the top, and then the outgoing action is processed, which is different from translator 2.
Now let's say you press the button 5 times in that 300ms window. That's okay. The rules in Translator 1 won't let gc be greater than 2. And then when the timer fires off, gc is reset anyway. In fact, you should add a new rule to Translator 1 so it looks like this
Code: Select all
gc=gc+1
if gc>=2 then gc=2
if gc>1 then exit rules, skip outgoing action
So the timer will only activate when the button is pressed the first time, but the rules are still processed so the variables can be calculated correctly.
Jared
) to take incoming note 68 and output note 68 which solves a previous problem of Mobius not even taking the mapping since it kept on detecting the note 60 as the 1st incoming message and would map only that one. It now maps correctly but since I set Bome MT's Router to pass on thru the MIDI from the Bome's MIDI driver IN to Bome's OUT so the other MIDI messages would come through as well...that's exactly what happens meaning, I'm sort of back to square 1 with Mobius taking on the 1st message & executing it, i.e. that darn note 60 (Foot On)!!
Typically, I can see myself having a revelation where from one moment to the next, it all makes sense, just not there yet! I'm just missing something, some key explanation that will make all the puzzle pieces fall into place. For now, over thinking it as you said. 