On Thu, 30 Jan 2025 17:49:40 +0100 Kristian Amlie <krist...@amlie.name> wrote: <snip> >Now, I have to admit that I was slightly surprised and confused when the >Program Change wipeout *still* happened to me (under controlled >conditions, of course), and I had to investigate it. Through this I made >some new discoveries. > >First off, it turns out that my host doesn't do "state update" followed >by "Program Change". It does it in the opposite order! This means that >when the Program Change happens, the correct config still hasn't been >loaded by the state yet, and thus the Program Change still happens. How >can we get the correct config then..? Bummer. > >But hold on! If it does it in that order, it should *already* have >worked, even before your patch, because doing the state last means that >any Program Change that happened before that is irrelevant; everything >is reloaded from the state. Well, it turns out that there is an extra >element in play here, and what actually happens is this: > >1. Load LV2-instance config (Program Change is enabled, on purpose). > >2. Receives Program Change, which *schedules* program change. > >3. Receives state update, which contains both Program-Change-disabled >and correct patch. > >4. Program change is handled, and since Program Change is now disabled, >it should be blocked, but the check for Program Change Enabled happens >in point 2, not here, therefore it loads the Program anyway. > >So it still doesn't work correctly! > > >There are two ways we could handle this: > >1. Make the Program Change in point 2 synchronous, forcing it to finish >right there and then. Then the state will load after and everything will >be fine. > >2. Move (or copy) the Program Change Enabled check to where the load >actually happens (point 4), instead of where it is scheduled (point 2). > >I'm personally leaning towards option 1 because I also discovered that >delaying the loading is actually violating the LV2 Programs extension. I >quote: "The program change should take effect immediately at the start >of the next run() call". This is impossible to guarantee if the call is >asynchronous. The host is still free to call the function from a low >priority thread, so by making it synchronous we are making it the host's >responsibility to do so rather than ours. > >If I don't hear any counter-arguments, I'll get going with option 1. > > >FTR, what I described above is a separate problem from the original, so >everything Hermann has done is still valuable, and should go in >immediately as far as I'm concerned.
I've checked this through and it is now in the current master. It's astonishing how these things sort-of work so get missed for so long. I'll test Herman's patch against this and report back if I see any issues. -- Will J Godfrey _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
