On 23.01.25 23:40, Will Godfrey wrote:
Like that LV2 at startup would only see the hard defaults, and would not save anything to the main config or instance files, ....
On 24.01.25 10:50, Will Godfrey wrote:
..., certainly for LV2 where the idea of a primary instance doesn't make sense. For stand-alone I think users would prefer to see a simple numerical entry.
Yesterday I did consider various aspects of this topic, and one important insight was for me: -> we have actually two different usage models. (1) simple, ad-hoc (2) as part of elaborate projects And case (2) implies typically to use some kind of state-files. This means, to use Kristian's terms, in these cases we have an *individual*, local and *flat* configuration + patch state for each instance. The structure of configuration mostly matters for the simple usage (1). And it matters for the "new-instance" situation, when you prime the flat and local config + patch-state and then create the state-file. It seems that LV2 almost entirely falls into the "complex project" category. Why would you bother to start a DAW / Host and Project, if all you want is just try out some notes or tweak some instrument? On 24.01.25 01:17, ichthyo wrote:
Besides that, there is also the problem with the Window layout files.
On 23.01.25 23:40, Will Godfrey wrote:
... Much better now would be a single 'display' file, with all the data in it. This could then be tacked onto the state file, so would become part of the LV2 storage.
wow, that seems like a significant improvement, because then each plugin instance would recall its own last-used windows. With my hash-Key proposal I had something similar in mind (albeit with less effort). However, we should then also consider to make it part of the patch-state in general (not only LV2 specific). Because IMHO those are also the cases where (at least I, as a user) would value finding all windows as they were last time. Especially when fine-tuning.
Also, I think the get/put all data names for LV2 are confusing, and should be renamed as: loadLV2state / saveLV2state
indeed, it is something generic, and it is just a special entrance-point for LV2. Maybe we could even get rid of that special entrance point (by folding it into the implementation of the callbacks). Because, in the end, those functions just delegate to the general functions handling the state-files. -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
