For some reason I have to strike a Key Stroke twice in order to fire off a Translator.
Second,
I have Preset A and Preset B
Preset A
Translator 01 = Incoming > Keystroke (T) Outgoing > Mouse Position XX
Translator 02 = Incoming > Keystroke (T) Outgoing > Activate Preset B
Translator 03 = Incoming > Keystroke (T) Outgoing > Deactivate Preset A
Preset B
Translator 01 in = Incoming > Keystroke (T) Outgoing > Mouse Position YY
Translator 02 = Incoming > Keystroke (T) Outgoing > Activate Preset A
Translator 03 = Incoming > Keystroke (T) Outgoing > Deactivate Preset B
For some reason Mouse Position XX is not happening. But Mouse Position YY is. As I said, I have to press (T) twice for anything to happen, and when it does, Mouse Position YY is executed and Mouse Position XX is not. So I put a 100ms delay on Activate Preset B and this fixed it. Almost like there is some sort of âbleedâ from the first (T) activating the Translator in Preset B.
I set up this project for someone to have a look at.
Hi,
When there are several translators with the same incoming trigger, sometimes they are executed in parallel which is probably what is causing the issue. If you want a series of events and want the guaranteed to be in order, you should insert delays to ensure the outgoing actions are in the order you want.
Here is an example. In the first translator I introduce a 20ms increment and added rules to increase each step.
Hey Steve,
Thanks for the reply. I understand what you are saying, but this particular Preset and Translator set up was fine in my 1.8.4 project. Oh well, I can always roll back to 1.8.4. How did you go with the Keystroke not working on the first press. It may be my system or a windows thing.
Hi Jesse,
thanks for the report. From your separate bug report, I read that youâre using Windows 10.
I suggest to always use (and post) the Log Window to understand why and how something is working in MT Pro.
In addition to what Steve said, 2 observations:
I can reproduce the issue that only every second T keypress is triggering the actions. Weâll work on that bug. It does work when you use key combinations (like Ctrl-T) or Key Down or Key Up only.
I can reproduce that with âPhysical Keysâ T, Translator 0.0 is never triggered. Probably related to the previous point.
As Steve suggested, you have a race condition in your presets: translator 0.1 activates preset 1. Now the incoming event (keystroke T) continues processing preset 0. As Steve said, meanwhile, preset 1 is activated. Now when the incoming event has finished processing preset 0, it depends if the activation of preset 1 is already done or not. If yes, the translators in preset 1 will be executed, too (because theyâre also reacting on keystroke T as incoming action). Otherwise, theyâre ignored. This is â sort of â at random and you should not rely on this behavior being either this way or another way. The fix is to add a very small delay (a couple of milliseconds) to translator 0.1 so that activating preset 1 will always come after processing the current incoming event.
Weâll follow up with the bug. Thatâs quite a serious bug!
Thanks!
Hi Jesse,
Iâve found the cause for this bug. Fortunately, it only occurs when deactivating the current preset in response to a Keystroke incoming action, without delay.
The problem was that the Keystroke incoming action received the key down T event and deactivated the preset. Then when you release the T key, the preset is deactivated and the translator action will not receive the T release event. The incoming keystroke action has a lot of logic to handle overlapping keys and modifier keys, and a bug in that logic prevented an incoming action to re-trigger when it thinks that the key in question is still held down.