Oh, oh. I don't think this is good!

For the opcodes to have INDEPENDENT entropy, they actually need to use the SAME generator -- the whole idea of the PRNG is that each sample is independent of the next! Using different generators for different opcodes would almost certainly introduce SUBTLE CORRELATIONS in the entropy which is just what we don't want!

That's why the designers of boost::random, etc., and every other PNRG-using software system usually try to use a static single generator somewhere to drive all the distributions and random variables. 

I think for Csound it's best to use one generator per instance of Csound.

Regards,
Mike

-----Original Message-----
From: Istvan Varga 
Sent: Oct 3, 2005 10:01 AM
To: csound@lists.bath.ac.uk
Subject: Re: [Csnd] Instrument Static Variables, Completely encapsulated instruments

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.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk