Am 11.10.21 um 20:09 schrieb Kristian Amlie:
Indeed. How hard would it be to have an option which sets the config
directory? Aka "--config-dir=testsuite/config", and then there would be a
"yoshimi-0.instance" file there.
Hi Kristian,
Hi Will,
after reading the available Docu regarding Config (in the old Advanced User
Manual PDF) and an attempt to analyse what's in the code, it seems to me
that there is no direct way to tell Yoshimi: "use default for everything".
The underlying reason seems to be that "Config" actually means several
things and is handled on various places on the startup code path, which
are controlled by the Config::sessionStage variable, which implements
some kind of State machine.
But right now my intention is not to change anything fundamental in
Yoshimi. I just look for ways to get a real clean everything-default
state prior to launching the Test.
And my current understanding is that we somehow need to prevent the
current user's Yoshimi default and state settings to "leak into"
the Test invocation. It does not help to use CLI to invoke the
MAIN::control::masterReset action, because this still might
reload the User's default session (if loadDefaultState==True)
Right now, the only viable method I see would be as follows:
(1) copy asside any existing Yoshimi configuration
(2) clean out everything below ~/.config/yoshimi
(3) launch Yoshimi with --null (to prevent figuring out
any sample rate or buffer size or audio devices)
(4) at the CLI immediately save a state file "empty.state"
Then, the Testsuite would inject a --state=path/to/empty.state
into the Commandline. This is not perfect, since Yoshimi will
then still load the User's .config/yoshimi/yoshimi-0.state,
but it will only load the base parameters from there, and then
it will load the base parameters from our "empty.state" on top.
Later, in SynthEngine::Init (SynthEngine.cpp line 330), because of
Runtime.sessionStage == _SYS_::type::StartupSecond
the function Config::restoreSessionData(Runtime.StateFile)
will be invoked, and StateFile has been set to our
"empty.state" when parsing the command line.
Is there any other solution?
As far as I can see, this approach would work, it would be
reasonably fast (since we don't load any instruments unless
a specific test wants to load an instrument). It should indeed
nail most values to defaults; the only downside I can see is
when we introduce settings for new stuff, which could then
leak through from User's defaults, unless we manually recreate
our "empty.state" to include defaults for this new stuff too.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
