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. 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. 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. If we manage in a second step also to integrate the window layout, all the better. It would likewise fit into this scheme. If a user has "load with default state" enabled, then a new pristine LV2 instance will come up with the window layout users have in their default state (it will be saved either in yoshimi-0.state, or maybe in a new yoshimi-0.windows) Bottom line: a better solution would be to adapt the way how config is addressed for LV2, so that no config for *other* instances is read or written or located. -- Hermann PS:
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) _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
