On 31.05.24 16:12, Will Godfrey wrote:
On Fri, 31 May 2024 15:06:34 +0200 ichthyo <[email protected]> wrote:
So why can the regular code to start up new instances not handle this case
as well? Why does this regular code have to use some greasy magic bit set
trickery with global variables, which is hard to understand for the
reader, instead of just processing a queue of instances in plain daylight?
And is there any real reason why this newBlock() function was moved
/before/ the regular event processing, while in normal operation, the
start-up of a new instance can happen just fine from within the regular
event processing?
The problems stem from the need for the first stand-alone instance to know
which other instances are currently active when it shuts down so that it can
restart them on the next run - hence that integer handled bit-wise. Each
instance has it's own config and instance files, so if you want to start the
identical setup you need to know which ones to fetch. I did try to find a
way for the first instance start to complete before it loaded the others,
but hadn't been able to do so. A further complication is the feature to force
a new startup from the desktop to open a new slave instance instead.
This gives some important context. Maybe a solution could be to make the
current state of each instance in the instance map even more explicit;
and also the request to start an instance could be some kind of command,
or it could be explicitly marked in the instance map.
I'll have a look if that is possible. Right now we only store a pointer
to the MusicClient in the instance map as "value" while the "key" is
an unique runtime ID of the SynthEngine (actually its memory address).
So, instead we could store a descriptor record as "value" and this
would allow us to store state information explicitly alongside.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
