When I use “recordMacro” I often found that the recording stopped of its own accord. It seemed to be when I was doing a few keystrokes in a row.
So I tested it by trying different speeds.
If I slowly press the keys, the recording doesn’t stop (I continued to about 150 key strokes), and I can use playMacro to replay the keys after I manually stop it. If I press the keys quickly (I use 4 keys and quickly press one after the other in a rotating motion with 4 fingers), after a short time (sometimes 20 keys, sometimes 70 keys), the recording is stopped. I can’t replay what was recorded up to that time.
I think this started happening only relatively recently (in the last … half year maybe?). When I first used the feature when I got the keyboard, I didn’t have any issues with this. But it’s become quite debilitating (I use macros a lot).
There is 2048 bytes reserved for the macro recorder. When you reach them, the oldest macro is deleted in order to free space for the currently recorded macro.
However, above logic may easily lead to deletion of all macros when you try to record a single long macro, or maybe just start recording accidentally. In order to prevent that, there is another rule:
If the macro you are recording surpasses 1/4 of the space, the recording stops.
Now how much space does key strokes take:
we record usb report states, so every keystroke causes two changes.
empty report takes 1 byte
single scancode takes 2 bytes
multiple scancodes takes 2+<number of active scancodes> bytes, i.e., at least four.
In other words, when you are typing quickly with key overlaps, each keystroke can easily take 8 or so bytes.
512/8 = 64 keystrokes.
I am not aware of any change in behavior for ages, and I don’t even see any significant changes in git between v10.0.0 and now.
Testing:
my test shows that macro recording ends after approximately 17 asdf rolls. Numbers from the above estimate match pretty well: 17*4*8=544.
I have managed to record 5 macros containing 10 asdf rolls each. Sixth overwritten the first macro. 5*10*4*8=1600
This matches the expectations.
Of course, what to do about it is another matter entirelly.
You could build a custom firmware and assign all unused memory to the macro buffer.
You could drop the 1/4 condition in the code so that you can have a single long macro.
We could finally repurpose the validation buffer to storing data, and allocate part of it to macro recorder.
We could write some smarter algorithm. edit: actually I have an idea that can significantly improve things… but not sure when I can get around to implementing it…
Good to know. Kinda changed the way I look at things a bit.
(Also, weirdly gave me flashbacks of editing super sloppy MIDI data from MIDI guitar pickups. I wonder how much of a nightmare that’s going to be with the new MIDI 2.0…)
I see, thanks for the great explanation. It pretty much matches what I’m seeing - under 70 chars (70*8=560).
And I’m probably wrong about it changing - maybe I’m only noticing it now due to being more confident and therefore quicker in Colemak (I switched when I got the UHK).
I suppose the best, and probably easiest, would be to remove 1/4 limit. If I overwrite existing macros because my recording is too long or if I accidentally start recording, that’s my issue.
Is there already an option for that? If not, can it be added?
Thanks, I’ve tried that out. I’m not sure if there is a precompiled firmware for that branch, so I tried compiling it myself.
I’ve run into an issue - I could compile and flash the rightv2 & keycluster (the only module I have connected), but “left” kept coming up with “left is not a valid device name!”. If I switch to 80 (switchZephyr), “left” is known, but I assume that’s for the 80, not the 60v2.
So now I have the right & keycluster using the branch firmware, but the left is still on 15.0.1. I don’t know what issues that causes.
However, since the macro limit is on the right side, I could test it and confirm that it works. I was able to get above 250 chars doing the rolling keys. And in my normal work, I’m no longer getting the recording stopped.
Can that be merged upstream? I think being able to do longer macros would trump the risk of overwriting existing macros.
Thanks for the super quick response on this. This is why I have a UHK.
“leads to a ci action” .. I don’t use github, so I’m not sure what that means. There isn’t anything downloadable from that page that I can see, nor in any of the other links leading from that page, which is why I compiled my own.
So if this isn’t going to be merged upstream, does this mean we simply have to live with small macros? Or has all development stopped on the 60 anyway?
. I knew the storage was not optimal, but I never cared to compute how bad actually.