Hello everybody,

I've made a post regarding random seed in the past, but I found that recently, it seems that the way random seed works in Pd has changed. For context, I've had a generative MIDI patch for a couple of months now, and each time I open it, I'm able to consistently get the exact same tone arrangement each time.

I don't know what happened, but when I open the exact same patch, I now get a totally different array of tones, and I'm not quite sure what happened. The patch is the same – but something changed and the tones are no longer the same. I know this is a vague issue to have without something more concrete, but I'm generally wondering whether anything did change in recent versions of Pure Data.

Does anybody know what might be going on?

@Maks Worth checking...... but very unlikely as changes that break objects for previous patches are frowned upon by the developers.... even when they could improve things.

It is most likely that you have opened another patch first, and that it also contains [random].
Unsure...... but every [random] created after the starting of Pd will be different...... but the same difference will occur for all of them after a fresh start of Pd.
David.

@Maks said:

I'm generally wondering whether anything did change in recent versions of Pure Data.

List of changes tagged with the word "random": https://github.com/pure-data/pure-data/search?q=random&type=commits

I haven't opened each one individually but they look like help patch changes, not functional changes, within the last 2 years.

How are you using the "seed" message?

hjh

Hi all, thanks for your responses.

I probably /should/ have generated a seed just for this patch so that I'm able to recall it again and again. I'm using random messages to create random note on/off messages + setting up parameters to alter note velocity. Otherwise, I'm not doing anything unique whatsoever – just good old "random" objects.

My process has been that I open up Pure Data and my VST of choice, then have the notes output right into the VST, producing sound. I'm absolutely confident I have no other patch open, as I literally quit out of Pd every time, a habit I formed because I didn't want some background patch to alter the arrangement of tones.

The patch has remained entirely unchanged for the last few months, and yet when I opened it last week, the note arrangement that was produced was entirely different. Not sure what this is about, but I suspect I lost that specific configuration somehow along the way.

@Maks Maybe try falling back to an earlier version of Pd?

@Maks As @jameslo says....... setting the patch to use a previous Pd version might work if a change has been made. The help file used to state "WARNING: nothing is known about the quality of the pseudorandom number generator." .... so very strange if it has changed.

