On Fri, 17 Jan 2025 20:03:47 +0100 ichthyo <p...@ichthyostega.de> wrote:
>Hi Kristian, > >working with the Config can be challenging at times... > >On 17.01.25 17:44, Kristian Amlie wrote: >> Hmm, yes, the split between instance data and state data is rather murky >> waters. > >I can just agree to that. But right now we somehow have to live with it, >because separating both would be a quite deep refactoring of the whole >engine. Thus, for me it was always helpful, to sort those categories apart, >at least mentally. > >The changed / new logic applies to base/instance config. >There are other fields in the Config object, which are treated differently. > > >With the new handling/policy present since last release, >config is no longer saved explicitly by the user having to activate >on some "save" functionality. Rather, it happens immediately and >automatic. > >This has one important ramification: >We now have some kind of *Invariant* in place: > >I'd like to formulate it the following way: >"Config in memory *must not differ* from Config on disk" > >That means, whenever some piece of logic changes a setting that >is considered *Config* (as opposed to runtime state), than that >very piece of logic is responsible for making that change persistent. > >Otherwise we'd break this new contract, and get into quite confusing states. > > >On 17.01.25 09:13, Kristian Amlie wrote: >> 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. > > >Thus I'd approach this scenario as such: I'd try to spot any place >where the Config in memory moves away from the Config on disk. > > >Because, if both are always kept in sync, it does not matter to what degree >we actually load / write back to disk. As long as we're able to persist any >change in memory which is relevant. > >This was basically the trick which I applied when investigating the problems >with the XML compression (which was a long standing issue). And indeed, I >found a path where a setting from another instance config could leak into >the state (this is fixed now). > > >Thus, I'd look at that point you mentioned here >> * When loading a state, all configuration settings (in memory, not on disk) >> are overwritten by the ones in the state. > >Applying the "Invariant" from above, both /should not/ be different. >And thus it would not matter reading back config settings from disk. > >Thus I'd propose to ask, why is there a setting in memory which was not (yet) >persisted? Can it be persisted immediately close to the point where it is >changed? > >Or is there something in the Config object, which is not considered "config" >proper, but also overwritten when loading (because that would be a bug then)? > >-- Hermann > > >PS: I do not want to come over as "nitpicking", rather trying to be helpful, >because I had also quite difficult times with getting Config correct... Just want to add there are four areas of possible contention: LV2 JackSession management Normal stand-alone CLI startup When Yoshimi starts stand-alone it reads in the config and instance files. If they are missing this is the only time it immediately writes the default settings to file. I think we're more-or-less agreed that LV2 should not touch any of the main config/instance files at all. On a first time start *of each instance* it gets the default values, and from then on uses only 'get all data' and 'put all data'. This includes the config status (although much of this is ignored). Therefore it should be prevented from either reading or writing to the normal files. JackSession management, only handles the instance files - indeed I still have a session file that I used for testing some years back. It loads and saves these to it's own location. Changes you then make manually will end up in both the session data and the normal instance data! Normal stand-alone is the only one that reads all the config/instance data. It updates both as, and when you make changes but doesn't make a bulk save. The state file also includes MIDI-learn and Vectors. CLI startup *I think* only writes the first instance data (on top of the default values). Currently this doesn't overwrite the config/instance files until, and unless you make changes and then it only overwrites the bits you later change. I *think* that's all correct! -- Will J Godfrey _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
