Recently I was surprised hw little change the LFO randomness did.
I'd expect the full Frequency Randomness to cause every single LFO cycle to have a different length. Making the output very irregular, but it olny seemed to cause one of 30 cycles to change it's shape, and then it's back to normal.
You can see (and hear) what I'm talking about in this video:
https://youtu.be/wYXi0jx_t14?t=4m41s
Reading through the source, the constructor has lfofreqrnd which is
0.0 to 4.0 with a non-linear scale.
In one of the later routines I see:
incrnd = 0.5^freqrnd + RND*(2^freqrnd - 1) // between 1/16 and 16
and in the phase increment step I see:
tmp = (incrnd * (1-phase) + nextincrndphase) //linear interpolation
between the two different random frequency terms
phase += phaseInclimit(tmp, 0, 1) //from what I can see with
incrnd/nexincrnd the limit expression should always yield tmp
So, the outermost range seems reasonable, but I'm guessing most random
events are either not large, or a high frequency random value is
followed by a low frequency random value and the interpolation cancels
the two out. I assume something closer to brownian motion would work
as a better model as it would make more extreeme values more likely
and temporally adjacent events would be less likely to cancel each
other out. Now the problem is testing it out and seeing how the
modified behavior should coexist with older instruments.
Yes, breaking backward compatibility is always a pain.
I have an idea:
The old mechanism could be kept around for backwad compatibility, and the new one would be written to XMZ/XIZ file with a diferent name: "freqrnd_2" instead of "freqrnd" or something similar.
The idea is to make the old Zyn instances ignore this.
Also if Zyn-Fusion finds "freqrnd" marker it uses the legacy algorithm, if there's a "freqrnd_2" it uses the new algorithm.
Could this work?
Closing as this appears to have lost momentum. Ping the issue if you want it to be possibly migrated over to the github tracker.