I understand it is not easy without any starting point.
To get a starting point, it is probably worth doing one or a few of the tutorials
To learn about where the audio thread is working, maybe that post I wrote a while back helps a bit:
About your questions about MidiKeyboardComponent:
This is a software keyboard that your app can display. It needs a corresponding MidiKeyboardState. The reason why that is not in one class is, because in a plugin you have an AudioProcessor, that is always present, and a GUI called AudioProcessorEditor, that may or may not be present. To know, which key is pressed, the MidiKeyboardState has to observe the stream of noteOn and noteOff events. Otherwise, if you open the editor while a midi note is playing, it couln’t display that.
Any class called FooListener or Foo::Listener is an interface to register for notifications. In the case of MidiKeyboardState::Listener you can add yourself as listener to a state and get a call, if a noteOn or a noteOff or other things happen, that you can see in the API docs of that Listener
The MidiInputCallback is indeed listening directly to the port and should not be used in a plugin. The reason is, it collides with the host’s routing and second, the data will not be timestamped and therefore not synchronous with the timeline of your DAW.
Something that probably makes is additionally hard is, what parts are actually under control of a plugin, and what is the host’s responsibility. Recording audio and midi events is what the host is doing.
Before I write a whole book, maybe you could already get an idea, otherwise just keep asking…
And sometimes it takes a few hours until someone comes back with an idea how to help you, have a little patience 