On Fri, 17 Jan 2025 09:13:35 +0100 Kristian Amlie <krist...@amlie.name> wrote:
>On 16.01.2025 12:47, Will Godfrey wrote: >> On Thu, 16 Jan 2025 10:29:21 +0100 >> Kristian Amlie <krist...@amlie.name> wrote: >>> ... >>> >>> It's the loading that doesn't work. And it doesn't work under LV2 >>> either, apparently. >>> >>> This is turning into more of a hornet's nest than I expected. Let's just >>> put aside the loading problem for a moment, and pretend that this works. >>> Even then, the way that config files are loaded and saved is >>> problematic. If I load a state that contains certain config settings, if >>> I change one config setting afterwards, it will load the one from the >>> config directory instead, not the state, then change that one setting. >>> When I then go to save the state, all settings will have reverted to the >>> settings from the config directory, not the settings that were already >>> in the state. >>> >>> I knew about the fixes to config saving (not the details though), but I >>> don't remember why this loading-followed-by-saving was introduced. Do >>> you remember? >>> >> That shouldn't have happened :( >> It's supposed to load the config file into a 'detached' area, not the current >> one. Change just the one parameter in that area and re-save it to the config >> file. > >Hmm ok. > >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? > 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. >Will, is that how it's supposed to work? Apart from those potential issues, that's exactly right. P.S. As usual, nothing is simple in Yoshimi! -- Will J Godfrey _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
