| Michael Gogins wrote:
> Therefore, I regard the replacement with better generators to be a real
> improvement.
>
> I'd be happier if all the opcodes used the MT (with perhaps an option to
> use Whittle instead for slightly greater efficiency).
In fact, I did think about using the MT everywhere as a rand() replacement,
and not doing so (at least so far) is not only the result of performance
issues, but also trying to make the opcodes more independent by having more
than one single global generator. The problem with that approach is that
adding or removing opcodes elsewhere in the orchestra changes the output
of everything else that uses the global PRNG. So, it might be preferable
to have a private instance of the generator for every opcode, with the
possibility of seeding each one individually (although this is possibly
less convenient from the usage point of view than just setting a single
global seed); this is what is done for example in rnd31. On the other
hand, the MT consumes a lot of memory per instance, and the CPU usage
is uneven with occasional high peaks, so I found it preferable to have
only one global PRNG of this type. As a trade-off, the following now use
the global MT (controlled by the 'seed' opcode) for high quality random
numbers:
unirand, linrand, trirand, exprand, bexprnd, cauchy, pcauchy,
poisson, gauss, weibull, betarand, GEN21
while these are based on a global 31 bit generator that is also
initialized with the 'seed' opcode:
bbcut, grain, adsynt, phasorbnk, noise, shaker, sndwarp,
sndwarpst, ATSaddnz, ATSsinnoi, adsynt2, ~ (score operator)
also the various physical model opcodes (marimba, cabasa,
sekere, singwave, etc. - there are quite a few)
A third generator that is always seeded from the current time is
used in the widget opcodes that allow for randomly changing the style
of displayed widgets, as being able to reproduce the random sequences
is not very important in this case.
Using a 31 bit generator instead of rand() does have a disadvantage,
though, as rand() often has a longer period (usually 2^32 or more),
even if the least significant bits of the numbers returned by rand()
are not very random, but that is mostly not a problem for audio. |