I am currently trying to write an application that sends sysex messages over a virtual MIDI port in order to remotely control a digital audio workstation (FL Studio) via its isolated Python scripting environment.
My project is designed as follows:
- The client contains code for connecting to a MIDI port, and sending messages to the server.
- The server is a separate Python program specifically written to be run within FL Studio's isolated environment. It decodes the messages, executes the required commands, and then returns the results.
- Since Windows doesn't natively support loopback ports, the user must create the virtual MIDI port using a tool such as loopMIDI.
- When the client is started, it connects to the input and output MIDI ports of this virtual MIDI device. It then repeatedly sends a "hello" message until it receives a response from the server running within FL Studio.
- After receiving this response, it performs some setup operations on FL Studio's Python environment before handing control to the user or calling library.
The full code for the project is on GitHub, but I don't believe that my code is specifically the problem. Instead, I think that this more likely to be an issue with my overall design that is causing this problem.
The issue I am encountering is that after a certain number of messages have been sent to FL Studio, it stops responding, and freezes.
I do not believe this is an issue with loopMIDI, as I have also managed to reproduce the issue when using an alternative LoopBe1.
I have discussed this issue with the developers of FL Studio, and they are stumped on the cause, although they did inform me that their call to midiInAddBuffer from mmeapi.h never returns, which triggers the application freezing.
Image-Line suspect that this is due to the sysex buffer being full, but this doesn't seem right, since my client has no trouble keeping up with incoming messages - it just stops receiving responses from FL Studio. Given that neither mido nor python-rtmidi have a function for clearing the buffer of incoming events, I presume that the buffer is automatically drained as incoming messages are processed.
In the replies to this question, Stevens Miller suggested that midiInAddBuffer could deadlock under some circumstances. I believe that this could be the issue, although I don't believe that the cause is the same as the callback function, since Image-Line tell me this isn't how their program is designed. Note that since FL Studio is proprietary, I cannot check for myself.
Instead, I believe that the issue could stem from the way that my application accesses the virtual MIDI port. As mentioned earlier, when my application connects to the MIDI port, it connects to both the input and output. FL Studio also connects to the same input and output. As such, when they communicate, I use event filtering such that the server and client don't react to their own messages. This means that when an event is sent through the virtual MIDI port's input, it is received by both the client and the server on the output, and both the client and server send messages through the same input.
As such, my theory is that having two applications (my client and FL Studio) connected to the same MIDI port is the cause of this deadlock, although I am not sure what the specific cause is.
As such, my questions are:
- Is having two applications connected to the same MIDI port in Windows likely to cause a deadlock?
- If not, what could be the cause of this freeze?
- If so, how else can I accomplish my goal of connecting to FL Studio over a virtual MIDI port such that I get two-way communication between my client and server?
Solutions that don't involve multiple MIDI ports are preferred, since the process of linking a MIDI Controller Script to receive from multiple ports in FL Studio is a little challenging, so would make my project, and any software based on it, more difficult and tedious to set up.
Thanks, and let me know if there is anything else I can clarify.