<repeat>
Phew! There was a lot to go through in this thread. Apologies if I'm
repeating some stuff here, there was so much I had to reply one by one,
and send them as one batch. I think we are converging on something in
the last email though, so feel free to skim the other replies.
More below.
On 23.01.2025 22:18, ichthyo wrote:
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)
Hah! I hadn't even noticed this setting! That's another level of
complexity. But if I understand it correctly, this is really just the
same as starting Yoshimi with the defaultState setting disabled, and
loading the default state manually, right? If so, it doesn't really add
anything to the problem.
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*
Exactly.
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?
Exactly! You described it more succinctly than I could, apparently! 😄
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.
Yep, it's sneaky.
So there are two points to consider:
* why is such a dangerous setting enabled by default?
I guess it just wasn't foreseen to be dangerous. I would be ok with
changing the default, since only new users would be affected anyway.
* why does an aliasing to an existing instance-state happen?
Just to clarify: It doesn't. Not to an *existing* state. But it can
happen with a fresh instance, which I then save. It will be correctly
saved the first time, but not the second time (see the "wrong sequence"
in my other email).
Affecting existing states would only happen if we made the config truly
global, so that it isn't saved or loaded from the state at all. This is
why I was worried about that. But I think we are not seriously
considering that now, so we can probably ignore this point.
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"?
Yes, I agree, because I have trouble seeing the answer to the first
paragraph without answering the question in the second paragraph first.
--
Kristian
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
