On Thu, 28 Dec 2023 16:20:52 +0100
ichthyo <p...@ichthyostega.de> wrote:
>Hi Will,
>
>first of all, hopefully you could enjoy the holidays and have a good time.
Hi Hermann,
Yes I spent the whole of Christmas day at my sister's, along with my other
sister, a few nephews and nieces and two grandchildren - the youngest of which
is about 15... I think!
How was your time?
>This made me reconsider the Model-2 the "core push" again, since this model
>clearly has the benefit that the core precisely knows when to push an update.
>And funny enough, since the core does it actively, it can not be "disturbed"
>by update requests, which could come in any time, while a "push" can be
>done at a point where it's convenient for the core (or a push can even
>be delegated to a background thread).
>
>Now, as we both pointed out, with a pure "core push" model, there might be
>the danger that the receiver is no longer there and thus the sender crashes.
>
>However, this could be mitigated by using a combination of "push" and "pull".
>How about that?
>
>(1) core knows there is a change that must be published. Thus it
> 1a) gets a new identifier from the data block system
> (which we'll have to design and build from scratch for this purpose)
> 1b) places the data into the buffer associated with that ID
> 1c) sends a "there is a data update" message via the /existing/
> ringbuffer-command system (that would be InterChange::toGui )
>
> At this point, Core can just walk away. If no one picks up that message,
> then it will be overwritten in the ringbuffer eventually. And the claimed
> data block will also be re-used after some time. Thus: no problem here.
>
>(2) The GUI does already a duty-cycle in »mainThread«, which wait states
> of 33333µs. Currently this is used for the update and response messages.
> 2a) when GuiUpdates::decode_updates() detects the new message type it...
> 2b) retrieves the data block from the data block system and
> 2c) directly dispatches it to the intended GUI component
>
>(3) this GUI component holds what we've discussed already: a mirror
> data store. This data mirror now would be the receiver and would be
> *directly invoked* by »mainThread« to push the retrieved data block.
>
> From this point on, a draw() routine would use the new data.
Yes I like this!
>So far this seems to be straight forward and rather robust.
>There is one remaining issue: possible interference with other GUI processing.
I don't think this is likely. FLTK is mostly small header files and is designed
to be capable of being statically linked (we may have to do that if the
upcoming V 1.4.0 is incompatible).
>Maybe you know a little bit more about FLTK here? Where does FLTK process
>its own events? i.e. when the user clicks on a button or a window is uncovered
>and must be redrawn?
I'm not sure but it seems to work in private space per instance. For example
the colour map is definitely per instance. If you start two completely separate
instances of Yoshimi and set the theme of one to the demo, it doesn't have any
effect on the other. Also things like the Alert window don't block a second
instance.
>Most UI toolkits I am aware of today use the model of "only one GUI thread",
>because this turned out to be the most robust way to build a message driven
>system. Thus typically there is somewhere a event-loop or a event-pulling
>in some GUI thread. Do you know how this is handled in Yoshimi? Is this
>GUI event processing hidden in the FL::wait() call which I see in mainThrad()
I think that's true per instance - The instances we create *within* a main
start do interact and can block each other. In a sense I wish Andrew had never
done that - it caused all sorts of complexities, but I don't know if anyone
actually uses it, so am reluctant to suggest it's removal.
I think LV2 instances are completely separate.
>Just poking into FL.h, I see a FL::run(), but this seems not to be invoked
>anywhere...
No we don't use 'run', it's one of two ways to start FLTK. We use
'lock()' and 'unlock()'. I did read up on the difference but have completely
forgotten :(
As an aside, two areas of contention internally are banks and window positions.
Over the last couple of years I've been mulling over ways to resolve both of
these, but will leave it for now!
--
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
