bandominedoni same note fix

[3araht]

Description

An issue with multiple same notes played at the same time is fixed.
(This version requires #20179 to be implemented to use an encoder correctly.)

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[elpekenin]

Not on the computer right now, so cant really check to confirm it... Changes to move information into data driven (read: info.json) are most likely done on the develop branch already, thus would lead to conflicts when develop gets merged on master, changes to the keyboard's code should target develop

Also, there seems to be quite some duplication (eg the custom keycodes across several keymaps), which should be moved to keyboard-level (and use QK_KB instead of SAFE_RANGE)

[3araht]

Not on the computer right now, so cant really check to confirm it... Changes to move information into data driven (read: info.json) are most likely done on the develop branch already, thus would lead to conflicts when develop gets merged on master, changes to the keyboard's code should target develop

Also, there seems to be quite some duplication (eg the custom keycodes across several keymaps), which should be moved to keyboard-level (and use QK_KB instead of SAFE_RANGE)

I made a branch from a develop branch and applied all the modifications done here to avoid conflicts.
I'd like to send a pull request to a develop branch, but I mistakenly pull-requested the whole develop branch to master.
Maybe I should wait for the next breaking change so that I can send a pull request as usual.

[elpekenin]

On my computer now, so i could take a closer look:

1. Indeed, the changes to move stuff into the JSON file are already done in https://github.com/qmk/qmk_firmware/blob/develop/keyboards/bandominedoni/info.json, so you should not make such thing on a PR to master
2. As i said a few hours ago, you have tons of duplication across files (defining a lot of custom keycodes and their behaviour, on each of the keymap.c files), that should be moved to bandominedoni.c using process_record_kb (remember to call the user variant from there):

bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
    if (!process_record_user(keycode, record) {
        return false;
    }

    // your code
}

[3araht]

On my computer now, so i could take a closer look:

1. Indeed, the changes to move stuff into the JSON file are already done in https://github.com/qmk/qmk_firmware/blob/develop/keyboards/bandominedoni/info.json, so you should not make such thing on a PR to master
2. As i said a few hours ago, you have tons of duplication across files (defining a lot of custom keycodes and their behaviour, on each of the keymap.c files), that should be moved to bandominedoni.c using process_record_kb (remember to call the user variant from there):

bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
    if (!process_record_user(keycode, record) {
        return false;
    }

    // your code
}

Oh, I see. I moved some Macro definitions and functions to there but I didn't modify process_record_kb() yet.
I'll do that.

[zvecr]

You only get 64 keyboard level keycodes https://github.com/qmk/qmk_firmware/blob/master/data/constants/keycodes/keycodes_0.0.2.hjson#L6, and can count 75 which would be invalid.

[3araht]

Uh, oh…
I can’t use QK_USER in the KB level, can I?

BYW, Thanks for changing the base branch to develop.

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.