Velocikey: Match RGB animation speed to typing speed

[chrislewisdev]

Hey all, I've been working on this feature for a little while and think it's just about ready for integration! I haven't really discussed it with the wider QMK community, so I realise that more revisions may be required to make it suitable for merging. That's OK!

Description

Simply put, this feature makes it so that the faster you type, the faster your RGB animations play. You enable it via the VLK_TOG key that toggles it on and off, and then it will control the animation speed regardless of what speed settings you currently are on.

I'd like to add support for the LED Breathing effect, but currently I can't test this myself because my keyboard doesn't have LEDs.

Remarks

Enabled by default

This might be contentious, but I've left the code for this feature on without requiring a compile-time activator such as VLK_ENABLE. This is due to the small memory footprint it has and also that its usage can overlap with other configurable settings like RGB Lights and/or LEDs, which adds more complexity to the configuration.

If you disagree with this decision, I'm more than happy to discuss revisions :)

Coding style

I've followed some of the general conventions evident in the code, but haven't exactly followed the guidelines to a T. I'm happy to make updates for coding style if this is an issue.

[chrislewisdev]

Second time's the charm? 👀

[mechmerlin]

@chrislewisdev I want tooo soo bad, but as of this writing there are still unresolved conversations and Drashna hasn't approved!

[drashna]

Before it gets merged, I'd like to see @jackhumbert or @skullydazed check off on this.

[chrislewisdev]

More merge conflicts fixed, more firmware size issues!

The tetris:default keymap seems to only be sitting about 16 bytes under its limit without my changes, so even just the new eeconfig.c changes push it over, and there's no escaping that.

I think the tetris:default keymap could sit well under the size limit if it didn't include AUDIO_ENABLE in the default config. @YCF could you please consider this?

Unless anyone has other ideas, the only solution I can see is changing tetris:default so it doesn't rest so close to its size limit.

[YCF]

I will update the tetris:default keymap (maybe this weekend),remove the millions of lines of rgblight_setrgb_at().

code:

for (i=0;i<47;i++){
       (i>45)?(j=i-1):(j=i);
	   uint16_t kc =keymap_key_to_keycode(layer, (keypos_t){ .row = 0, .col = i });
	   if (kc == KC_TRNS) {
	     setrgb(64, 64, 64,(LED_TYPE *)&led[j]);/* TRNS
	   }else if (kc == KC_NO) {
		 setrgb(0, 0, 0,(LED_TYPE *)&led[j]);   /* NO
	   }else {
		 setrgb(1, 2, 3,(LED_TYPE *)&led[j]);   /*  KEYS
	   }

Please help me disable the AUDIO of the tetris.

Thanks.

@chrislewisdev

[chrislewisdev]

Thanks so much for the prompt reply @YCF, I really appreciate it!

If you change keyboards\tetris\rules.mk line 56 to AUDIO_ENABLE = no, it frees up a few thousand bytes of firmware space which should prevent any size issues from new functionality like this for the foreseeable future, and would help me get this PR over the line.

From what I see in keyboards\tetris\keymaps\default\keymap.c, it looks like audio is set up as an optional feature, so I assume that disabling it in the default keymap would prevent my current issue while also allowing anyone who wants to use it to easily configure it :)

I'll be back online tomorrow if you'd like any further input.

[drashna]

@chrislewisdev Actually, I'd rather see the changes to the Tetris keyboard in a separate PR. that way, it can get merged sooner rather than later.

Also, we generally don't want PRs that affect both keyboards and core code (as a guideline).
And there are other PRs that that this affects too.

[chrislewisdev]

Sure thing @drashna, new PR is #5197

[mechmerlin]

Woohoo thanks!

[drashna]

@chrislewisdev any chance you'd be willing to adapt this to the rgb matrix code?

[chrislewisdev]

@drashna I'm not terribly familiar with how RGB matrix works nor do I have anything to test it with, however I'm happy to help advise in adapting it and provide reviews for any changes!

From a quick glance at rgb_matrix.c, it looks like the speed of change in matrix effects is largely driven by the g_tick global which is incremented by one every tick. One method to make it go faster using Velocikey could be to use g_tick += velocikey_match_speed(1, 5) instead of g_tick++, but I'm not sure how that would look in practice.

With a little experimentation and tweaking, I'm sure it can work, so keep me in the loop if anyone picks it up and feel free to hit me up for more discussion!