On Sun, 24 Dec 2023 02:51:46 +0100
ichthyo <p...@ichthyostega.de> wrote:
>>> On Fri, 22 Dec 2023 22:03:41 +0100 ichthyo <p...@ichthyostega.de> wrote:
>> Taking into account the current way of the main command interconnection,
>> and the situation in the code base in general, I see several different
>> approaches we could take. These are not totally separate, some aspects
>> being relevant for all of them, yet they differ in the depth and
>> radicality of the changes involved. I'll group them into three schemes.....
>
>On 23.12.23 10:34, Will Godfrey wrote:
>> Having a fairly quick look through these options, the one I'd be least happy
>> with would be number 2. We should work towards no possibility of the GUI
>> taking down the core.
>> Number 3 superficially looks the least invasive and most interesting.
>
>Scheme number 3 indeed attempts to keep some middle ground.
>Scheme-2 (push from core) would be simpler, but more pervasive.
>
>> It occurs to me that the UI can be informed that a graph change has been
>> *completed* with a 'graph changed' message via the existing ring buffer used
>> for all other GUI updates.
>
>That however would be Scheme-2, a push from the core on its own initiative.
>Yes, Scheme-2 has several benefits, because the core always knows first hand
>when data is stale and must be updated (but as said, would change a lot more
>existing things and has also its weak spots)
>
>What you propose here (if I understand correct) would be a slight variation.
>The push from the core would go via the command protocol, but then the
>UI code would do a further round-trip to request a data update. Doing it this
>way might be simpler to implement in the actual code, but is an unnecessary
>added interaction between core and GUI; this way we would lose the most
>important benefit of a core push, which is its simplicity and robustness.
>
>
>But as said, maybe the Scheme-3 is at the moment less pervasive to implement
>and better fits into the existing situation. So let's consider a bit more
>what we'd have to work out to make this happen.
>
>(1) in any case, we will have to develop a new data transfer facility,
> which can move structured / complex data from the core to the GUI.
> As in this example here, the filter response function. Or in the
> case of the OscilGen, the spectrum tables.
Yes I was expecting this.
There are also the resonance and format filter graphs to be considered.
The envelope ones are much simpler and can easily be handled by the existing
system.
> As you already pointed out, our existing communication channel is good
> for notifications and to transport single values, but no extended data.
> But we could build something similar as was used for the TextMsgBuffer,
> i.h. the main communication message transfers an attachment ID, and
> we'd build some thread safe storage, which keeps a number of buffers
> around, tagged with such an attachment ID. The number of buffers would
> be limited and discarded in LRU order (least recently used).
>
>(2) since in Scheme-3, the UI has the initiative: you probably know the
> UI better than I: has the UI always a reliable clue to know when to
> ask for new data?
No. far from it!
Originally everything was directly accessed both ways, with a wasp-nest of mutex
locks. It took a long time to work through that lot, and maybe as a result I'm
now overly hostile to mutex!
The GUI is still dipping into the core to read data (as you know), but
information *from* the core is now always buffered.
>(3) then the weakest point for Scheme-3: what will we do when the update
> from core does not arrive in time? Obviously this is unlikely, because,
> as you noticed correctly, the UI operates very slow in comparison to
> the SynthEngine. Yet non the less, this /can/ happen and we need to
> be prepared for it.
>
> - one possibility would be to allow blocking the UI much longer
> (say, five seconds), so that this situation is so extremely unlikely,
> that we can assume the core is crashed anyway. We would then just
> kill the UI and terminate. This would be the "KISS" solution
> ("keep it simple and stupid")
>
> - another possibility would be to wait only for a short timeout and
> then just to return and use the outdated data. Maybe we could
> re-trigger ourselves then and re-try the interaction, say 200ms later?
> I do not know FLTK well enough, but e.g. in GTK or QT, you can send
> yourself a re-activation event with some predetermined delay.
How does the GUI know there is new data in order to update it's copy?
Also, currently the GUI samples the graph - not every single point. I'm no sure
how that fits in.
--
Will J Godfrey {apparently now an 'elderly'}
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
