Skip to content

MacroPad helper library. #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jul 12, 2021
Merged

MacroPad helper library. #1

merged 5 commits into from
Jul 12, 2021

Conversation

kattni
Copy link
Contributor

@kattni kattni commented Jul 12, 2021

No description provided.

@kattni kattni requested a review from a team July 12, 2021 15:48
@jedgarpark
Copy link

Works great! I tested with the Macrodad MIDI Tester code I'm working on. This includes pixels, display text, key events, encoder switch debounced, encoder, and all of the MIDI sends.

@ladyada ladyada merged commit 4f0e7a3 into adafruit:main Jul 12, 2021
@PaintYourDragon
Copy link

Some notes on this with the Macropad_Hotkeys code:

Library inits NeoPixels to brightness=0.5 and auto_write=True, project code relies on 1.0 default for former and sets auto_write=False when declaring pixels … either those arguments could be passed into Macropad() and through to the NeoPixel constructor, or the project code can set the two values manually after the fact.

Project code relies on the keypad library to debounce the encoder button “free,” requires no extra import and it generates events in the same manner as the keys rather than handling it distinctly (each of the example configs assigns some macro to the button … the revised code, using the Macropad lib, now misses these). Could either make Macropad lib treat encoder as 13th button, or project code can be modified to discretely poll and act on the encoder switch.

Project code is also pulling a shenanigan of declaring 13 rather than 12 NeoPixels, so the same code can handle key press/release (with pixel) and encoder press/release (no physical pixel, but it writes data that’s off the end), and also just uses the 13th element of the 'macros' array that it imports. Same deal, lib or project code could go one way or other. But, if it’s the project code, this kind of undoes the “library to make the project code smaller” since the project code now needs extra stuff to handle this.

Key rotation is neat but skimming the code it seems to be incomplete … it’s rotating the keys but not the NeoPixels, indices won’t match up in rotated states, making it difficult to set the pixel corresponding to the key. The pre-rotated tables of key pins are speed-efficient, but to handle both I wonder if it’s better to always declare the key pins in the “upright” rotation and then change these to remapping tables and provide setters/getters for both the keys and pixels. Except then I don’t think this’ll work with events.get(), so maybe you need both the key pin tables AND remapping/setter/getter for the NeoPixels. I don’t know. Is this rotation thing really just trading one problem for another?

@jedgarpark jedgarpark self-assigned this Jul 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants