Open Petorrrrr opened 3 years ago
Hi @Petorrrrr, thanks for your kind words and your interest in the MIDIMonster! Very happy to hear that you like the tool :)
As you've correctly determined, the API gives more information on the faders than is currently used. Due to the internal construction of the MIDIMonster, it is currently only able to work with absolute numeric values (and relative numeric values in some special cases).
So while accessing information on whether a given fader is free or not would be possible, processing the fader name is currently not within the scope of the MIDIMonster. See issue #41 for some more discussion on additional channel types such as this.
The advanced processing steps (such as sending different values based on whether the fader is free) would need to be done in one of the programming backends, as I would very much like to keep the MIDIMonster core free of concrete assumptions (also known as "magic values") about specific devices. One device might, for example, use MIDI value "20" as "25% green led", while another one might use that as "blink as brightly as you can". All in all, I find it is best to strive to make this tool as generically usable as possible, which does carry it's own problem in being more complex and scary to understand to newcomers, but ultimately provides more flexibility.
As for the build environment, I do all work on Linux and so the environment is set up for that. Additionally, automating builds on Windows is not straightforward, and so cross-building for Windows on Linux was just the path of least resistance. It should be possible to use the Makefile to recreate something that will build with visual studio, as the build steps are very similar to most C projects (build object files from the core source files, build "midimonster.exe" from those, then build shared objects for each .c/.h pair in backends/
).
If you want to try building on a Linux VM, you can set up a basic Debian installation, run
apt-get install build-essential pkg-config git libasound2-dev libevdev-dev liblua5.3-dev libola-dev libjack-jackd2-dev libssl-dev python3-dev mingw-w64
as root to install the dependencies and the clone the project with
git clone https://github.com/cbdevnet/midimonster
After that, entering the directory and running make windows
will build the Windows port.
I planned to make a video to show how to do this some time ago, I might do that at some point yet :) If I find the time over the Weekend, I'll at least add a knowledge base article on building :)
Thanks for your response.
It makes perfect sense why it can't handle anything other than numeric values right now. Though unfortunate, obviously ;)
I will take a look if I can get it to build on a VM. Really appreciate the instructions. But even if I get it working, helping out on implementing non-numberical values in the core of midimonster to be able to pass might be a bridge (or two) too far for me.
I'll keep an eye out for updates in the future. Thanks again for your hard work and making it publicly available!
Hi @Petorrrrr,
I have started work on a "Building" guide over at the knowledge base: https://kb.midimonster.net/dev/Building.html Maybe it'll help clear up some questions about the build process :)
Hello! Thank you for creating this wonderful peace of software! I have been using it happily for some days to control a dot2 onpc together with touchOSC on a tablet.
Before I used midimonster, I was walking a different route, based on this nodejs solution to retrieve information from the dot2: https://github.com/ArtGateOne/dot2apcmini
I was able to tweak it (I have only very limited coding experience) so that it not only retrieved the executor values (both buttons and faders), but I was also able to retrieve the text of the executors. I got it working, but for me, it's not stable enough. With midimonster it is a lot more stable, but I think it could be a nice addition to also retrieve the executor text.
Perhaps it would be even possible to take it one step further and also retrieve more information of the executors. It seems in the json retrieved from the webclient, there is also information to see if a executor is free or not and the fader value (especially interesting when you assign a speedmaster to a fader).
In OSC it's possible to work with strings, therefore it can dynamically show the name (and value) of the executors. Especially when you have 48 executor buttons, it's nice to see on the touchscreen the name of the executor. For backends which cannot work with strings, you could perhaps send out some value to reflect the availability of an executor. I can think of an example where you'd want a led on a midi controller to be off when the executor is available, to be a certain color, or brightness 25% when it's not available, but not active and another color or brightness 100% when not available and active.
I hope it make sense. If not let me know.
On a side note: I'd love to try some stuff out myself, but I'm not experienced with setting up a build/develop environment for this. I use visual studio code on windows, but I don't know how to set it up so that it can build or debug. Based on the documentation I think that isn't even possible at all. I can setup a linux VM, but where to go from there. Is there perhaps a reference to a general starting guide that someone can point me to to set it up?