Randomisation and Seeds

Randomisation and Seeds

FWG randomisation is repeatable. With the same released FWG version, effective seed, and settings, the same addressed random decisions can be reproduced.

🎹 Use this page for the practical questions: where the seed is, how to repeat a batch, and when changing it is useful. For tuple framing, named-draw paths, mapping rules, statistical qualifications, and forensic boundaries, go to Deterministic Randomisation — Technical Reference.

Where you can see a seed

🎹 Visible seed fields are provided in:

• Bulk Random
• Bulk Explorer

Playground and Morph endpoint Randomise actions also use deterministic named randomisation, but their next-action seeds are intentionally hidden so ordinary endpoint editing does not require extra seed controls.

The four randomisation domains are separate:

• Playground
• Morph
• Bulk Random
• Bulk Explorer

Using the same text in two different domains does not mean the domains make the same choices.

Repeating a Bulk Random batch

🎹 To repeat a Bulk Random search:

1. keep the same FWG version/build;
2. enter the same Seed;
3. use the same pool/preset and other effective Bulk settings;
4. use the same iteration numbers/directions;
5. export again.

If the effective inputs are the same, the addressed random decisions repeat.

A useful workflow is to record the seed before changing it. Exported JSON sidecars also preserve the generation context needed for reconstruction.

Repeating an Explorer batch

🎹 Explorer uses the same idea, but its result also depends on the current source state and variation rules.

To repeat a previous Explorer search most reliably:

1. load the saved Explorer recipe/result JSON that restores the intended centre and rules;
2. restore the same seed;
3. export the same iteration range.

Changing only the seed searches a different set of candidates under the same Explorer rules.

That makes an Explorer recipe useful as a personal search preset. See Auditioning, Curation, and Building a Personal Library.

When to change the seed

🎹 Change the seed when you like the kind of search but want different candidates.

Do not change the seed merely because one individual result is weak. If the whole batch is systematically wrong, first change the search settings or variation rules. A new seed explores a different lottery; it does not repair a poor search definition.

Default generated seeds

🔧 Bulk Random and Explorer generate 26-character lowercase Base32-style tokens using:

abcdefghijklmnopqrstuvwxyz234567

The default token namespace is 130 bits wide (32^26 = 2^130). The browser obtains the random bytes from crypto.getRandomValues().

You do not need to use the generated form. The seed field accepts ordinary user text up to 128 UTF-8 bytes.

Case, punctuation, internal spaces, and Unicode representation can matter. The UI trims leading/trailing whitespace; an empty committed value generates a fresh default seed.

A seed is not the whole patch

⚠️ A seed does not mean “this sound is encoded in 26 characters.”

The result also depends on things such as:

• FWG version/build;
• randomisation domain;
• pool/profile;
• iteration and named draw paths;
• fixed settings and choices outside randomisation;
• Explorer source state and variation grammar;
• render direction and other effective inputs.

That is why JSON sidecars are the preferred reconstruction record.

Why FWG uses named random decisions

🔧 FWG does not use one fragile sequential PRNG stream where inserting a new random choice would shift every later result.

Instead, important decisions are addressed by names/paths and hashed with the seed and randomisation domain. This makes unrelated choices less likely to disturb one another and makes diagnostic evidence easier to interpret.

The exact technical contract is versioned. Do not assume a seed alone must reproduce the same result in every future FWG release.

What seeds can prove

⚠️ A seed can be useful evidence of reproducibility:

Given this FWG version/build and these effective inputs, the disclosed seed is sufficient to regenerate the recorded random decisions.

A seed does not by itself prove:

• who created the result;
• when it was created;
• that the supplied JSON is historically authentic;
• that no modified executable was used;
• that the user had no prior target in mind.

For ordinary sound-design work, this distinction rarely matters. For forensic/reproducibility questions, see:

• Proof of Zero Prior-Work Knowledge and Forensic Evidence
• Authenticating and Timestamping FWG Outputs

Good seed habits

🎹 For work you may want to return to:

• keep the JSON sidecar;
• keep important Explorer recipes;
• use descriptive filenames for the sound/use, not the seed;
• record or preserve the seed when a batch is worth repeating;
• do not expect a seed from a different FWG version to override compatibility differences.

Related pages

• Bulk Random
• Bulk Explorer
• Saving, Loading, and JSON Sidecars
• Deterministic Randomisation — Technical Reference