Why is everyone saying that a more random rand would break every old
orchestra out there?  The range of numbers would be identical.  Yes, you
would get a different sequence of random numbers than you did with the
old rand.  But you already get a different sequence with the existing
rand if you render on different platforms.  If your old orchestra relied
on rand not being random, its already broken and you can fix it by
storing the "random" values that you want in an ftable.  So I see no
reason why rand should default to the current definitely NOT random behavior.

-- 
Mike Berry
mikeb@nmol.com
http://www.nmol.com/users/mikeb

At 21:11 1998-11-10 , Matt wrote (and someone agreed):
>old rand.  But you already get a different sequence with the existing
>rand if you render on different platforms.  

Is that really so? Nowhere in Ugens4.c is the C function rand() called,
instead it looks like an in-house algorithm is used (short integer
rand = rand * 15625 + 1). 

However, the non-uniform or "x-class noise" random opcodes (trirand, 
betarand, cauchy etc in file cmath.c) call the standard C library function, 
so here the argument holds. Also they haven't been around for as long 
and they have just changed names, so nothing stops us from changing 
their functionality.


So, my vote is:

Don't change rand/randi/randh, (or at least make the old version the default 
if an optional is added). 

Instead, change the implementation of uniform() in cmath.c (which is used
by all the "x-class noise" opcodes) to use some 31-bit random function. 
This will make the output of those opcodes cross-platform identical. If we 
want 63- or 1023-bit versions of random later, an option could be added 
when the time comes (or a dummy option now, for maximum confusion).
Note that this will affect GEN21 too, since it uses the x-noise opcodes
internally.

Perhaps an "iseed" option should be added at the same time if people 
like that, no strong opinion there. 

(Aside:
There is the undocumented opcode "seed", but this might as well stay 
undocumented: Unless I've misread the code in cmath.c, it looks like the 
last instance of seed (the one appearing in the highest-numbered instrument) 
will init all x-class noise opcodes on a global level, so you couldn't presently 
tweak  two x-noise opcodes in the same orchestra independently. 
Further, if you add another x-noise opcode to any instrument, all instances 
of these opcodes will have their pseudo-random sequences changed, since 
they all end up calling the same ANSI C function. This would make the present 
"seed" of limited use. 
)

Regards,

	rasmus ekman