[BUG]: Design of midi1monitor.exe causes dropped incoming messages

[Psychlist1972]

midi1monitor doesn't use a good approach for receiving and displaying messages. Instead, it should use something similar to midi.exe where receive is into a queue that is processed on a display thread. As a result of this design, there are dropped incoming messages.

Reference this bug and comment:
#362 (comment)

Quote from @m-komo :

---

I have done the testing and confirmed that dropped messages were found only under the following three scenarios:

• Scenario 3a - 1 first-party WinMM client
• Scenario 3b - 2 first-party WinMM clients
• Scenario 4b - Mixed 2

In all cases, the issue appears only when using midi1monitor.exe.
In addition, if I redirect the output of midi1monitor.exe to a file, no dropped message is found.

This suggests that the issue is related to how midi1monitor.exe handles received messages. The app displays received messages within the incoming callback. It should be avoided.
I.e., applications that are properly implemented and avoid heavy processing in the callback may not cause this issue.

Thanks to improvements in the driver, proper handshaking with the device is now in place, and the issue of missing received data seems to be resolved.

We are now focusing on evaluating overall throughput from the device to the app, through the MIDI service. This will be covered separately.

---