On 17.01.2025 11:59, Will Godfrey wrote:
On Fri, 17 Jan 2025 09:13:35 +0100
Kristian Amlie <krist...@amlie.name> wrote:
I'm a bit confused by how it's even *supposed* to work, so let me try to
break down the scenarios.
1. Standalone instance(s) with no state saving or loading.
* Every change to settings is immediately saved to that instance
config.
* The config is loaded once at startup, and never again for that run.
Yes. Quite correct.
2. Standalone instance(s) with state saving and loading.
* Starts out like scenario 1.
* When saving a state, saves everything currently in the config.
* When loading a state, all configuration settings (in memory,
not on disk) are overwritten by the ones in the state.
* When saving the state again, the settings from the loaded state
are saved.
* When changing a setting, that specific setting is saved to the
instance config. The rest of the settings (which are different from the
ones in the loaded state) are left alone.
Currently yes. This may be slightly contentious as it it could be regarded as
having corrupted the instance data.
If that *really* is an issue, we would need to set a flag to indicate that were
were working in state 'mode'.
Thinking about it we already have one that could be extended: 'Start with
default state'.
We could set this when a state file is directly loaded. What do you think?
Hmm, yes, the split between instance data and state data is rather murky
waters. I'm not sure I understood exactly how your fix would work.
But even without that, I think that the behavior explained above is
acceptable, even if not ideal. The command line parameters and state
loading are on equal terms then. Both will modify the config, but not in
a way that is saved to the instance data, *unless* you also enter the
config window and start adjusting things yourself, in which case those
specific settings will be saved.
This is all good, except for, of course, that it doesn't work! 😄 But as
long as we agree that we are targeting that behavior I can look into why
loading is broken for me on my own.
3. LV2 instance.
* Essentially the same scenario as scenario 2.
Yes, but with LV2, we always work in an 'internal' state mode and never use any
of the stored config/instance data, so we should probably block *all* config
updates for LV2 - although I don't know what we'd do about graphic themes.
Yes! I was going to suggest that too.
Themes are completely independent of the config system. They are a truly
global setting, stored somewhere else, and I think it might as well stay
that way. It has no impact on the sound, loading or MIDI control, after all.
Will, is that how it's supposed to work?
Apart from those potential issues, that's exactly right.
Perfect!
--
Kristian
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
