On 27.01.2025 01:05, ichthyo wrote:
On 26.01.25 23:29, Will Godfrey wrote:
Next, disable LV2 from loading and saving state (as I tried earlier).
I want to object strongly against that, after all the discussion and
the good insight gained. Just amputating some problematic functionality
we don't get under control, is a recipe to generate hard to maintain
software.
Why could it be any good to amputate config for the LV2 implementation?
I want to be able to save a changed general config from a LV2 plugin.
*Global* config should be saveable to the main config from within LV2, I
don't think anyone is objecting to that.
I want to be able to start a new LV2 instance, without having
to set a different oscil size and interpolation, or other settings.
Kristian has demonstrated why he wants to disable the Program Change
to avoid a disaster.
I agree very much with the incentives here. However, I do not like that
the LV2 config messes with the config of regular instances. I feel like
they are completely unrelated to LV2, so why should it be saved there? A
user could be using regular instances for completely different purposes
(and hence different config), and have this regularly screwed up
whenever a change is made in LV2.
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.
It seems, we more or less converge towards the conclusion, that
the problem (and unneeded feature) is handling of *instance configs*
for LV2. So IMHO this is the point where we could go in and address
the problems, as follows:
If a LV2 plugin starts, it *should* do all the regular normal config
handling. That is it loads the base config and the default form Instance 0
But it should not try to locate *special instance config* based on the
Synth-ID.
Same on saving. If you change something, it /should indeed write/ to the
base and default config, which is the one for Instance-0.
This would give us all the features we want!
- if you come in with a new instance, it picks up the *user*s defaults,
which are stored in:
+ yoshimi.config
+ yoshimi-0.instance
The existing code does that already.
No need to load technically sane, but for the user broken
hard-wired-defaults.
- later the Host will pick up the detail config and the patch state and
save it into the state file. From then on these individual settings
will be in effect for this instance, because they are baked into the
state,
even if the user changes the default settings later. This is what we
want.
If a user accesses the Config UI from a running LV2 instance and changes
a setting, this clearly means that the user *wants to change* this general
setting. It would be confusing and annoying if that is not possible.
With the proposed mechanics, such a change would go to yoshimi-0.instance.
That is, the user has changed the default. Moreover, the changed value is
also in-memory, and thus, when the project session is saved in the DAW /
Host,
the changed setting is also embedded into *this* instance. All other
instances
do not get the change. Again, that is what I'd expect as a user, when e.g.
changing the oscil size.
To me, it seems like the most important property that we want the system
to have, is for LV2 configuration changes to be preserved as a default
for the next fresh instance, so that one doesn't have to keep re-setting
config options all the time.
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 would completely disconnect
standalone config from LV2 config (except for global options), but both
would maintain their default config data. How's that?
First off, move "handle_padsynth_build" into state.
Maybe it should go into the second layer?
That is into yoshimi-N.instance. Right now it is in yoshimi.config, i.e.
it is in the base layer and can not be overridden on a per instance or
per state base. On the other hand, I'd like to ask if we want this setting
in the patch state / state files rather?
But IMHO this would again raise the question regarding defaults.
Some users (with only 1 CPU) can not afford to build PAD in the background.
Other users might still want an explicit "apply" button (I do at times,
when
I want to decide if there *is* an audible difference, and thus want a
tactile
action to do the switch instead of waiting for a crossfade, which tends to
obscure subtle changes)
I think you guys actually mean the same thing, no? Move
handle_padsynth_build into instance config, which then gets saved in
state. I agree with that.
With regards to being in the patch state.. Hmm, I think it should be
wherever oscilsize is (which is currently in instance config), since
they are the same "type" of setting (they affect engine initialization
parameters).
--
Kristian
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
