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"
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.
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
