P.S: starting a new thread.... Hi Kristian, thanks for this ongoing discussion. It seems we're gradually narrowing down towards a clearer understanding of the problem at hand. And your analysis seems to underpin my gut feeling that we don't so much have a specific LV2 problem. Rather we have inconsistencies in general config handling. And none of these problems are new, only somewhat exacerbated by the recent change to persist config changes immediately. The core of the problem is: config is *layered* And Yoshimi is not able to keep that layered structure when saving. We have - base config - instance config - patch state - transient runtime state State files provide settings for all the first three layers. And largely, they need to, otherwise the concept would not be useful. Irrespective if used by LV2, or by JackSession, or by "start with default state" If we think through this logically, each setting would need to recall from which layer and which config source it was taken. So that when you "save" the config, an appropriate handling could be done -- either saving it to the source it stems from, or /not/ saving under some circumstances, like a default state, or maybe even asking the user what they want. But we don't have that infrastructure in place. We just immediately merge all config into "simple" values. All we can do after that point is somehow cheat around that deficiency. As said, the problem was there in essentially the same shape before the last release. Just there was a "save" button, and the user was free /not/ to hit that button if they did not want a change to the base config. Now, with the auto-save, just touching some setting in the Config UI is enough to overwrite the lower layers of config with settings populated from a state file. This can be confusing; but the good news is: there are state files! A user using state files can typically just ignore the regular config, as long as we can rely on the state file really having *all* settings. Are state files saved automatically? - for "start with default state" -> No, you have to save the default explicitly - for JackSession (or other session managers). Depends on the session manager. Usually you have to save a scenario explicitly there. - what do LV2 hosts? I must admit that I still don't see all possible scenarios. Kristian: you mention Program Change. I don't yet fully understand why this could wipe out some work? Is your example related to settings in the "patch state" layer of config? E.g what instrument is loaded into which part etc? And what precisely was overwritten? - a base config? - an instance config file? - maybe even a state file? where? managed by whom?
Con: Incompatible with Hermann's memory-and-disk-always-in-sync plan.
A minor nitpicking. This is not a "plan". And /personally/ I was rather opposed to the change. But the majority of users seemed to lean towards getting rid of the "save" button in the Confi-UI. Thus Will went ahead and made that change. As far as I know, this does not extend to "patch state" or "session-specific" as you put it. Like which instrument sits in which Part, if portamento is on etc. -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
