Nick Conway

> If there is a memory hard limit that can be determined per processor, or an overall safe limit, it might be worth adding that because when going over the...

> Hi, I tried the feature and, although I like it, I would like to share some feedback: > > * I believe the recording should also capture the time...

> > Hi, I tried the feature and, although I like it, I would like to share some feedback: > > > > * I believe the recording should also...

> * The no-op suggestion was about hitting play while the _playback_ of a macro is ongoing (not the recording). The one implemented indeed seems like a welcome bug-fix, but...

> I don't love the code duplication between the parameterized version and not, but the amount duplicated is so minimal, I'd say it's fine. We could the duplicated code to...

@petejohanson done.

> Thought I'd weigh in here. The `each` keyword sounds the most correct for this application since the word,`every`, could be interpreted that it invokes all keybinds at once, or...

> About the "tri-state" naming: It might be confusable with the "tri-layer" (`lower+raise = adjust`) [pattern](https://docs.qmk.fm/#/ref_functions?id=olkb-tri-layers) that we support with [conditional layers](https://zmk.dev/docs/features/conditional-layers). Maybe three-phase would be better, or would 'triplex'...

@petejohanson Apologies for the delay. I think the bookend name is much better. As for the behavior queue, my understanding was that the keymap_* functions would be used here since...

I have some starter code for this and I plan on working on it more when I get some free time. I'd love some help with it if you're familiar...