Am 07.04.22 um 16:44 schrieb Will Godfrey:
....it should be sent straight to resolveReplies(&). It's not actually a command, but a notification of completion.
..at the Moment I am still a bit unsure which entrance point to use. When looking at all usages of the queue interchange.toGUI(), I see some usages specific to MidiLearn and Undo. But for generic and unspecific responses to GUI, I see only two invocations directly in mediate(). However, as mediate() does all the command dispatch, it seems difficult to setup the command such that it is /only/ sent to GUI and does not cause and adverse side effects elsewhere. On the other hand, I see that some other parts of the code base directly send messages through interchange.toGUI(), without going through mediate(). So that might be a better approach here, since in our case we do not want to dispatch or broadcast a new command -- rather we just want to send a notification to the UI. E.g. commandPad() has a special treatment in... case PART::control::enablePad: if (write && (part->kit[kititem].Ppadenabled != value_bool)) { part->kit[kititem].Ppadenabled = value_bool; toGUI.write(getData->bytes); // cause update in the GUI to enable the edit button getData->data.source = TOPLEVEL::action::lowPrio; getData->data.control = PADSYNTH::control::applyChanges; ... note: at that point a message is directly fed into toGUI.write(), while then the flags TOPLEVEL::action::lowPrio is set to cause the actual command to be re-dispatched in the low-priority thread. So following that example, we could just directly send status update messages into the toGUI() queue (of course only when the GUI is actually started and showed) -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel