<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 24.01.2025 00:09, ichthyo wrote:
Hi Yoshimi-devs,
let me just brainstorm a bit further.
>
> ...
Trimming the email, but yes, good analysis.
@ Kristian: regarding your options,
I agree with your analysis.
Basically the conclusion is that we're more or less forced
to stick with the current scheme, which has a *layering*
--- Option 1 ---
Leave it as is. There are both global and non-global (session s.ecific)
Its not only gloabal, also global per-instance and then a overlay
provided by the state file. This covers all settings with impact on the
sound.
--- Option 2 ---
Make all options global, don't save them in state.
This would attempt to make "Config" and "Patch State" disjoint
Which is problematic because:
- some users need specific *Config* settings even to connect to sound
- some *Config* settings have a impact on the fine points of sound
generation
- and not all users can or want to start with the same baseline.
- thus you want *your personal default* for *new instances*
Agreed, I figured this would probably be the least desirable option.
--- Option 3 ---
Make all config options global, but move some options to other parts
of the
save structure, such as Part or Controller.
Effectively this is like using always state files in the current solution.
And you need a way to create and explicitly save your state files.
Yes, I suppose it could complicate the simple case. If you are just
happily using a single instance with no LV2, then you'd be forced to use
state files to be able to save certain settings. I guess defaultState
could be used, but it doesn't sound like an improvement to me.
So I think option 1 is the best.
On 22.01.2025 23:14, ichthyo wrote:
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? 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?
On 23.01.25 18:13, Kristian Amlie wrote:
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?
That is *precisely* what we do now and do since several years.
Whenever you start a LV2 plugin instance, it internally grabs a Synth-ID.
And it uses this Synth-ID as prefix for the *Instance Config*
If a config with that ID already exists, it loads this config.
Otherwise, it looks for the base config and Instance-0 config to fill
in defaults.
*After that* the state file is loaded *on top* of those baseline settings.
And when you *save* the Config settings from the Config-UI (which now
happens
automatically), the instance settings also use the Synth-ID
(Instance-ID) as
prefix to find the config to overwrite.
Right, and it is this saving which Will suggested that we remove.
Note: this also covers window and UI layout. Like e.g. the scale of the UI
for people with very high resolution monitors. This is a lot of detail data
and it is stored in the windows/ subdirectory, also with the Instance-ID
as prefix.
Right, I did not think about the window settings. I think they are less
critical though.
What I propose is basically to use a more intelligent allocation of IDs.
Instead of using the plain Synth-ID, my idea was somehow to derive a more
distinctive instance-key. I do not know if this is possible. We'd need to
get some additional information from the LV2 host, like the session name
and the track name or some internal unique plugin instance ID.
We could hash these then and use the Hash as Key.
Standalone could use a different scheme.
If we're able to pull that off, then...
PRO: each Instance also recalls its window locations
PRO: we will much more often really detect the "new instance" situation
and populate from the dafault values, instead of aliasing to some
other usage which just happened to have the same Synth-ID
CON: over time, we will flood the user's config directory.
Would be a very localised change and thus easy to implement.
But not sure if its a relevant improvement....
I think there is no such thing as unique plugin instance ID in the LV2 spec.
I think a better approach would be to get the window settings into the
state data instead, because this could be saved in LV2 very easily, and
in config as well. The window settings are stored in a directory full of
window-named keys, so couldn't they just be stored in XML as
window-named keys instead?
(Update: I see that Will also suggested this in a different email, so +1
from me!)
We could consider how much digits to put into the hash key,
to control the trade-off between storage waste and accidental
clashes.
Anyway, I think there is one crucial question:
Can we think of situations where this config is essential for a plugin
instance to work? That would be the case if some host does not do the
extra trick with passing a state file. I mean the hooks in the LV2
plugin to retrieve and provide the state data (YoshimiLV2Plugin::stateSave)
Do we know how reliably these are used by the hosts?
I do not know the LV2 standard well enough, but are hosts required
to invoke these functions?
Yes and no.
Yes, in the sense that any host that doesn't invoke them is a completely
inferior host, incapable of saving anything between sessions. I have
never seen such a host except for experimental projects and LV2 code
examples.
No, in the sense that it expected behavior of a host *not* to call those
functions when launching a fresh instance, so that can be used as a way
to distinguish between the two. It will then call them the first time it
saves.
If this could be guaranteed, then we could indeed kind of amputate
the config handling and make a LV2 instance always behave as if it
has just not found its config, i.e. populate from baseline.
We actually do this already, in the brief window between launching the
plugin and loading the state, which are discrete steps, and can
sometimes be far apart in time (when there are many heavy plugins to
load in a project).
One caveat though: there is also the window layout config.
Yes, this is not covered at all, and windows will receive a "random"
instance layout.
--
Kristian
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
