On 17.01.25 20:52, Will Godfrey wrote:
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).
I *think* that's all correct!
Hi Will,
to answer to your last sentence, I also consider the current state
more or less correct, to the degree that it is even possible to get
such complicated logic with lots of mutable state under control.
However, I'd be cautious to work from a mental model that distinguishes
between an "LV2" Yoshimi, or an "Standalone Yoshimi" or even a "CLI Yoshimi".
Because, up to now there is only one core Yoshimi engine and runtime,
which is only slightly and (really superficially) configured differently,
according of the launch mode (standalone vs. LV2).
Please also see the code examples from my other mail.
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.
It is not true that LV2 does not touch Config. Quite to the contrary.
It runs through all of the complete start-up processing, which may include
loading default state. There is the setting to start with a default state,
and there are options to load a default instrument. None of this is guarded
in any way to behave different by Config::isLV2.
I'd like to stress that point: Config management is a huge and complicated
beast. To use computer science terminology, it is a full blown "state machine".
That means, it has various states, and goes over several state transitions.
(see the Config::sessionStage variable)
Right now, there is only one single version of that logic, and we
barely manage to keep that correct. For my refactorings last summer,
I went through an detailed analysis, going through the code line by line,
and it is really quite involved what happens during that process.
Thus I am somewhat anxious that we might loose control if we now start
to add guards for "LV2" and "CLI" or whatever on a case-by-case base,
without really understanding that logic as a whole.
With the change in the last Release, which immediately saves a changed
config setting, we actually *simplified* that logic by quite some degree.
The reason is, we do not have a "pending config" any more. We just have
"the" config, and it should always be the same in memory and on disk
(and if it isn't that's a bug and should be fixed).
You may recall, that from a user's POV, I rather do not like that behaviour,
because as a user, I really like the ability to have a pending config, and to
decide when it is saved. But, with my software developer's hat on, I tend to
welcome this change, because it makes it easier for us to keep it correct.
-- Hermann
============ Background info:
Who invokes XMLwrapper::saveXMLfile ?
* Config::saveMasterConfig()
* Config::saveInstanceConfig()
* Config::savePresetsList()
* Config::saveSessionData(savefile)
* Config::updateConfig(control, value)
* Microtonal::saveXML(filename)
* MidiLearn::saveList(name)
* Part::saveXML(filename, bool yoshiFormat) <- from indirectTransfers
* SynthEngine::saveBanks()
* SynthEngine::saveHistory()
* SynthEngine::savePatchesXML(filename) <----- from indirectTransfers
* UnifiedPresets::save() <------------------ from indirectTransfers Copy&Paste
* Vectors::saveVector(baseChan, name, bool full)
It is clear that not all of those count as "Config data",
yet is a good starting point to find out about persistent config
and who writes when to disk....
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
