On 01.03.24 19:22, Will Godfrey wrote:
I've spent quite a lot of time trying to get rid of these loops, but it's
rather like wack-a-mole, and very easy to accidentally create new ones :(
If the commands have come from anywhere *other* than a specific knob/slider
etc, then that control should be updated.
Hi Will,
indeed I can very much understand those difficulties now....
For the extra control parameters of the Effects, I have now established the
pattern to let the control only send the command, and to perform the possible
updates to UI state later, when the returns arrive. (I am referring here to the
effect number, effect type, enable / bypass and routing widgets, which are
not part of the EffUI itself. Approaching it this way, it does not matter if
the command actually originates from the GUI or from elsewhere; as soon as
it is processed in core, the push-update happens, and the following
process_returns() causes then the refresh or redraw, showing the changes.
With the changes from yesterday, I have removed the independent GUI state
for those controls. That means, the GUI now has no "neff" or "ninseff"
variables any more, and thus is also no longer able to access the values
in the core directly. Rather, the UI for the effect relies now solely
on the MirrorData sent per push-update. This resolved all those crashes
and out-of-sync problems.
Then I had to close some further gaps, where the command processing still
did not trigger the push-update and so the GUI would not expose the changes.
Notably this were some special cases of part switching, and the copy/paste
and the loading of instruments. With those filled in now, the GUI seems
to behave as usual now. "Hyper Matrix" loads correct again.
Then I discovered another challenge for those cases, where we load state
or an instrument through the configuration or the command line (or Jack
Session). In those cases, there is no receiver for the data-push, because
the GUI has not started yet. I added some sort of a preliminary hack
with my last changeset; but this is something I'll have to think over
in more detail, also regarding multiple Synth instances or the LV2
plugin case (I rather doubt it can even work with LV2, haven't tested
yet, but I also don't really understand how the GUI starts for LV2)
Anyway, my immediate next goal is to switch the EQ graph also to the
new system. This was the very reason we engaged into this rework after all.
Moreover, I'm under the impression that what I do now can also serve as
blueprint for extending it to further cases, notably the waveforms from
OscilGen or the Envelope data.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
