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 23.01.2025 21:40, ichthyo wrote:
P.S: starting a new thread....
Hi Kristian,
thanks for this ongoing discussion. It seems we're gradually narrowing
down towards a clearer understanding of the problem at hand.
And your analysis seems to underpin my gut feeling that we don't so much
have a specific LV2 problem. Rather we have inconsistencies in general
config handling. And none of these problems are new, only somewhat
exacerbated by the recent change to persist config changes immediately.
The core of the problem is: config is *layered*
And Yoshimi is not able to keep that layered structure when saving.
We have
- base config
- instance config
- patch state
- transient runtime state
State files provide settings for all the first three layers.
And largely, they need to, otherwise the concept would not be useful.
Irrespective if used by LV2, or by JackSession, or by "start with
default state"
If we think through this logically, each setting would need to recall from
which layer and which config source it was taken. So that when you "save"
the config, an appropriate handling could be done -- either saving it to
the
source it stems from, or /not/ saving under some circumstances, like a
default
state, or maybe even asking the user what they want.
But we don't have that infrastructure in place.
We just immediately merge all config into "simple" values.
All we can do after that point is somehow cheat around that deficiency.
As said, the problem was there in essentially the same shape before
the last release. Just there was a "save" button, and the user was free
/not/ to hit that button if they did not want a change to the base config.
Right, I had not even considered that the problem got amplified by that.
I think that the auto-save in general is still an improvement though,
except for this specific issue.
Now, with the auto-save, just touching some setting in the Config UI is
enough
to overwrite the lower layers of config with settings populated from a
state file.
This can be confusing; but the good news is: there are state files!
A user using state files can typically just ignore the regular config,
as long as we can rely on the state file really having *all* settings.
Are state files saved automatically?
- for "start with default state" -> No, you have to save the default
explicitly
- for JackSession (or other session managers). Depends on the session
manager.
Usually you have to save a scenario explicitly there.
- what do LV2 hosts?
They always save. This is nearly universal behavior I'd say. The state
is included in the save file of the DAW, so as long as you save the
project, you save Yoshimi's state as well.
I must admit that I still don't see all possible scenarios.
Kristian: you mention Program Change.
I don't yet fully understand why this could wipe out some work?
The core of the problem is that State loading and Program Change are
somewhat conflicting operations in Yoshimi, unlike many other plugins,
where they complement each other. If you first load a state, and then
issue a Program Change, most of that state is wiped clean and replaced
by whatever instrument is in that slot.
A contrasting example is FluidSynth, where the state and the program
complement each other. The state is used to load the bank file and
effect settings, and the program change is used to select an instrument
from within the bank. The two complement each other.
I don't think Yoshimi is "wrong" or anything, but Yoshimi does right to
have a setting to block Program Change in this scenario. Some folks may
prefer to use LV2 Yoshimi differently, and load banks instead, and for
them the opposite setting would be the correct one.
Is your example related to settings in the "patch state" layer of config?
E.g what instrument is loaded into which part etc?
And what precisely was overwritten?
- a base config?
- an instance config file?
- maybe even a state file? where? managed by whom?
Let me try to illustrate by going through the correct sequence, then the
wrong sequence.
(Update: After writing this I realized that you already captured it
correctly in a subsequent email, but I left it here in any case before
sending all replies in a batch. Feel free to skip though.)
--- Correct sequence ---
1. DAW loads fresh Yoshimi LV2 instance.
2. Yoshimi loads main config, which contains Program Change Disabled.
3. I make a patch inside Yoshimi.
4. I hit "Save" in the DAW.
5. The DAW pulls the whole state from Yoshimi, and saves it in its own
format. This includes the Program Change Disabled setting.
6. I shut down.
7. I come back later, and load the project into the DAW.
8. DAW loads a fresh Yoshimi LV2 instance.
9. DAW applies the state data it previously saved.
10. DAW sends program change message. Since I didn't actively use it
earlier, this is typically just program 0.
11. Program Change is blocked by Yoshimi.
12. Project loading is finished, everything works.
--- Wrong sequence ---
1. DAW loads fresh Yoshimi LV2 instance.
2. Yoshimi loads main config, which contains Program Change *Enabled*.
3. I make a patch inside Yoshimi.
4. I hit "Save" in the DAW.
5. The DAW pulls the whole state from Yoshimi, and saves it in its own
format. This includes the Program Change *Enabled* setting.
6. I shut down.
7. I come back later, and load the project into the DAW.
8. DAW loads a fresh Yoshimi LV2 instance.
9. DAW applies the state data it previously saved, including Program
Change *Enabled*.
10. DAW sends program change message.
11. Program Change is *handled by Yoshimi* and used to load the first
instrument in the current bank. This erases the patch from point 3. Note
that nothing has been overwritten *yet*.
12. I save the DAW project.
13. The DAW pulls the the whole state from Yoshimi, which now contains
the patch from point 11, not from point 3. It is saved in the DAW file
and the point 3 patch is lost.
Con: Incompatible with Hermann's memory-and-disk-always-in-sync plan.
A minor nitpicking. This is not a "plan". And /personally/ I was rather
opposed to the change. But the majority of users seemed to lean towards
getting rid of the "save" button in the Confi-UI. Thus Will went ahead
and made that change.
Ok, fair enough, I had misunderstood it slightly then.
--
Kristian
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
