I’m trying to setup a dynamic macro to tap a key with a scancode offset if double-tapped, otherwise just press the key.
setVar next_key ($thisKeyId + 4)
ifDoubletap final tapKey $next_key
holdKey $thisKeyId
It errors at the variables in the last two lines. The best I can deduce is that variables are not supported at all in commands like this and instead are only usable in statements. Is this correct?
First of all, keyids and scancodes are two different things.
ifGesture)holdKey and tapKey take scancodes.)The syntactic problem with your macro is that we don’t treat scancodes as integers. They can be referenced only by their abbreviation.
Second, I don’t understand what and why you are trying to do, but my intuition says it is going to backfire.
The best I can deduce is that variables are not supported at all in commands like this and instead are only usable in statements. Is this correct?
No. Generally variables can be used in commands, but SHORTCUTS are not supported as a type in variables, so commands that take SHORTCUTS in turn do not parse them as variable expressions.
See the grammar firmware/doc-dev/reference-manual.md at master · UltimateHackingKeyboard/firmware · GitHub for exact information on what is syntactically possible.
Oh, that makes sense now!
I just found out about smart macros and I even had to update my firmware to make use of them, so I’ve only had like one hour of learning.
I’m trying to create some macros that allow me to effectively “press” keys on the opposite half based on “tap-dancing” or double tapping. I wanted to avoid making a macro per possible key.
The primary motivation is for games and specialized software.
I’m going to read over the document you linked and try to understand a bit better.
In the meantime is what I’m trying to do possible with the current macro features? By that I mean: press a key that’s offset to the one just pressed?
Well, there is the activateKeyPostponed [atLayer LAYERID] [append | prepend] KEYID command.
But be warned: keyids are not arranged in a precisely regular manner, so offsets might easily not work the way you wish them to.
The above command can also be used to trigger actions from different layers, so you could map your right half in your left half layers, and then just activate activateKeyPostponed atLayer fn $thisKeyId. This sounds workable to me, unlike an offset-based solution.