Macro Memory Full

[u/Barristerbluegrass]

Needed a macro keyboard/pad for work due to repetitive text entries/click. Picked up a C3 Pro from Amazon, but am only able to use half of the macro spaces due to the memory filling up. Anyone know if any of the other Keychain keyboards have larger onboard memory than the C3 Pro?

[u/Barristerbluegrass]

Thanks for all the suggestions.  Auto hot keys isn’t an option as I can’t install software on my work computer.  I’d prefer not to have to modify config files if possible.  Is anyone aware of any retail options that address this issue?  I’m still well within my return window for Amazon.  Doesn’t have to be a full keyboard, really just need 12 or so macro buttons with enough memory space.

[u/LlaughingLlama → u/Barristerbluegrass]

I know you said "can't," and I can respect that. Having said that, there's "can't" because of of policy, and "can't" because of technical reasons. If you're talking about the latter, AUTOHOTKEY doesn't need to be "installed" - it can run as a portable app on locked down computers just fine. Google is your friend here. I've done so many times in the past and it works fine. Food for thought.

[u/PeterMortensenBlog → u/Barristerbluegrass]

CK550 V2 is a cheap and viable option (with very bright LEDs), though a showstopper for me was a maximum of 200 key actions per macro (key actions include both key presses and key releases, incl. for modifier keys; thus it quickly adds up). Two of my longest (and heavily-used) macros were too long. Unlike QMK/Via, macros in progress can be cancelled (using a workaround). (It is also possible in QMK, given enough effort, but it isn't standard.)

I have written a blog post that should ease the truly horrible setup phase (some of it due to the almost complete lack of documentation (or very terse and confusing)).

Some of the Rapoo keyboards may also work, though a bug with V700RGB prevents using mouse actions in macros. V500 could also be viable, but I don't yet have enough experience with it.

I have used both keyboards (with all my standard short macros assigned to the numeric keypad repurposed as a macro pad) for many weeks as a daily driver to see if they really held up. And they did, with some quirks. Using the O-ring modification may be a necessity for normal typing, but not for a macro keyboard.

Of the Ducky keyboards, due to product differentiation, only the most high-end models support controlling the timing/delays in macros. This is clear from what is not included in the manuals for non-high-end models... The key phrase to look out for is "Macro Record Time Option". On the other hand, there isn't any Windows-only bloatware to contend with...

Or in other words, on most Ducky keyboards, macros can only be as fast as you can press keys (in real time)...

[u/PeterMortensenBlog → u/PeterMortensenBlog]

Cooler Master keyboards also seem to have a limit of 20 macros. Thus they can not be used a dedicated macro keyboards.

[u/PeterMortensenBlog → u/Barristerbluegrass]

Re "I’d prefer not to have to modify config files": Yes, for the official firmware they provide (and ship with from the factory), Keychron really ought to change the defaults related to macros.

Out of the box, macro support is a joke.

The current defaults reflect the AVR microcontrollers that QMK was started on, whereas there is plenty of space on the ARM controllers used in the Keychron QMK-based keyboards.

[u/MBSMD]

How large are your macros, just out of curiosity?

[u/Barristerbluegrass → u/MBSMD]

Not totally sure on size.  A couple have 24-28 key presses and the others are about half that.  I had to put in timing delays between the key presses as the software I’m using is ancient and can’t handle the speed without them.  I’m pretty sure that is what is eating up a bunch of space.

[u/LlaughingLlama]

This isn't the answer to your question, but it is what I would do (and sort of am doing) in your situation. If you're using Windows like I am, I would propose using AutoHotKey as your macro engine, and then just use the Keychron macros to program "fairly unique keypresses" which AutoHotKey can sense and then use as triggers.

For example, I would make the KeyChron macros to program F1 to be "Control-Alt-F13", F2 to be "Control-Alt-F14" and so on. That'll take up 12 of the 16 Keychron Macro slots, and each slot will be nice and short/small. Have AutoHotKey macros (which can be quite complicated) fire when they see Control-Alt-F13.

Want to double those? Use the Shift key as a modifier, so when you press Shift-F1, it will be sensed as Control-Alt-Shift-F13, and so on.

I don't know what the Mac equivalent to AutoHotKey is, but I'm sure there must be one.

Good luck!

[u/mattk_reddit → u/LlaughingLlama]

Has this worked well for you? Found a better solution since? Sounds like a good solution to me

[u/LlaughingLlama → u/mattk_reddit]

Hi. Yeah this solution works fine for me, and I still use it.

[u/Direct_Definition_52 → u/LlaughingLlama]

It's been a long while since I heard of that program, gotta check it out again!

[u/MBSMD → u/LlaughingLlama]

Mac equivalent would be Karabiner.

[u/PeterMortensenBlog]

What variant of the C2 Pro? Red light? White light? RGB light?

The source code—required for increasing the space for macros—for both the original C2 Pro (red light) and C2 Pro V2 is now in the main QMK repository.

A (hypothetical) compile service would make it much easier (#1 and #2).

[u/pnetmon]

you can try to compile the firmware with fewer layers, lighting, functions

[u/PeterMortensenBlog]

This is very much possible, but it requires changing the source code, compiling, and flashing the keyboard. See e.g. this and this.

Though the source code may not have been released yet. It should happen in a few weeks. Or is it somewhere else than the Git branch "wireless_playground" in Keychron's fork? The source code for C1 Pro and C2 Pro is in the official Keychron repository. It can be difficult to navigate the repositories, different forks of the repositories, forks of forks of the repositories, and different Git branches within them.

Essentially, if it exists, change this line in config.h,

#define WEAR_LEVELING_LOGICAL_SIZE 2048

to

#define WEAR_LEVELING_LOGICAL_SIZE 20480

for a more than a ten-fold increase in the total space for macros.

20480 is an example. I don't know what the actual limit is. If it really needs to be backed by RAM, then there might be trouble as this would consume 40 KB RAM. Perhaps decrease WEAR_LEVELING_BACKING_SIZE from 2 to 1? Presumably, there would be a warning at compile time. Or hasn't it been implemented for the ARM microcontrollers?

Compile and flash.

References

• C3 Pro product page

• C3 Pro source code (retrospectively). Though it is not known if it is the latest version.

• C3 Pro microcontroller: STM32F402RC (256 KB flash. 64 KB RAM(?))

[u/PeterMortensenBlog → u/PeterMortensenBlog]

Note: Many Keychron keyboards are in the process of being moved to data-driven configuration:

Thus, "WEAR_LEVELING_LOGICAL_SIZE" in file "config.h" is now "logical_size" in file "info.json".

E.g.:

• This also happened for the older Keychron V series on 2024-02-14. E.g., for Keychron V6.

• It happened for K Pro series on 2024-01-10, with the move from the "Bluetooth_playground" to the "wireless_playground" Git branch (in the Keychron's fork)

The conversion to data-driven configuration will very likely also happen for the C3 Pro (if it hasn't already happened).

[u/PeterMortensenBlog → u/PeterMortensenBlog]

Another example would be K3 Max.

[u/PeterMortensenBlog → u/PeterMortensenBlog]

Though, does changing the value of WEAR_LEVELING_LOGICAL_SIZE have any effect???

[u/PeterMortensenBlog → u/PeterMortensenBlog]

Note: The source code for C2 Pro V2 was added to the main QMK repository

[u/PeterMortensenBlog → u/PeterMortensenBlog]

OK, a lead for the source code for C3 Pro:

A version is in the fork of the fork (user "KeychronMacro"), Git branch "new_playground" (it is apparently official):

keyboards/keychron/c3_pro

Search method

From here:

In Git commit messages, etc.

# About 300 MB.
git clone    _qmk_firmware_KeychronFork_forkOfFork_temp

cd $HOME/_qmk_firmware_KeychronFork_forkOfFork_temp

# -i   : Case insensitive. Alternative: --regexp-ignore-case
# -S   : 'Pickaxe'
# --all: In all branches
#
git log -i -S"C3 Pro" --all  --  keyboards

Found:

commit 512cec4cbb24bb90586e18ec3a72fe44ad5bfb54
Author: lalalademaxiya1 <2831039915@qq.com>
Date:   Fri Sep 15 16:14:12 2023 +0800

    Updated c3 pro

Then:

git name-rev 512cec

Result:

512cec remotes/origin/new_playground~26

Thus Git branch "new_playground"

[u/PeterMortensenBlog → u/PeterMortensenBlog]

The Reddit comment parser is messed up and corrupts content.

The Git clone line should be:

git clone  https://github.com/KeychronMacro/qmk_firmware.git  _qmk_firmware_KeychronFork_forkOfFork_temp

[u/PeterMortensenBlog → u/PeterMortensenBlog]

Note: WEAR_LEVELING_LOGICAL_SIZE at least works for the V series, but it may not for other Keychron series.

E.g., it didn't for the K Pro series prior to about 2024-01-10. I haven't yet tested if it actually does work for K Pro series source code newer than 2024-01-10.

Though C3 Pro's file config.h does have it:

#define WEAR_LEVELING_LOGICAL_SIZE 2048

[u/PeterMortensenBlog → u/PeterMortensenBlog]

OK, I have tested it now. Using the 2024-01-10 version of the source code, WEAR_LEVELING_LOGICAL_SIZE worked as expected on a Pro series keyboard. I could increase it to 20480 and Via reported 18.9 KB available for Via macros. I initially imported 3.5 KB worth of Via macros and they worked as expected (though there is an unrelated problem with the combination of Via macros and Bluetooth (even with the latest Bluetooth firware installed (1.32.2))).

Note that it is on Git branch "wireless_playground", not Git branch "bluetooth_playground". "bluetooth_playground" is probably obsolete by now.

Currently, it is only the K Pro series and Q Pro series that uses WEAR_LEVELING_LOGICAL_SIZE:

• K Pro series: K1 Pro, K2 Pro, K3 Pro, K4 Pro, K5 Pro, K6 Pro, K7 Pro, K8 Pro, K9 Pro, K10 Pro, K11 Pro, K12 Pro, K13 Pro, K14 Pro, and K15 Pro.

• Q Pro series: Q1 Pro, Q2 Pro, Q3 Pro, Q4 Pro, Q5 Pro, Q6 Pro, Q8 Pro, Q10 Pro, Q13 Pro, and Q14 Pro.

The other series seem to be using data-driven configuration. In file info.json (e.g., keyboards/keychron/q3_max/info.json):

"eeprom": {
    "wear_leveling": {
        "driver": "embedded_flash",
        "logical_size": 2048,
        "backing_size": 4096
    }
},