On Fri, 31 May 2024 15:06:34 +0200
ichthyo <p...@ichthyostega.de> wrote:
>On 07.03.24 00:03, ichthyo wrote:
>> ...the pull-request is out, featuring the foundation and the change of the
>> Effect-UI, using push-updates through the newly developed GuiDataExchange.
>>
>> We have identified two known Bugs, which did exist already on the previous
>> release v2.3.2, but are largely amplified by the rework and are much more
>> noticeable.
>
>Hi Will and the other Yoshimi-devs,
>
>the "guiconnect" feature was landed on master at 7.3.24.
>Using it in practice revealed a bug when loading another Instrument,
>and this bug was fixed by performing a part-switch explicitly instead
>of implicitly in the GUI.
>
>There are some related issues, which were discovered or amplified by
>this rework of the Core-GUI connection. And possibly some further
>Clean-up work can be done in the Effect section of SynthEngine.
>
>
>To pick up this thread, I have investigated problems when restoring
>multiple Instances on start-up. That is, using the Config setting
>"Enable Auto Instance", represented as `Config::autoInstance`
>
>Doing so causes a time-out on the initial "bootstrap" message sent
>up into UI, and thus a complete failure of UI startup; the message
>would be processed about 600ms later in this case (which is above
>an implicit tiemout level of 500ms, which I've built into the new
>connection scheme to weed out stale messages).
>
>I tend to resist the temptation just to weaken the timeout level.
>Rather, I am looking into what causes that delay. Starting those
>instances was somehow hooked into the existing logic of main, and
>I am under the impression that the second instance start-up is
>triggered at the begin of the event loop and blocks the completion
>of the initial instance's start-up. This is caused by a function
>newBlock(), which is activated there only when autoInstance = true.
>
>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?
>
>-- Hermann
This was all built up over several years initially by Andrew, then by me (which
may explain some of the issues).
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.
There is another (currently unresolved issue) which is also relevant with LV2.
There is only one set of stored banks, yet multiple instances can load copies
of these at the same time. Therefore, a change could be made by an instance
that invalidates any others. I do have an idea for how to fix this, but have
been concentrating on more important stuff.
--
Will J Godfrey {apparently now an 'elderly'}
.
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
