Closed Adib-C closed 2 months ago
Not with the way Deej communicates with the host app. Only slider positions are sent, and there's no media control functionality.
I understand, but it would be nice if this feature gets added to deej though 😊
i second this, although it would like expand it to general media buttons such as end call, stop & skip song, and mute for the different sliders
The main repo is mostly abandoned, but there are many forks of Deej with extensive changes: https://github.com/Miodec/deej
This one adds the keybd_event library for configurable button mapping.
Aah I see, I didn't know this is mostly abandoned , thanks for letting me know, and I will check out other forks.
Aah I see, I didn't know this is mostly abandoned , thanks for letting me know, and I will check out other forks.
Hi there.
I was facing the same issue before I decided to Fork this amazing (but abandoned) project myself as plenty other did. It is unfortunate that we cannot consolidate features into one single repo which should be the goal of github instead of having hundreds of tiny mods all over the place.
It is indeed very possible to have touch buttons, hardwired, capacitive or anything you want. You can checkout the code on my repo I have implemented such a possibility in the Go portion of the project, along with various interesting mods I have gathered around. I am working on Linux so not sure yet if the code properly deploys on Windows. There might be some sticky bits with one architecture or another such as key mappings different in these systems for some functions, but with proper testing it should all be solvable quite easily.
Also if you want some specific features don't hesitate to make a pull request, I will try to do my best to implement it.
Keep in mind that Arduino while a great tool for starters and also because of its decent ADC chip, seems quite a bit outdated compared to current possibilities offered by various MCU devboards. Arduino is not much simpler than other MCU as long as you have a good grasp on C++.
Keep in mind that while my code is in a working state (I have it running for several weeks now), it needs some cleanup as I used to be totally new to Go Language apart from compiling Loki Docker driver for a Raspberry Pi once in a while. Also you will have to modify your Arduino code but it is quite simple. Let me know if you need some tips.
The architecture of this project code is dual. One part is in Go and purely deals with the server side and does all the interfacing with the sound backend. It is by far the most remarkable piece of software of the project. The other part is the client side which is by default a simple Arduino script. There are millions of possibilities with such an architecture. Some people hardwired their switch to pulldown the fader (ghetto style),, but you can go as far as you like. At the moment I have implemented software defined fader curve and it allows you to tweak the response of any fader you have in your build.
I intend to refactor the server code for good once I have my hardware complete with all the features I want to implement. I will update my repo with all information soon.
Hi there @Adib-C, @neroes, @TheScabbage and @Lefuneste83 - thank you for writing.
First and foremost please let me address the primary subject of this issue - media controls (and more broadly, key bindings). They're something I consider to be out-of-scope for the vanilla version of deej at this point in time. I might opt to add them in a future release, but until then - as mentioned above there are forks with support for this functionality and I encourage you to use those forks instead.
I'd like to also take the time to address the above comments regarding the project's state and to clarify - deej is not an abandoned project. The notion that it's abandoned is honestly quite preposterous to me. A project not receiving issue comments from its maintainer for a few weeks doesn't make it abandoned - nor that it hadn't had pushed commits in an admittedly long time, and thirdly nor that it has a non-standard contribution policy.
Let's talk about that third point briefly - specifically to address this comment:
It is unfortunate that we cannot consolidate features into one single repo which should be the goal of github
Well, yes but not really. GitHub is a collaborative platform, but on the other hand - open-source can mean a wide range of things and its most basic definition is "the source code is freely available". It doesn't necessarily imply open collaboration. The reasons I outlined in my above document (for not wanting to receive direct contributions to this main repository) have not changed since that document was written.
The notion of "consolidating features into a single repo" sounds like a wonderful thing, but the nature of how customizable and how personalized this project can be simply means that there is no sane way to support and maintain the large amount of features thought up by the thousands of users within the deej community - all in one place. I see the existence of hundreds of different forks which accomplish different features - some with broad appeal and some extremely niche - as a good thing, in spite of their discoverability leaving a lot to be desired.
Finally, I'd like to point out a couple of other things that should (in my opinion) signal that deej is nowhere near being at an abandoned state:
If you'd like to continue the discussion on the project's state, I encourage you to DM me through the project's Discord server; I realize this response is very defensive, it's just difficult for me to see the "abandoned" term being thrown around in this manner - deej is extremely dear to me and so it was important for me to take the time and clear up my own point-of-view. If you took the time to read through all of this - thank you.
Is it possible to send a Play/Pause command to deej when pressing a button connected to the Arduino?