Hi Julia. This problem is due to Xojo's “cooperative threading model”. They’ve said on the forums that they aren’t going to change it, so we’re stuck with it.
So the only way around this problem using Xojo is to handle MIDI input in a helper MIDI app which communicates with a GUI app using sockets. I’ve done it and it works. Unfortunately working this way brings in a host of other problems. It taxes the processor more heavily, and is a nightmare for debugging. The apps have to keep tabs on each other to handle exceptions. Also keep in mind that such “multi-apps” won’t work on the Mac App Store. Apple has something called XPC-Services which are supposed to allow one to do this same kind of thing within one app, and MBS has some functions for it, but despite my efforts I never got them to do anything, so I gave up on it. I need things to be cross-platform anyway, so using an Apple-only solution is not good enough. Conclusion: realtime audio is doable using a multiple app model, but it’s far from ideal. Until Xojo drops its “cooperative threading model”, it will remain a poor choice for making realtime audio apps. I say that with regret, because I’ve used Xojo forever and otherwise I love it. Cheers, Aaron On 28Dec 2017, at 12:00, mbsplugins-requ...@monkeybreadsoftware.info wrote: > 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
