On Mon, 15 Nov 2021 05:41:04 +0100 Ichthyostega <p...@ichthyostega.de> wrote:
>>> the recent changes on master must have altered something related to >>> PADSynth. >>> Here, "recent" means between >>> >>>> commit 0b3199e91dec15dbcc8d7d240ba785be993ddab4 >>>> Author: abrolag <willgodf...@musically.me.uk> >>>> Date: Fri Nov 5 09:38:46 2021 +0000 >>>> >>>> "Updated user guide" >>> >>> and current master 71ffe1d0bd53 > > >Hi Will, >Hi Kristian, > >The good news is: with the testsuite it is now possible to identify >the relevant change automatically. All it needs is to write a shell script, >that builds a current git checkout, then runs the testsuite (filtered to >only the relevant test case) and then return 0 or 1 if that test fails. > >Then "git bisect" does all the work: it performs a logarithmic search to >find the last changeset that passes the test. You just need to let it >run an hour or so... > >OK so this reveals the "culprit" > > > commit e8fd94239bd46e2c8b2ce44ef54455f7dd3c2ee3 > > Author: abrolag <willgodf...@musically.me.uk> > > Date: Tue Nov 2 17:40:44 2021 +0000 > > > > mlearn2 > > Modified padsynth 'apply' action so it only responds to value > 0 > > Paves the way for useful MIDI-learn - now added here. > > >However, it is damn hard to find out *why* this breaks the test. > >One thing stands out immediately, when I perform the test with the >debugger both with a build one change before and with this changeset: > >With the change, calling "APPLY" from a CLI script does no longer >invoke PADnoteParameters::applyparameters() > > >In the actual testcase "features/BasicPAD.test", the script is as follows: > > > set part 1 > > set ADD off > > .. > > set PAD on > > set profile Double > > set bandwidth 555 > > set waveform Chirp > > set APPLY > > / > > set test note 27 > > set repetitions 7 > > set duration 0.5 > > set holdfraction 0.9 > > execute > >Previously, this invoked the applyparameters() function twice: > >- once from "set PAD on" >- then a second time from "set APPLY" Found the cause of this. APPLY now needs a value of 1, whereas previously any value would set it, this presented a problem with MIDI learn. If someone (quite reasonably) learned a hardware push button or footswitch it would be applied twice, which on a large patch could cause a significant delay before the part became active again. However, when adding the change into the CLI I forgot to adjust both resonance and waveform versions. As your script is still at waveform level, the command was still sending a zero, so was ignored. This is easily fixed of course, but do you want me to do so now, or wait till you've checked the anomaly you've seen? >Now, with this change, the second call does not happen anymore, >which /is problematic/, generally speaking, since then the changes done >by the preceding CLI commands will not be applied at all, i.e. the PADSynth >runs with the old wavetables, which were built on the first invocation. > > >But this does not yet explain why the test fails; In fact, the test >/should/ still be fine. This is, because the TestInvoker re-seeds the >SynthEngine, and then explicitly invokes PADnoteParameters::applyparameters() >for all active PADSynth voices. Thus, after the "execute" from the CLI script, >in both cases the wavetable is re-built. When you say this is set explicitly how is this done? I remember (vaguely) when I originally made this available to the CLI I had to jump through hoops to get the CLI to be able to do this correctly :( >Just the fun fact is: the *created wavetables differ*. >And I could not find out yet /why/. > >Seemingly it can not be the phase randomisation. Because I can clearly >see that the PRNG state in both Yoshimi instances (before|after the change) >are absolutely identical. > >Also, the harmonics generated from the Oscil look the same, and seemingly also >the harmonic profile. The problem here is: this is a huge amount of data. The >Spectrum has 64k entries, and the harmonic profile has 256 slots. And there >is at least one Wavetable per octave. So this is like searching the notorious >needle-in-the haystack. > >Right now, without any additional rigging, I can not even know for sure >that the generated spectrum is 100% the same. It is only clear that after >the inverse FFT, the resulting wavetables differ (and thus I'd suspect >something somewhere in the spectra to be different too). > > >How can this happen? >This puzzles me. My suspicion is that there is still some state leaking >through from before re-seeding the Synth. And since before this re-seeding, >as explained above, the wavetable is not re-computed and thus differs, >something of that different state might be leaking into the test. > > >Bottom line > >- IMHO, when the CLI sends "set APPLY" the wavetables should be rebuilt > no matter what. The change in e8fd94239bd seems to have broken that > >- there is still state leaking through, even after calling > SynthEngine::setReproducibleState() > Basically this means, we haven't fully understood all details of how > state is managed in the PADsynth > > >-- Hermann > > > > >_______________________________________________ >Yoshimi-devel mailing list >Yoshimi-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/yoshimi-devel -- Will J Godfrey 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
