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?

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