On 27.01.25 01:05, ichthyo wrote:
If a LV2 plugin starts, it *should* do all the regular normal config
handling.
On 27.01.25 13:05, Will Godfrey wrote:
Most of the base config is ignored by LV2, as are things like Jack/Alsa in
the instances.
Probably you are referring to the instance config, not the base config.
The /base config/ is relevant for LV2, because it holds things like
xml-compression, banks-checked, guide-version, and the manual path
The /instance config/ is in fact very relevant for LV2, because among
these are behaviour settings (logging variants, reporting of loadtimes,
virtual keyboard layout, bank-highlight, saved instrument format).
Then, there are settings regarding special MIDI commands, including
the ignore_program_change!
And last but not least there are engine settings with impact on
the sound, like oscil-size and interpolation
So IMHO it is very important to populate *a new LV2 instance* with
those values and have a GUI for them
On 27.01.25 13:05, Will Godfrey wrote:
If we do want a generic default config to replace the hard-wired one
then it should be a completely separate file - possibly named
'master-config'. Presumably it should be applied to both LV2 and
stand-alone, and would be over-ridden by the LV2 stored states,
and the same for stand-alone instances and numbered states.
Agreed, that could be a nice addition.
In the current logic this would be without effect however, since it is
always shadowed by the Instance-0 config. But that could change, see
Kristian's proposal.
We could add a new menu entry to allow saving a new default config, which
applies for any new instance. This might help to disentangle functionality.
On Mon, 27 Jan 2025 Kristian Amlie <krist...@amlie.name> wrote:
The current code actually mitigates this somewhat by only saving the
option you changed, not the whole set of options.
We have not yet talked about whether we want to keep that or not.
On 27.01.25 13:05, Will Godfrey wrote:
It's not applicable to LV2, as on close LV2 stores all the *current*
settings for that instance.
How so? Are you referring to patch-state?
Indeed, the LV2 host can pull the current state and save it
into the session. Most full-fledged hosts do it one way or the other.
But this has nothing to do with Yoshimi's *Config UI*.
If you change a setting in the ConfigUI of a LV2 instance, it
will write a change into that instance's config (not the patch state).
If you close the LV2 host without saving its session, the change will be
in yoshimi's instance config, but not in the state managed by the Host
What is problematic with the status-quo however is that this instance
state is keyed by the Synth-ID, which is more or less random for LV2.
We seem all to agree that this is not what was intended and desirable.
However, it is certainly not a solution just to cripple that feature,
because there are several valid cases why a user /wants/ to change a
setting in the settings-UI and that is being used as /fall-back/ for
/new instances/.
A solution would be to change the *addressing* of this instance config
for LV2. My proposal was to always use the instance-config of Instance-0,
Kristian proposed a similar approach:
On 27.01.25 10:04, Kristian Amlie wrote:
So why don't we do this: Basically we save the configuration exactly as
Hermann describes, except instead of saving it to "instance-0", we save it
to "LV2-default" (or some other suitable name). And new LV2 instances also
pull their defaults from here.
This seems like a much better solution for me!
Implementation-wise it uses the same approach: We just "decorate" the
instance-ID that is used to build the file name of the instance config file
- for Standalone: use the current Synth-ID (what is done currently)
- for LV2, instead use a fixed symbol, e.g. "LV2" instead.
We'd have to extract the build-up of the file name, which is currently
done interwoven with the other config handling. But besides that, this
would be a really minimal change and would solve all the problems,
by addressing the root cause: essentially we are creating a new kind
of "instance", which is a LV2 instance, and separate from standalone
instance.
In any case, the overlay with the patch state always comes on top,
and is maintained in state files, or by the session manager, or
by the LV2 host.
To sum up:
- for Standalone, the three layers are:
Tier-1: yoshimi.config, yoshimi.banks, yoshimi-favourites
Tier-2: yoshimi-#.instance
Tier-3: yoshimi-#.state
- for LV2, the three layers are:
Tier-1: yoshimi.config, yoshimi.banks, yoshimi-favourites
Tier-2: yoshimi-LV2.instance
Tier-3: managed by the host via YoshimiLV2Plugin::extension_data
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
