Add MIDI controller support

[Hagtronics]

This may well be "out of scope" for you, and if it is please feel free to delete this post. :-)

One really nice feature of piHPSDR is the possibility to use a commercial / custom MIDI keyboard to control the various controls on the software. The dl1ycf fork of piHPSDR went even further by adding improved GUI wrappers around the various functions. MIDI itself is pretty easy in C++ with many libraries available. I got RtMidi going in just an hour on a Raspberry Pi 4, Windows is easy also. I really don't see this applying to Android.

The hard(er) part is making the connection / control matrix so the user can assign MIDI functions to various controls in SDR++.

Thanks for your hard work.

[crackerjacques]

I once used MIDI keyboard dials and faders as shortcut keys to control LED signage.
In other words, it's the kind of thing that could probably be solved with such a utility.

But it's definitely convenient, right☺️
Audio equipment evolved from communication devices, so they share similar control systems.

[dh1tw]

I just did a quick prototype and added a Plugin that allows MIDI devices to control SDR++. I really like it, it improves the useability of SDR++ for practical ham usage. Apart of tuning the VFO and the center frequency I find it particularly useful to have Waterfall Min, Max and Zoom on rotary knobs for quick adjustment.

Unfortunately, implementing this plugin properly, would require some modifications of the SDR++ source code. Some of the variables (e.g. the ones that hold the values of the sliders) are actually private and not exposed. In case Alexandre would accept a few changes, I could create a PR which addes Setter and Getter Methods for some needed Control variables.

[AlexandreRouma]

They are private for good reason. You can't just change the slider value and expect it to update everything properly. Not to mention the thread safety implications.

I left this open for later when the architecture allows it, hacking shit in that "works" but isn't done properly only serves to reach SDRangel levels of stability... (or lack thereof...)

[dh1tw]

I didn't ask to merge prototype code. I'm of course aware that thread safety needs to be ensured. I just wanted to clarify if you would accept a PR that exposes more controls towards plugins before I start investing time in developing a proper implementation.