I have a longstanding problem in my MIDI apps, which is that UI activities like dragging a window cause MIDI communication to stop. My apps use almost exclusively the sysex filedump message protocol, where each packet must be ACKed by the receiver. I use the Audio plugin for Windows MIDI classes and the MacOSXCF plugin for Mac MIDI classes.
I can put the code that handles messaging into a thread, but that doesn’t solve the problem, because the low-level MIDI stuff is still blocked. I don’t know if the code in these plugins runs in their own thread(s) or not, and if not, I don’t know how to do it. Under Windows, WindowsMIDIInputMBS.Idle is called by a timer event, and from what I’ve read, timers can be blocked by the main thread under some circumstances. It looks like Garth H. has struggled with the same problem (although he’s using Port MIDI): https://forum.xojo.com/15504-heavy-timer-in-separate-thread-or-main-thread I was also thinking along the same lines as Garth, which is to use a loop in a thread with thread.sleep to fire WindowsMIDIInputMBS.Idle instead of a timer, but I think that that still wouldn't put my message-handling code that’s in the WindowsMIDIInputMBS.DeviceLongData event handler into a thread, so it won’t solve the problem. One of the more interesting proposals in the forum thread is that of a faceless helper application that runs entirely separately, maybe I’ll look into that more closely unless anyone has a better idea. Garth, did you ever solve the problem? I hate having to tell my users “Don’t click on anything while the program is running”, it’s really unprofessional :( Thanks, Julia _______________________________________________ Mbsplugins_monkeybreadsoftware.info mailing list mbsplugins@monkeybreadsoftware.info https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info
