Macros on UHK are quite easily the best the planet has to offer, which is why the 32Kb limit on the board is oh so painful! The UHK 80 is tempting but it’s just so hard to improve over the v2, I’m curious if the 80 has more flash storage for more macros??? If not, wondering if there’s some way to substitute the board while keeping UHK Agent happy or otherwise v3 even just going to 64 Kb is a hard sale on my end!
Keep up the great work and I’ll be able to meet my maker without ever needing a neuralink installed.
Thanks for checking! Told myself I might have a problem if I ever sacrifice all per key colors and still run out of macro space, I definitely have a problem.
The UHK 80 currently exposes the same 32K configuration space as the UHK 60. We may extend the UHK 80 configuration space eventually because we have some leeway, but given the ~0.1% of users who run out of flash space, it’s questionable whether the effort is worth it.
It’s a fair argument. I have 5 layers across 3 keymaps and deep macro scripts for terminal CLIs and programming languages, so even pretty condensed scripting adds up quickly, niche to be sure. If it’s just a “change this constant in code” thing I’d be tempted to build the FW+Agent myself on a fresh 80. You’d at least make >= 2 sales if it works ha.
Thanks and by my count 3 years as undisturbed best keyboard of Earth.
It sounds like a quick win for users to recover space could be for us to delete unused keymaps. I dont use Colemac, for example. @maexxx, do you know if this will work?
Deleting unused keymaps and layers will definitely save sognificant amount of space, especially if per key rgb is enabled.
(We plan to implement an optimization to reduce the amount of space occupied by sparsely populated layers, but we have more pressing matter these days…)
As for increasing the config size, we are short on RAM.
For uhk80 it may or may not be as easy as changing a constant - I doubt that uhk80 will fit into 128kb, but it might.
Otherwise there are these things can theoretically be done, but are technically nontrivial:
refactoring the firmware so that it uses only one config buffer instead of two. Then the saved space could either be used for new features, or for increasing config size.
compiling macros into bytecode on the firmware size, so that only the byte ode is held in RAM; This would also speed up macro execution a lot
compiling macros into bytecode agent side.
Unfortunately considering available development time, priorities and rate at which new issues spawn, I don’t expect I will ever get to it .
I was almost going to suggest the 2nd in the lazy form of, give me iKA in addition to ifKeyActive, but yeah sounds like compiling to bytecode is even better.
This is what happens when you make a nice Turing complete scripting language people like us will abuse it
Iirc, current named variables do not support indirect access, which means that the only way to access something that resembles an infinite tape is to pretend that variables can store arbitrarily large numbers and perform arithmetics to store (arbitrarily many pieces of) information there.
While feasible, it is also very impractical.
We don’t even support local variables and argument passing to macro calls…
Which means that unless we resort to the above abuse, the strength of the language is even below a push down automaton . (Arithmetics can be used to implement some push down automatons, but not all.)
(Also sorry, I just don’t know how to accept a compliment .)
Honestly reading about people running out of space makes me feel FOMO as if I’m not making the best out of the keyboard. But even layers beyond Fn & Mod are way more than what I seem to need.
.
. (Arithmetics can be used to implement some push down automatons, but not all.)
.)
)
I added some infinite tape to my UHK right now tho just to make you wrong again.