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*.
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.
I'll give you a particularly disturbing practical example which has
already happened to me at least twice: 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.
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! The effect of loading this later can be *devastating* to
the project. All the changes I made are wiped out due to the program
change, and if I now save the project again, they are wiped out
permanently, even from disk.
Because this particular config setting is saved in the state data, this
only affects new, fresh instances, and only if I've made a mistake and
enabled Program Change. Which is sort of my fault, but still pretty
dangerous.
I'm not suggesting that we fix that in any way, but I'm just
highlighting that this problem would become *much* worse if the config
was truly global, and was not saved in and loaded from the state data.
Then if I mistakenly changed that setting, and innocently loaded a DAW
project and saved it again, I would essentially wipe out *the whole
project*! At least everything having to do with Yoshimi.
Luckily, I check all my projects into Git, so the few times this has
happened to me, I was able to recover the patches from there.
On 22.01.25 22:00, Will Godfrey wrote:
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.
There is a lot you want to configure different than the "hard defaults".
Just look into the settings GUI. Oscil size, Keyboard layout, PadSynth
crossfade, XML compression....
Moreover, you definitively want to preserve your window layout.
The LV2 host has no GUI for this stuff.
I don't understand this.. LV2 and standalone have the same GUI, am I
missing something?
Then on top comes my strong objection against introducing lots of
specific LV2 behaviour. The complexity within Yoshimi is already hard
to manage without it.
First of: what are the actual problems we see with the current state of
affairs
regarding LV2? Before we got into this discussion, we were able to live
with the
current situation since some years, and at least my own experience shows
that
configuration is rather an occasional annoyance when working with several
LV2 or standalone instance. Not a real problem. Because you can manage
somehow.
This started with me wanting to support for Omni mode. Both of you
preferred to have this setting in config data.
What I take from Hermann's comments is that config should be global, and
shared between all instances, LV2 or not. I kind of agree with this in a
general sense, but unfortunately Yoshimi's config is already very
non-global. This is both due to the state saving, but also that some
options simply are very session specific. And some of the data is very
important for correct operation, as described with the Program Change
option above.
So I think the heart of issue, and what we need to agree on, is what to
do with the session specific config options.
--- Option 1 ---
Leave it as is. There are both global and non-global (session specific)
config options.
Pro: The least risk of breaking anything.
Pro: We know it works.
Con: A bit messy, and unintuitive that some options are saved in the
state while some are not.
Con: Makes it hard to avoid certain hacks, treating some options
differently from others, and possibly treating LV2 differently.
Con: Incompatible with Hermann's memory-and-disk-always-in-sync plan.
--- Option 2 ---
Make all options global, don't save them in state.
Pro: Very clean.
Pro: Easier to understand for users.
Con: No longer possible to configure certain options differently for
different projects.
Con: Some options are extremely devastating if configured incorrectly,
as per my example.
Con: If disk and memory are to be kept in sync, then it means that
specifying command line options will change the config, which Will has
been working to avoid.
--- Option 3 ---
Make all config options global, but move some options to other parts of
the save structure, such as Part or Controller.
Pro: Also very clean.
Pro: Also easy to understand.
Pro: Can selectively move options that "make sense" out of config and
into Part or Controller.
Con: Probably a lot of work. Requires changes both in internal structure
and in the UI, to move the affected options.
Con: Maybe difficult to agree on which options make sense.
Con: Needs compatibility loading code (for a new instance to load old
config correctly).
------
Those are the options I can think of. Honestly, I think all of them are
kind of bad. And given that, I think I'd favor option 1, simply because
it's the least amount of work. But then we have to accept some
"unclean-ness".
Since Omni mode was what started all this, it's worth noting that for
option 2 and 3, the Omni mode setting *cannot* be put into the Config
section, because it's session specific. It must be put in either the
Part or Controller section then.
If we really think that config handling for LV2 is a serious problem,
shouldn't we rather consider to store config differently for LV2 and apart
from the standalone settings?
I don't think this would solve the problem, because the issue exists for
normal state saving and loading in standalone instances too, not just
for LV2.
Wouldn't it be sufficient just to use a
different
instance-key (for the config files and the window layout files?) Like e.g.
a 6 digit hash-ID which is somehow derived from an identifier which
characterises the plugin instance reproducably?
I may be misunderstanding, but do you mean to store the config for LV2
in instance specific files in the `~/.config/Yoshimi` directory? Under
an instance key?
This is not a good idea I think, because DAW projects would not be self
contained. It would not be possible to copy a project from one PC to
another without loss of Yoshimi config, unless you deliberately copy the
config as well.
--
Kristian
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
