We should also think about whether or not the driver code should actually run as part of the main JUCE code or as it's own thing managed by systemd or something like that. I think I'm leaning towards treating the driver code as it's own thing outside of the main JUCE code. This could simplify things a lot.
Basic Idea
We need to make a driver that talks to our GPIO pins and turns them into MIDI CC messages which will be sent to JUCE.
The main priorities are:
GPIO Header Info:
https://www.libre.computer/blogs/gpio-headers-reference-for-aml-s905x-cc/
(source)
Example Code?
Reading a rotary encoder in C++ might be as simple as this:
(Untested code generated by GPT4)
The key thing here is the wiringPi library. If we can get that running I think we have a good starting point to do a lot of what we will need.
wiringPI website
Should Drivers Run Standalone?
We should also think about whether or not the driver code should actually run as part of the main JUCE code or as it's own thing managed by systemd or something like that. I think I'm leaning towards treating the driver code as it's own thing outside of the main JUCE code. This could simplify things a lot.