On Sun, 3 Mar 2024 02:22:53 +0100
ichthyo <p...@ichthyostega.de> wrote:
>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,
Hi Hermann,
Thanks for keeping me updated. I've been looking through some of the changes
(compared with V2.3.2). There are a few surprises, but in the main I can see -
at least in general, where this is all going.
>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.
>
This is definitely better than we've had up to now. To be fair, originally
there was only the GUI as a source of changes. It's a "bit" more complex these
days!
>
>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.
Those were always a nightmare to manage. Their absence will not be missed.
>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.
I had a lot of 'fun' trying to get Paste to update the GUI properly. It will be
good to have in enclosed in the more general case.
>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)
I hadn't thought about that. I think these options are very rarely used. In the
LV2 case, most hosts I've tried don't open the GUI when Yoshimi is loaded, but
do keep it open if instruments/patchsets etc. are changed. For stand-alone
would it be practical on startup to record the filename, but delay the
actual loading of these till the GUI is visible (assuming GUI is enabled).
As an aside, none of the startup options should mark the config as changed, and
that's something I want to sort out once the dust settles.
>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.
>
I look forward to seeing this :)
P.S.
It seems strange seeing code that I've exclusively managed for years being
altered by someone else (bit of a relief actually).
--
Will J Godfrey {apparently now an 'elderly'}
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
