On 22.01.2025 23:14, ichthyo wrote:
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*.
On 23.01.25 18:13, Kristian Amlie wrote:
Yes, a lot of them, all the time, unfortunately. To be exact,
what is stored in state data are all the settings
below `XMLcompressionLevel` in the `globals.h` file.
Again, I would kindly ask anyone to be precise with the terminology.
yoshimi.config
This is the *Base Config*.
It is populated by first start of Instance-0
And most of the config entries are grayed out in the GUI,
unless you're running Instance-0
It has only a very small number of settings
enable_gui
enable_splash
enable_CLI
show_CLI_context
enable_single_master <- potentially dangerous
enable_auto_instance <- potentially confusing and dangerous
handle_padsynth_build <- not sure if this belongs here
gzip_compression
banks_checked
active_instances <- this is not really "Config" but global persistent state
guide_version
manual
yoshimi.0.instance
This is the major part of the *Instance-Configuration* /different per instance
It currently has 36 settings, some of which have a subtle or even drastic
impact on the sound and behaviour
yoshimi.0.state
This would be the default *state file* for Instance-0
It will be loaded /only/ if you have "defaultState" activated in the *Config*
of that Instance (here #0)
In the previous mails, we used various terms for this part of the persistent
data. Like "patch state" or "state file"
One twist to note is that these state files do also contain all of the
settings from the previous layer, i.e. they overlay all the *Instance Config*
On 23.01.25 18:13, Kristian Amlie wrote:
When my DAW loads my project, containing LV2 instances, it loads each
instance's state data, and it also issues a Program Change. 9 times out
of 10, I will have made a customized patch for that project specifically,
which means that I don't want a Program Change to take effect, because it
would wipe out the state which is the only place where the patch is stored
(I don't store it in a bank).
So I keep the "Enable Program Change" option disabled.
So for the sake of clarity: what we see here is a very unfortunate
interaction between the LV2 host's behaviour and Yoshimi's behaviour.
This is the kind of stuff that no one ever intended,
but repeatedly caused nuclear power plants to melt down.
To summarise...
- the host populates each plugin-instance with a state file
- then the host sends some patch-state changing MIDI command
- when you close the session, the host prompts each LV2 plugin
to generate a new state file and staves that with the project.
Is this summary correct?
But there have been times where this option has been enabled. Often this
has happened when I've been hacking on Yoshimi itself, and that option
happens by chance to become enabled in the main config file. Much later,
and unaware of the config change, I fire up a DAW, and start working on a
new patch in a new LV2 instance.
When I save this, it has Program Change Enabled!
So basically this is a leak of config data, migrating through several sources.
The problematic setting must be from some default?
Anyway, it got into the config of some instance (because it is a setting
on the level of the instance-config, "ignore_program_change"
Now you create a new LV2 plugin instance.
This happens to pick up an existing instance-config.
and from there the dangerous setting sneaks into the state-file persisted
with the session in the LV2 host.
So there are two points to consider:
* why is such a dangerous setting enabled by default?
* why does an aliasing to an existing instance-state happen?
This brings us to the discussion "LV2 should not touch config"
Will, I see your point, but I still oppose the approach. Because
"not touch config" would have way to far reaching ramifications.
Maybe we should rather try to get a better handle at the notion
of "a new instance"?
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
