To be fair, I hadn't seen in my 1st reading that Ultros gave my user name when mentioning the image maker.
I would have preferred a clear and explicit link to the Github site covering all the stuff Ultros used..
For me the subject is closed whoever it is.
So, Let's go back to the substantive topic : what to do with a Force binary running on a MPC One ?
1/ when the Force (or a MPC) starts, it sends an identity request (it is a universal sysex), so the software knows you are not using a Force
2/ To change color of pads, the Force software sends specific sysex sequences not compatible with those of the MPC. But pressing a pad will send the appropriate "note on"
3/ You haven't all the buttons you need to use the Force software, and the "Main" button is inoperant.
4/ Qlinks works on the first group. Nothing on group 2-4
5/ Plugins and effects are embedded in the binary : so no way to activate them even if you see some config files, skins, or presets.
So it is not possible to activate a plugin because the code is simply not here ! The plugin management is totally proprietary...
So for sure, it is "fun" to see the Force app running on a One,a X or a Live, but no real usage in fact. So no need to update your MPC with that.
I also worked on a customer controller that could emulate a Force or a MPC controller, so I could mutate my MPC Live in a Force (I also own a X). I have written a specific library that creates Alsa virtual ports and connects them to the ports of my choice before launching the MPC binary. I'm able now to emulate any button, qlink, or pad of a Force or MPC, and receive and interpret the sysex I was talking about above.
One use case of that is on the Force. It has no "controller mode" as the MPC has. With that special lib, I could bring this "control" mode by allowing mapping with an external midi controller. I'm here...
You have a detailed description of that on the MPC reverse engineering site I mentioned above.