On 07.02.24 01:07, ichthyo wrote:
* implemented: have MirrorData blocks in the UI connected properly
* unimplemented: trigger push update + use the data from the MirrorData
block
On 21.02.24 02:51, ichthyo wrote:
...now focussing on the aspect of state updates. While I'm still somewhat
struggling to understand how things work together (especially since those
effect arrays are more or less global data and accessed from a huge load
of different contexts) ...
Hi Will,
indeed, the above statement indicates the major road block for this effort.
Meanwhile, I was able to understand the command processing and add trigger
points for push-updates to all those changes which actually cause different
Effect settings to be exposed in the UI.
Building on this, today I was able to switch the entire Effect-UI away from
accessing the core data directly. Obviously this is a massive and daunting
changeset (and I'd bet that I have introduced some new stray bugs...).
Yet the good news is: it basically works as intended. All Effect settings
are there and can be manipulated as before. This makes me confident that
the concept for this change will work out as planned.
There are follow-up problems in the current state on the branch, and
these are not surprising. 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). Especially this means
that on change, the state in core and in UI differs until the
push-update arrives, and thus for part-effects the refresh()
call simply runs too early. So this gives the impression
that the old UI sticks and is carried around even after
a part switch.
Now I have to explain, why I went head-on into this major rework.
Initially, we intended to start with a sub-component, the EQ graph.
But this turned out to be very complicated, due to the same reason
as indicated above: if only one sub-widget would use the new update
mechanism, which happens through a push-update and thus slightly
delayed, the update pattern would be mixed and it is near impossible
to prevent pointer accesses to components which aren't there (anymore).
Just assume for example that we have two consecutive EQ effects and
we change between them: then a randomly mixed up refresh() of old
and new data would be hard to prevent. Thus I decided to switch
the entire Effect-UI in one coordinated effort.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
