A nasty, repeatable bug - test code provided!

I've just spent many, many hours trying to figure out why a very simple translator (a patch change!) would not work even though the MIDI log was indicating that the correct output was being sent (e.g. "OUT 1.0: MIDI C6 04"). For a while, I was even thinking that the receiving device had failed since the MIDI log said the correct command was being sent. However, the problem was not with that translator at all!!! It was with another one--arghhh! I only discovered the source of the problem when I deactivated other translators and suddenly the patch change worked. The culprit is below and I found that an equivalent translator, further below, did not cause any problem. I sure hope someone fixes this and soon

Okay, the translator that screwed up my patch change is as follows:

Incoming trigger: B1 qq pp
Rules:
if qq!=80 then exit rules, skip Outgoing Action
g0=6
if pp==0 then g0=7
Outgoing Action: None

All it does is wait for the press of pedal #80 (0x50) and it toggles global variable g0 between values of 6 and 7, since the pedal value toggles between 0 and 127. Seems simple enough but as I said, having it active screwed up the MIDI output of my patch change translator (not shown) even though the log said the output was fine.

I couldn't see anything wrong with the above or my other translators so I replaced the above with the following (which is equivalent):

Incoming trigger: B1 50 pp
Rules:
g0=6
if pp==0 then g0=7
Outgoing Action: None

With this, everything works fine.

Audios

Hi Audios,

thanks for this detailed report and sorry for the time it took you to isolate the issue!
It seems that VERY basic operations fails here, and I would be surprised if really MT is at fault because there are people running presets with thousands of similar translators in critical environments and there's no problem. But who knows, nobody's perfect, not even MT!

Looking at the provided translator and how you were able to fix it, I see two legitimate ways why your second translator would fail:

1) in your first translator, you have "stop processing" checked
This means that if the "incoming" section matches, this particular incoming event will not be processed in further translator entries. Now if your second translator has as incoming trigger any controller on channel 2 (MIDI status "B1"), it will never be touched, because your first translator caused processing to be aborted.
Setting the incoming trigger of the first translator then fixed it, because "B1 50 pp" will only stop processing for this particular controller.

2) in your second translator, you rely on the local variable "qq" to have a particular value.
Local variables are local to the incoming events, so if you assign it in one translator, following translators that react on the same incoming event will share the same local variables.
This is just a theoretical cause for your problem, but I wanted to mention it to raise awareness of what a local variable actually is.

Let us know!
Thanks,
Florian