On Fri, 24 Jan 2025 01:17:43 +0100 ichthyo <p...@ichthyostega.de> wrote:
>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, but would be relying on: >> SynthEngine::getalldata( >> SynthEngine::putalldata( > > >Hi Will, > >see at the end of my other mail. >Where I've explained the idea with the hash-IDs. Yes. This bit I think is a good idea, 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. >The point is: we need to know if a LV2 host *must* (by the standard) >use this mechanism. Which is equivalent to always starting Yoshimi >with a state file and at the end saving that state file. >Because, in that case, the instance config is always overwritten anyway Yes. This *is* part of the LV2 spec. Similarly Jack-session uses state files for its storage. >It would not resolve the corruption problem Kristian described though. >Because that rests on a dangerous setting leaking from the defaults >into a new instance and from there into the patch-state data the >host stores and publishes back. > > >Besides that, there is also the problem with the Window layout files. >For users with high resolution displays, these are crucial. >We'd have to find a way also to pick up some default window layout >whenever we are in the "new instance" case. This is trivially easy to resolve. For some time I've been thinking that individual tiny files was the wrong way to go, but it was built up a bit at a time so made sense then - particularly when I wanted to fiddle with individual settings to test the behaviour. 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. >Your change (and the similar one pondered by me) basically amount >to always making LV2 plugin instances go into the "new instance" >case. We must be sure that all relevant hosts do indeed send >the patch-state data. And of course, we'd have to do the change >in a way that it also covers other stuff like the window files. It is certainly true of all the hosts I've tested with. I'm not sure about Reaper, but I'd be surprised if they got it wrong. Also, I think the get/put all data names for LV2 are confusing, and should be renamed as: loadLV2state saveLV2state >That is, if anything, I'd propose to handle it at the point where >the config location is resolved, ideally at a single and easy to >sport central location, and rather not hook into some implementation >functions deep down without understanding all the consequences. > >-- Hermann > > > > >_______________________________________________ >Yoshimi-devel mailing list >Yoshimi-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/yoshimi-devel -- Will J Godfrey {apparently now an 'elderly'} https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
