Configurable Firmware about deej HOT 2 CLOSED

* "does the user's config file require any knowledge about pin numbers?" - if the answer is "yes", it's too complex to put in the hands of users who e.g. receive deej as a nicely wrapped gift.

This is a really good point. I assumed the users are involved with the soldering of the project, and they would understand where the pins were on the board.

My first thought is that maybe the configuration could be layered into a hardware abstraction layer and an application layer. The hardware layer would set up slider3 and then the application layer would look a lot the same, with the config associating slider3 with the master volume.

I think we could also create good ways to handle hardware customizations we haven't thought of. By creating a well defined serial layer, which includes specific ls for custom components, makes it easier to edit, not harder. Inevitably, someone will make an led ring and someone else will have a wheel encoder and then a third person will want both. Keeping the pin assignments on the software/golang side just makes it much easier to change. But it could also be handled in the firmware. I cringe thinking that each user is making their own serial protocol and has to reinvent new customizations.

And I'm not offended at all. I really appreciate the honestly and if I sound ungrateful or critical, understand that I am just trying to express my point clearly and quickly. No worries.

from deej.

Hi there @jeffeb3, thank you for your incredibly detailed write-up! I'm happy to hear you like deej.

I share a lot of the same sentiments with regard to users being able to extend the project and take full advantage of the hardware they're building with, however I do think that the way there needs to look differently. There are several main reasons in play here:

• Simplicity above all else: one core reason that the project got to where it is, IMO, is how simple it is to assemble and configure it (even if you're a complete Arduino or electronics beginner - just like I was when I started it). It is crucial to maintain that. I would say a good rule of thumb is: "does the user's config file require any knowledge about pin numbers?" - if the answer is "yes", it's too complex to put in the hands of users who e.g. receive deej as a nicely wrapped gift.
• Customizability should be trivial when possible. If users need to learn the intricacies of the serial protocol to take advantage of custom features (even if they're exposed via config - which is also somewhat tricky to teach users, even if it's simple), it has the risk of feeling like a step backwards from simply adding a few lines to your Arduino code to e.g. achieve a mute toggle or color an LED ring.
• Similarly to the config, the serial protocol shouldn't be aware of pin numbers. Communication between the client and the firmware should happen with application-level semantics: "Slider 3 reads 765", "Button 1 has been pushed", "Display X should display icon Y". This is valuable for easier troubleshooting, but of course requires the firmware to be aware of these application-level concepts.

I do have a distant future plan for supporting a similar kind of extensibility in a different manner. My plan is to take advantage of code generation to build a custom firmware for the user's desired set of hardware features as selected during set-up. For example, the user would indicate that they have 5 sliders, 4 buttons and an LED ring. deej's setup would then generate a flashable firmware that supports these specific features, with pin numbers either being set manually by the user or suggested by deej, also depending on the user's choice.

This is still very far down the list of things I'm planning to add. With that being said, I have a shorter-term plan to add infrastructure-level support for handling button presses over deej's serial protocol. This would allow users to easily bind buttons to several different triggers from deej's config file. These will include triggering a keyboard shortcut, running an executable, software-muting a slider, etc. Further down the line, this can be expanded to allow advanced triggers such as making an HTTP request or even running custom Go code (via Golang's plugin system).

Here's where I might (understandably) disappoint you: I'm extremely passionate about my vision for the project and its future, but it is something I do in my free time and ultimately I would prefer to work on all of these major things by myself. I appreciate that you've put a lot of thought into your proposal, and I strongly encourage you to explore it in a fork if you're excited to do so.

I'd like to take this opportunity to sincerely apologize if this response at all strikes you as dismissive, or otherwise leaves any sort of bad taste. It is definitely not my intention. In the coming weeks, I intend to add more details about the project's development and scope to a ROADMAP file. I hope this will help people who find themselves in a similar situation down the line to manage their expectations.

I look forward to hearing your thoughts about any of the things we touched on here, and please also feel free to reach out privately to me via the project's Discord server if you prefer that.

from deej.