On 28.02.24 21:35, ichthyo wrote:
... Other parts of the system do still access the core direcly, and where this especially creates all kinds of strange effects (no pun intended) is in the Part-Effects, since the control widgets to select the effect-Nr, type and routing are not part of the EffectUI (rather of PartUI).
Today I spend a lot of time investigating and analysing these external control fields, how they are set, used and managed. The GUI in conjunction with the Command-system is somewhat like a maze, yet meanwhile it seems I've grasped the underlying pattern... I have now a solution planned, which I will implement tomorrow; the idea is quite simple: all those extraneous state fields in the GUI simply have to go away. I mean fields like MasterUI::nsyseff, or PartUI::ninseff, the type dropdown and the routing dropdown. Instead, I will provide getters which use the data in the MirrorData for the given effect. This way, any inconsistency is precluded. To illustrate this by example Current UI: when the user changes the Effect-Nr - spinner fires callback - callback sets the new nsyseff or ninseff - callback invokes refresh() - callback sends the Command - command changes value in the Core - returns_update() calls again refresh() - refresh() uses nsyseff or ninseff as index to grab into the Core New solution: - spinner fires callback - callback *only* sends Command - Command in core changes the value - Command in core triggers push-update - push-update is first in the Queue -> pushes MirrorData - then follows the returns_update -> calls refresh() - refresh() uses the data now locally in the GUI in the MirrorData -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
