Csound Csound-dev Csound-tekno Search About

Re: Instrument Static Variables, Completely encapsulated instruments

Date2005-10-03 00:21
From"Michael Gogins"
SubjectRe: Instrument Static Variables, Completely encapsulated instruments
I repeat, I do NOT think it can fairly be said that Csound had well-defined 
behavior regarding random number generators, because C itself lacked such 
well-defined behavior.

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

Regards,
Mike

----- Original Message ----- 
From: "Istvan Varga" 
To: 
Sent: Sunday, October 02, 2005 6:55 PM
Subject: Re: [Csnd] Instrument Static Variables, Completely encapsulated 
instruments


> jpff@codemist.co.uk wrote:
>
>> Similarly I am not really happy about changing random number generator.
>
> While I did already replace rand(), given that there are not really
> many comments on this issue I may consider restoring that too.
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 

Date2005-10-03 15:01
FromIstvan Varga
SubjectRe: 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.