On Thu, 7 Apr 2022 21:40:03 +0200
Ichthyostega <p...@ichthyostega.de> wrote:
>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.
I'd rather we didn't add another one. I know there are special cases, but I've
been trying to find ways to dispose of them! In a perfect world there would only
be one route to the gui.
>
>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.
I don't actually understand why we're doing that here :(
The fact that padsynth has been enabled/disabled should be passed to the gui
anyway, and that should be enough for the gui itself to activate the edit
button.
In almost all cases we want to send any changes to everyone who could have
created them or would like to know. Currently that's the CLI and the GUI. If
these don't want to know, then they can just ignore the message, and the CLI
will want to know that a change to padsynth has occurred. If we ever support
either a network and/or OSC these too would want to know.
This is where resolveReplies comes in.
This is of course a bit special as the result has been split in two 'action
started' and 'action completed'. Everywhere else just has 'action completed'.
It's actually more than that as we don't want to send multiple 'action
started' if one hasn't yet had time to complete so before sending the response
we need to check if one is already in progress.
Or is there something I've missed?
--
Will J Godfrey
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
