Question about randomness

DSP, Plug-in and Host development discussion.
Quick
KVRer
9 posts since 30 Sep, 2016

Post Fri Jul 10, 2020 2:31 pm

I am developing an effect plugin that utilizes a random modulation component. I am using the c++ standard library pseudo-random number generator to get randomness. I am currently seeding srand with the current time in the plugin constructor to get variations in the pseudo random number sequences.

I am wondering about alternative sources for seeding the pseudo random number generator that would result in deterministic playback, since my current implementation gives a different output each time the project file is played. Short of having a user parameter for seed value, has anyone done something like this? What is a good source to use for a seed?

xoxos
Mr Entertainment
12207 posts since 30 Apr, 2002 from i might peeramid

Post Fri Jul 10, 2020 5:15 pm

scuse me for forgetting the exact title, hal chamberlin's classic text on music and microprocessors

lists a very efficient operation for unsigned ints of various lengths, which loops though all the values contained in the bit depth.

i am on another computer but if it isn't returned under that info, check teh thread in my forum for universe, download the source, and search for the line with rnd = something something
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

matt42
KVRian
1201 posts since 9 Jan, 2006

Post Fri Jul 10, 2020 9:30 pm

https://www.musicdsp.org/en/latest/Synt ... rator.html

Your description reminded me of this. Having checked it turns out that it is the Hal Chamberlin method

User avatar
nix808
KVRAF
4286 posts since 22 Jul, 2006 from Tasmania, Australia

Post Fri Jul 10, 2020 10:00 pm

noise might be pretty random

User avatar
BertKoor
KVRAF
12046 posts since 8 Mar, 2005 from Utrecht, Holland

Post Fri Jul 10, 2020 10:28 pm

The book is "Musical Applications of Microprocessors" by Hal Chamberlin.

Random is random. By definition.

I don't think it's unreasonable to require the user to print the output to wav or freeze the track when repeatability is required. For sample&hold on filters for example that would not be unreasonable.

Maybe for your use case it's more desirable. You could make repeatability an option. Store the random seed in a patch, base it on elapsed ticks in the project. But then you get complaints why things change if a part is moved.
We are the KVR collective. Resistance is futile. You will be assimilated. Image
My MusicCalc is back online!!

matt42
KVRian
1201 posts since 9 Jan, 2006

Post Fri Jul 10, 2020 10:38 pm

If you want it deterministic then just choose a constant initial seed (there was an old side scrolling game that was proceduraly generated to same ram. The level layouts were the same each run through though due to a fixed seed which gave the impression that the layouts had been designed). Otherwise, for non deterministic, use time or whatever as the initial seed. I know some plugins with random processes allow user input for seeds.

Edit: I guess the issue for a deterministic system is how to handle transport starting at time locations other than 0. Perhaps a large repeating table makes sense in such an application

User avatar
nix808
KVRAF
4286 posts since 22 Jul, 2006 from Tasmania, Australia

Post Fri Jul 10, 2020 11:00 pm

BertKoor wrote:
Fri Jul 10, 2020 10:28 pm
Random is random. By definition.
- that is I guess ultimately,
but in practice we can sample FM or PM/PD noise
which can appear random I'm sure,
however with phase resets it may become looping

I think you could prolly could make truly random noise somehow in the box
-or is it bound to become cyclical eventually(not 100% sure)

matt42
KVRian
1201 posts since 9 Jan, 2006

Post Fri Jul 10, 2020 11:11 pm

Deleted

User avatar
syntonica
KVRian
644 posts since 25 Sep, 2014 from Specific Northwest

Post Sat Jul 11, 2020 1:20 am

Depending on how you use random numbers, if you require reproducible randomness, you may need to just keep a table of random numbers, perhaps generated per project.

mystran
KVRAF
5760 posts since 12 Feb, 2006 from Helsinki, Finland

Post Sat Jul 11, 2020 2:07 am

matt42 wrote:
Fri Jul 10, 2020 10:38 pm
Edit: I guess the issue for a deterministic system is how to handle transport starting at time locations other than 0. Perhaps a large repeating table makes sense in such an application
Forget the tables. The solution is to throw the recursive PRNGs into the recycle bin and instead take some deterministic set of state (eg. sample position, voice number, generator ID), pack it into an integer and use some decent integer hash function (eg. one of these https://github.com/skeeto/hash-prospector).

It's fast, the quality is great as long as the hash-function is good (ie. has low bias), it gives you full random access and the whole thing is embarrasingly parallel (eg. great for GPUs too). I would argue that even if you don't want reproducible results, just hashing a counter is usually superior to the average cheap PRNG.
Please just let me die.

User avatar
S0lo
KVRian
774 posts since 31 Dec, 2008

Post Sat Jul 11, 2020 3:05 am

Quick wrote:
Fri Jul 10, 2020 2:31 pm
I am wondering about alternative sources for seeding the pseudo random number generator that would result in deterministic playback, since my current implementation gives a different output each time the project file is played. Short of having a user parameter for seed value, has anyone done something like this? What is a good source to use for a seed?
A user parameter (as you already mentioned) would probably be the most effective. Doesn't have to be an integer. You can let the user dial a knob then scale the 0 to 1 value to any integer range you want.

Quick
KVRer
9 posts since 30 Sep, 2016

Post Fri Jul 17, 2020 7:38 am

Thanks everyone for the suggestions!
matt42 wrote:
Fri Jul 10, 2020 10:38 pm
Edit: I guess the issue for a deterministic system is how to handle transport starting at time locations other than 0.
This is the problem I couldn't wrap my head around, and which mystran's suggestion solves very nicely. For my particular use case, I have realized it gets too complicated to expect to achieve deterministic playback (just due to the nature of the process I have implemented). BUT, this type of hashing seems very cool and will definitely be something I keep in mind, so thanks mystran!
BertKoor wrote:
Fri Jul 10, 2020 10:28 pm
I don't think it's unreasonable to require the user to print the output to wav or freeze the track when repeatability is required.
Philosophically, I agree with this, but it bothered me that I couldn't think of a good way to make repeatability an option :hihi:

Return to “DSP and Plug-in Development”