On Wed, 22 Jan 2025 21:33:12 +0100 ichthyo <p...@ichthyostega.de> wrote:
>> On 17.01.2025 21:53, ichthyo wrote: >>> There is almost no impact of LV2 regarding config, and we should keep it >>> this way. In all the variants available right now, Yoshimi does the *full* >>> config handling, including all state loading and also all persistence, >>> for all of the base, instance, GUI / Window state and whatever. > >On 21.01.25 10:57, Kristian Amlie wrote: >> But how do you see state loading and saving fitting into all of this? State >> loading and saving happens constantly with LV2, which means it's changing >> config all the time. Simply loading a project in your DAW with LV2 instances >> can completely change the settings when firing up an unrelated standalone >> instance later. > >Some messages ago I proposed to distinguish conceptually between >- platform configuration >- instance configuration >- instruments etc. >- runtime state > >The current shape of the code is not especially helpful with that, >since there is one huge code blob called "Config", which has data fields >falling into all of these three categories. > >A good criterion if something can be considered "configuration" is to >look at the usages of this data field. If you find code to read/write it >from the config XML, it is config. If you find some other special persistence >or no persistence at all, it can be considered some other kind of internal >or runtime state. > > >With the policy changes (no explicit config save button anymore), which Will >introduced last spring and which came into effect with the latest release, >*configuration* should never differ between in-memory and persistent storage. > >Thus, if you know an example where just loading a LV2 project will silently >change a *configuration setting* (as opposed to some further runtime state), >then we'd break the new invariant and we'd have to consider how to sort that >out. Again, what I say here is *only* related to *config settings*. > > >There is one special twist pertaining to the /instance/ and instance numbers. >We mentioned it already in this thread, and this is *nothing new* (rather a >long-standing issue). The point is: you can /not control the instance IDs/ >for LV2. And when an instance ID is used for the first time, it will derive >a new set of config data, filling in some defaults and baseline settings from >the primary instance, and then obviously this new config data set will be >persisted (because otherwise we'd break our new invariant, that there can >not be any "pending, non-persistent" config settings). > >A similar twist happens if you have the "single instance" setting activated >for stand-alone and then start a new "yoshimi" at the commandline. Because >that new process will communicate with the existing "yoshimi" process, signal >the desire to start a new instance, and then terminate. And the existing >Yoshimi process will just allocate the next free instance number and launch >that instance of the Synth engine. > > >Just for sake of clarity: I did a lot of refactorings this summer, but I >deliberately did *not change any of this behaviour* -- this is a rather >obscure feature, yet it happened to be this way since a long time.... > >-- Hermann The more I see this, the more I think LV2 should not touch the stand-alone files: config, instance, state at all. As far as possible each LV2 instance should be treated as a completely separate entity. A new LV2 instance should only read the hard defaults, and from then on use get and put all data, which the host will then manage where and when it wants. The only area of contention I can think of is Banks (which already is a problem) as any instance can change the actual file structure without other instance been aware of the change. I know this is easy to say - without having tried to do it myself! -- Will J Godfrey _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
