| Pablo Silva-Escuela discussed the problem of the grain opcode running
from a pseudo random number generator which he could not change the
seed of.
Take a look at what I wrote about the various pseudo-random number
systems in Csound at the end of:
http://www.firstpr.com.au/csound/
In recent versions of Csound, the "x-class noise" opcodes and the
grain opcode all call an external "rand()" function which is provided
by the C library which Csound is compiled with. This could be a
simple 16 bit PRNG (Pseudo Random Number Generator) or it could be a
good 31 bit one. A 16 bit PRNG isn't much good, since its output
recycles every 65,536 numbers.
There is an init-time opcode already in Csound which enables you to
seed this external PRNG - simply:
seed 12345
where 12356 is the number you want to seed with. The integer
component of this passed to the C libary's seedrand function. If it
a 16 bit PRNG, then I guess that numbers up to 65535 would make
sense. If it is a 31 bit PRNG, then numbers up to about 2 billion
should do. This opcode prints out three decimal places of the seed
number, but they are irrelevant.
If the value you give to seed (which must be an init time, such as
an fixed number - not a k-rate variable) is 0, then the current date
and time is used to seed the C library's PRNG. Note that the output
of this PRNG could also be affected by other programs running on the
computer, which could be seeding the PRNG and taking numbers from it
- either of which would affect the numbers being returned to the
various points in Csound which call rand() to get pseudo random
numbers.
Searching through the source code, I find that the following opcodes
use rand():
All the "x-class noise" opcodes (but see my web site for how I
changed all these to work from a good 31 bit internal seedable
Park - Miller PRNG.
marimba (in modal4.c)
Also some or all of the physical modelling opcodes, since rand() is
called by the NoiseTick() function in physutil.c.
shaker in shaker.c
sndwarp in sndwarp.c
grain (in grain.c)
This "seed" opcode has been in Csound since 1994, but is not in the
manual - so you can use it to set the C library's PRNG.
If the C library rand() function with which your sound executable was
linked with only provides a 16 bit PRNG, then this may well be too
repetitiver for granular synthesis.
Pablo wrote:
> I've been experimenting a bit with the grain opcode, doing some low
> density synchronous granulations of soundfiles, and I have noticed that
> since I cannnot seed the pseudo-random number generator, my results
> (rather rythmic flashes of sound) always repeat the same
> granulation pattern... Can anyone suggest a workaround, short of
> calculating extra sound time and cutting/pasting with a sound editor?
I wouldn't expect this to happen unless the PRNG is set to the same
state every time you run Csound. Without knowing the details of the
C library with which your Csound is linked with, I can't say any more
- except that I agree that all pseudorandom data in Csound would
ideally (to my thinking) come from a single internal PRNG which can
be seeded with a fixed number or with the time of day. As you can
see, I have done this for the "x-class noise" opcodes in my recent
changes to cmath.c as noted at my web site, but you will need to be
able to compile Csound yourself, or use my Linux executable, to use
these.
BTW, I hadn't thought of this, but these changes affect gen 21 as
well.
> A suggestion to the Csound gurus: I don't know the first thing about the
> inner workings of the source code for Csound, yet from what I see on the
> list it seems to me that lots of us are using pseudo-random number
> generators for a variety of uses, some embedded into the opcodes (grain,
> etc) or as signal generators, and having some problems like mine of their
> actually not giving random enough results. Maybe a solution would be
> standarizing the way the opcodes deal with generating pseudo-random
> numbers (always providing a parameter handle for seeding) or better,
> having these opcodes in their inner workings refer to common, more
> reliable (a strange word to use about this!) generation routines, like
> the ones already incorporated in the opcode list?
Yes, but the ones in the opcode list are of three varieties. Firstly
there are the x-class noise ones that use the external C library's
rand() function. Then there:
rand, randh and randi
These are self-contained 16 bit PRNGs which can have their
seed set as an option. Each instance maintains its own
state. These are the oldest set of random number generators
in Csound.
The recently added irnd, ibirnd, krnd and kbirnd code in aops.c.
These are effectively a single,
self-contained PRNG, since the two functions rnd1( ) and
birnd1 ( ) both have the same algorithm and share the same
state - a double precision ( ie. 64 bit) floating point
number . The seed (rndfrac) is always set (to 0.5) at the
start of Csound running, so these ugens would always produce
the same sequence of numbers. There is no option for setting
the seed. The algorithm a simple floating PRNG and I don't
know anything about the quality of noise it produces.
So it is all rather messy.
I don't see the need for "irnd, ibirnd, krnd and kbirnd" - provided
that the x-class noise ugens use a common, good, seedable PRNG (which
my recent changes provide, together with a bipolar (ie -1 to +1)
uniform source, then I don't think these new ugens are needed.
rand, randh and randi
Each instance of these has its own seedable PRNG. Perhaps there are
some reasons for keeping this. It enables some musical parameters to
be "randomly" deterimined from a seed, while others are determined
from another seed. That way you could keep one set of "random"
things that you like, and change others independently.
If I was doing this from scratch, I would have a single 31 bit
internal, seedable PRNG, and make every pseudo random element of
Csound call this.
- Robin
===============================================================
Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au
Heidelberg Heights, Melbourne, Australia
First Principles Research and expression: music, Internet
music marketing, telecommunications, human
factors in technology adoption. Consumer
advocacy in telecommunications, especially
privacy. Consulting and technical writing.
Real World Electronics and software for music: eg.
Interfaces the Devil Fish mods for the TB-303.
=============================================================== |