You can try a compatibility message saved in the patch...... e.g.
[loadbang]
|
[;
pd compatibility 0.50(

BUT.... I luckily have a very! old [random] test patch with multiple [random] objects..... and I commented the values expected into the patch...
It is very strange.
There seems to be a shift......... the 2nd 3rd 4th etc. created are the same as the 1st 2nd 3rd etc. used to be.

You could make a copy of your patch, delete the [random] object, create a new one somewhere.... a dummy that you will not use, and then put a new [random] .... a second one....where you had it originally.
Keep the dummy [random] in the patch, save it and try starting the new patch.
I.e. insert a [random] in the creation order before the one you want to use.

The compatibility message doesn't seem to work and I had to go back to Pd 0.47 to have the same series as before.
That suggests a change as Pd went from 32-bit to 64-bit........ which could make sense....
David.

nothing in the implementation has changed.. also I don't think the size of unsigned int would change based on it being compiled for 32 vs 64 bit. usually 'long' is always 64 bit, regular 'int' is always 32 bit afaik

It's funny how people have different expectations: I'd consider it a bug that pd replicates the pseudo-random sequence at all upon relaunching. (It's quote-unquote "random" -- it should be different every time!)

hjh

@ddw_music said:

it should be different every time!)

One of my CS teachers would have disagreed because of issues like the OP is having. (He often argued that CS was in denial that it was engineering, not science--and he's rolling in his grave for my crappy paraphrasing) Instead of musical examples he would have cited Monte Carlo simulations used to expose bugs in code. How could you reproduce them (in order to study them) if the pseudo-random number sequence wasn't deterministic? It's about what's most useful.

@ddw_music actually, it is considered a bug if it's different every time you open pd. The rationale is that the behavior of a patch SHOULD be completely reproducible if desired (and that's the intent).

really, the meaning of the term 'random' mainly means having a certain statistical distribution. It doesn't necessarily mean 'different every time' or 'nondeterministic'. Even the term 'deterministic' is questionable: does it mean causal, or predictable? because any source of 'randomness' would be causal: chaotic doesn't necessarily mean non-causal.
Getting down to quantum systems things become a bit more controversial but imo simply not being able to make a prediction (determination) doesn't necessarily imply that some mechanical result didn't have a specific cause. (bohmian mechanics illustrates this)

@seb-harmonik.ar said:

The rationale is that the behavior of a patch SHOULD be completely reproducible if desired (and that's the intent).

@jameslo said:

How could you reproduce them (in order to study them) if the pseudo-random number sequence wasn't deterministic?

There might be exceptions, but in every pseudorandom number generator I've ever heard of, the sequence does repeat, provided that it's been seeded with a consistent value first.

SuperCollider seeds the random number generator at startup based on some value calculated from the system time. If you want replicable behavior, you do thisThread.randSeed = /* some value explicitly under your control */ at the moment of your choosing.

Pd [random] does implement a "seed xxx" message, so it isn't correct to suggest that Pd's constant initial seed is the way to get a replicable sequence. That's lucky if that's what you want, but it isn't necessary, and it may not be ideal either.

The problem with the counterargument here is that the [random] behavior depends on factors outside the user's direct control. If you really want a replicable sequence, the way to be certain of that is to send a "seed xxx" message to the random number generator at a moment that is under your control. Otherwise, you have no control over other components that might be pinging the random number generator. (Suppose, for instance, your patch depends on an abstraction which pings a [random] from a [loadbang]. Then, later, the abstraction author thinks, no, I shouldn't do that, I should get that first random value only on demand. Then you move your patch to another machine, re-download the abstraction from its source, and bang the behavior is different.) edit: that's a bad example, never mind.

Viewed from that perspective, one could say that the current Pd behavior misled the OP to believe that it wouldn't be necessary or desirable to control the seed... and then something changed somewhere in the system. That's actually quite a bad situation -- OP relied on happenstance for a mission-critical sequence of notes, and it isn't clear how to recover the original behavior.

Now this part is interesting, from whale-av: "There seems to be a shift......... the 2nd 3rd 4th etc. created are the same as the 1st 2nd 3rd etc. used to be." One possible explanation could be that, in the old version, something was consuming one random value before the user patch did (so the user patch never saw the true first value) -- so in the old system, the "first" random value would have been the second to be generated. Then, in the later case, the first value to be seen is the real first value. (But that might be -- or, is probably -- something in the test scenario and not in Pd itself.)

hjh

BTW [random] gets seeded this way:

static int makeseed(void)
{
    static unsigned int random_nextseed = 1489853723;
    random_nextseed = random_nextseed * 435898247 + 938284287;
    return (random_nextseed & 0x7fffffff);
}

So every [random] instance gets a new seed.

If you deleted and recreated a [random] object (this would happen if you edited [random 20] to [random 30] for instance), then upon the next load, it would be created later than it had been previously, acquiring a different seed and producing a different sequence. (And... explicitly seeding would override that.) It should be easy to reproduce that.

hjh

Still, the behavior of a patch is supposed to be consistent across different pd versions

1. Create a patch like this (creating the lefthand [random] first):
2. Save it as patch-A.pd.
3. Edit the lefthand [random] to be [random 101].
4. Then edit it back to [random 100] (note, do not ctrl-z undo here).
5. Save this as patch-B.pd.

23-0316-random-seq-A.pd
23-0316-random-seq-B.pd

Now, if you quit Pd, open patch-A, and click it at the top:

R: 92
R: 66
R: 10
R: 73
R: 38
L: 74
L: 56
L: 76
L: 48
L: 55

And quit, relaunch, load patch-B, and:

R: 74
R: 56
R: 76
R: 48
R: 55
L: 92
L: 66
L: 10
L: 73
L: 38

... whereupon L and R have switched value sequences.

Sure, these aren't the same patch, but the difference is invisible to the user, who would assume that they are the same and then assume that "something changed in Pd."

Still, the behavior of a patch is supposed to be consistent across different pd versions

No disagreement there, but the OP didn't actually say that a Pd version upgrade caused the problem. I'm starting to doubt that it's a Pd version thing.

hjh

@ddw_music I added a [bang] + [$0] + [number] to my patch just to check the order of abstraction creation, and saved it. Now it is consistent across Pd versions...... but with the new [random] sequence 2nd 3rd 4th (see my post above).
Conclusion..... something something nothing.
If I posted the original.... I probably did...... then I will check in a text editor this evening.
Certainly the patch window opens with different window coordinates in later versions..... a lot of whitespace at the top...... so "something" changed.
David.
P.S. Its a mess in a text editor.... window coordinates for every object have changed and the object ordering is all over the place..... to the point that I don't think I will be able to analyse the changes.....
So this evening I will start the patches and resave them in previous versions of wish..... maybe that is where the conundrum will be solved.

wish has nothing to do w/ patches getting saved in pd.. pd does that part on its own afaik