Whorld's new thread architecture

In Whorld V1, configure a MIDI controller to control a setting, one with an immediate and obvious effect, like Master Speed. Now continuously move the controller with one hand, and with your other hand, right-click in the Whorld’s caption bar and keep the right mouse button pressed. The MIDI controller stops affecting the rendering, and this freeze persists until you release the right mouse button.

This happens because you’re blocking the Windows message loop, and in V1, the MIDI events are routed through the Windows message loop on their way to the render thread. If the message loop blocks, MIDI events are blocked too.

This bug is gone in V2.

The MIDI thread has a more complex task now. Instead of merely posting input MIDI messages to the UI thread, the MIDI thread now does the mapping, and queues the resulting commands directly to the render thread. The UI thread has no involvement in that route and cannot impede it. The MIDI thread also posts the corresponding parameter changes to the UI thread, so that it can update the sliders and edit boxes. If the UI thread is busy or blocked, updates pile up, but MIDI control of rendering is unaffected. And of course, the UI thread also sends commands to the render thread, in response to user edits.

This is a proper professional design. The only complication is that the user can modify the MIDI mapping. That means the MIDI and UI threads must share the mapping data, and such sharing must be managed carefully to avoid data corruption. Luckily, the MIDI thread reads the mapping data but never modifies it. Only the UI thread modifies the mappings, and this makes synchronization much easier.

Click to enlarge diagram