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

Reply via email to