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
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
