[Feature Questions] RGB Reactive effects

[lvisintini]

Hi there:

I'm interested in contributing some work in the RGB effects area, in particular reactive effects.

It seems that to me that any reactive effect a way to determine which key switch to react to in such a way that:

• It is defined (row, col) pairs instead of key codes.
• It needs to take into consideration denouncing.
• It needs to have a timestamp (perhaps 2, one for pressing and another for releasing)

Furthermore, this would need contained within a queue of the last n keystrokes, so that effects can last and continue to evolve for some time after the key stroke.

Could you provide some guidance as to how would you think this feature should be implemented in the codebase

[jpconstantineau]

Hi,

I would appreciate your contribution to the code base.

Here is how I would approach this:

• Convert LEDRGB.h/cpp into a class. This class will manage the queue of events.
• Create press and release methods for "RGB". It should use the same inputs as KeyScanner::press and KeyScanner::release (already includes a timestamp)
• Debouncing is already done before KeyScanner::press and KeyScanner::release are called. (firmware_main.cpp line 341)

Similarly to how CircuitPython has defined key numbers for every row/column positions, see docs, each row/column should have a representative key number.

You will also need to have a configuration function to enable mapping between key number and RGB Led number. This will be needed for keyboards with RGB not following up the same order or boards with gaps in the matrix. Default should be a 1:1 mapping but the user will be able to call that function from their keymap.cpp setup file.

By wrapping it up into a class, it will be easier to separate and test. I have been slowly migrating everything to classes for that reason.

As you will see in LedRGB.cpp, many of the modes have placeholders only and haven't been implemented. This has been a low priority for me as I don't have any full RGB keyboard to develop and test with. Feel free to add to them as well. This could be a good starting point to get familiar with what's currently there.

What keyboard do you have and what controller do you use? Is it a full keyboard or a split?

[lvisintini]

I currently don't have any hardware to test any code.
I'm working on a hand-wired dactyl manuform and I'm waiting for nice! nanos to go back in stock at the end of September.

I may start writing some code before then but I wont be pushing a PR before October.

[jpconstantineau]

You could go with BlueMicro840s with external Antennas. They are slightly wider than the nicenanos but are available right now...
https://www.tindie.com/products/jpconstantineau/bluemicro840/

To test the algorithms, you can also develop them in CircuitPython. Both the BlueMicro840 and Nicenano can run this language and it's much faster to develop on. Once the algorithms are set, it would be easy to copy them in C++ and merge them into the code.

[jpconstantineau]

Did you end up with some hardware?
I am planning to bring support for the RP2040 to this firmware and I have several keyboards with per-key RGB that could use this...

[lvisintini]

Yeap. I finished up doing the hardware bit and I was testing out with circuit python. Obviously not ready yet, but I can share that with you next time in front of my laptop for you to review

…

On Thu, 27 Jan 2022, 00:11 Pierre Constantineau, ***@***.***> wrote: Did you end up with some hardware? I am planning to bring support for the RP2040 to this firmware and I have several keyboards with per-key RGB that could use this... — Reply to this email directly, view it on GitHub <#248 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAY5TOOR4G3SWDM5EEAC463UYCERXANCNFSM5DDXC6PA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[lvisintini]

Hi there @jpconstantineau
I think I'm finished for now with the prototype I was working on.

It implements a RGB controller class that handles most of the setup for the RGB matrix in a bunch of other things.
Then, each RGB effect has also its own class that makes use of the above controller to handle the effects.

I had to create a mock of the bluemicro firmware to have some level of structure, but most of that code can be disregarded.

The only assumption made for reactive effects is that we are able to get the last time the key was pressed for each key and that we are also able to tell if the key is currently pressed. (using key numbers here.... so this is regardless of layer or keycode)

I did not implement a press/release method for the RGB controller because I did not see how I could make use of use, though this may be due to inaccuracies in the way I chose to mock the firmware.

Happy to upload a video of the prototype in action on my own keyboard, but only if you feel you need to see it.

You can review the code on this repo -> https://github.com/lvisintini/keyboard-rgb-circuitpython-proto

Let me know what you think

Cheers