Menu

#9 Deadlock in UI/MIDI input handling.

v1.0 (example)
open
nobody
5
2018-01-24
2018-01-23
Scali
No

I think there is a design flaw in the software, at least in the Windows version.
The way EnvSysEx() and RecSysEx() are both called together from a single window event is not going to work in all cases.
The reason is that the midiIn callback is handled via the same message queue as the window events. So what I see happening is that RecSysEx() will time out in the loop, and as soon as I exit, I get the callback from midiIn.

So I think you should redesign it as a sort of state-machine:
1) User clicks button, window event fires off SysEx, and sets the state for the message it expects, event handler function returns, so message loop continues to run.
2) midiIn callback is fired, data comes in. With a switch on the state for the expected message, you call the correct code to finish receiving the message.

So it should be more of a Model View Controller design: the UI should be a view on the data, but you should have a central place to keep state and receive MIDI data outside of the UI. The controller will then be able to receive the incoming data, update the bank/voice/set/config/whatever data , and finally fire off a notification to the views so the UI can be updated.

Discussion

  • Scali

    Scali - 2018-01-23
    Post awaiting moderation.
  • Scali

    Scali - 2018-01-24
    Post awaiting moderation.

Log in to post a comment.

MongoDB Logo MongoDB