Hi, thank you for the bug report. I have tested your example project and I could not reproduce it.
In theory, however, I believe I know what’s happening:
Preset 0 activates preset 1 when you press space. Preset 1 also has the same action for when space is pressed (activate next), preset 2 also reacts on space, etc.
Now during processing, the MT Pro engine goes from translator to translator and tests if the incoming action matches the detected key stroke. If preset 0 is currently active, it will match the translator. The translator will activate preset 1 and deactivate preset 0. But processing of THIS space key is not done. It will continue to the next preset and see that it is active (now), and therefore process the translators in there. It matches the incoming SPACE key and executes the outgoing action: activate next preset… I think you get the point.
This also explains why “activate previous preset” does not suffer from this problem.
Now the reason why it is not 100% predictable is that MT engine processing is multithreaded, and depending on situation/OS/other stuff going on the incoming action and/or the outgoing action might get executed synchronously vs. asynchronously. In the former case, you’ll see the unwanted behavior. Note, the only thing the MT Pro engine guarantees is that events of a given type are always matched in the order they come in. And vice versa for outgoing actions, their order is also maintained (but might be scheduled async wrt to other outgoing action types).
Here are 3 ways which should fix your situation:
1) activate the stop processing flag on all translators processing the “activate next preset”. It means that whenever the given incoming action triggers, it’ll process it, but then discard this incoming event (so following translators will not be tested for that incoming event).
2) Set a 1 millisecond delay on the outgoing action “activate next preset”. Like this, you enforce asynchronous processing of the outgoing action. When the next preset is activated, the triggering event is already fully processed.
3) use a global preset switcher preset. All the “activate next preset” actions will be bundled in this preset. You can mark this preset with “ignore for next/previous preset switching” so that it always stays active.
If your setup allows it, I’d always prefer option 3.
So in summary, I believe that it’s a feature, not a bug… but I agree that it’s not nice that the behavior is not entirely deterministic. But MT Pro’s flexible engine allows the user to create race conditions of this type and of other types, too…
Let me know what you think.
Florian