Auditioning Curation and Personal Library

Auditioning, Curation, and Building a Personal Library

FWG can generate far more material than you should keep. The useful work after generation is deciding what has a job, what needs one small repair, and what is worth being able to find again.

The workflow is especially useful after Bulk Random and Bulk Explorer, but it applies equally to deliberate Morph designs.

The curation loop

1. Generate a small search batch.
2. Audition in the context that matters.
3. Classify by possible use, not only good/bad.
4. Keep the JSON sidecar for anything promising.
5. Open near-misses in Morph or Explorer and change one thing at a time.
6. Re-render and compare.
7. Archive the keeper, its sidecar, and any reusable Explorer recipe.

Random generation is search, not a finished-content machine. Bulk controls choose which part of FWG's sound space to search; curation decides what becomes an instrument, sample, template, or starting point.

Start small before scaling a search

A tiny batch can make a good pool look bad by chance. A huge batch can bury a systematically bad setup under hundreds of files.

A better rhythm is:

• render a small batch;
• listen for the overall direction;
• adjust pool, Morph settings, geometry, or cleanup if needed;
• only then increase iteration count.

If nearly every file has the same unwanted quality, change the search rather than trying to curate around it.

Audition for a possible role

🎹 Do not force every result into keeper/reject. A failed clean wavetable may be excellent raw material.

Useful role labels include:

• oscillator;
• wavetable;
• bass layer;
• pad;
• drone;
• hit/impact;
• riser/faller;
• transition;
• noise/glitch layer;
• granular source;
• resampling source;
• technically interesting but musically weak;
• template/search starting point.

The point is to remember why you kept the file.

Audition in the destination context

For important candidates, listen:

• quietly and at normal working level;
• over the pitch range you expect to use;
• as ordinary linear audio;
• in the target wavetable synth or sampler;
• with the target's Position/XFade/interpolation settings;
• through the filters, envelopes, distortion, or effects you expect to use.

For strict wavetable work, the destination instrument is the final judge. See Creating Wavetables.

Keep JSON with every promising result

The WAV tells you what you heard. The JSON tells FWG how to reconstruct it.

A sidecar can restore or explain START/END generators, taps, Wavetable Types, Morph mode/curve, render geometry, random pool/seed data, cleanup, custom Drawn data, custom Scanning recipes, and safety/diagnostic evidence where present.

For anything you may reproduce or refine, keep the sidecar with the audio. See Saving, Loading, and JSON Sidecars.

Improving a near-miss

A near-miss is often more valuable than another broad search because most of the design already works.

1. load the result JSON into Morph;
2. audition START, END, Forward, and Reverse where useful;
3. identify the weakest stage;
4. change one factor;
5. re-render;
6. compare with the original;
7. keep the improved sidecar;
8. send the keeper to Explorer if you want relatives.

Good one-factor changes include one endpoint generator/tap, Wavetable Type, Morph mode, Curve Amount, Cycle-stepped transition, Phase-Coherent Mode, filtering/modulation, cleanup, or geometry.

Changing one thing at a time turns refinement into information rather than another random search.

Use Explorer to turn one keeper into a family

Bulk Explorer is the natural next step once a result is close. Define what may vary and by how much, then search around the current patch instead of starting over.

Useful applications include:

• related basses;
• variants of one wavetable character;
• restrained pad families;
• alternate transition intensities;
• velocity/vector layers;
• candidates for one sampler zone.

Explorer's current value is the centre. Its allowed variation defines the neighbourhood.

Explorer recipes as personal search presets

An Explorer recipe stores a search neighbourhood, not merely one patch.

Reuse the same seed to reproduce a batch, use another seed to search the same neighbourhood again, narrow variation for conservative relatives, or widen it for more adventurous ones.

Descriptive filenames beat parameter dumps. Explorer itself writes recipe_<File Stem>.json.gz; after that, rename the file according to the sound or search purpose you actually discovered. The detailed settings already live inside the JSON, so the wiki does not prescribe fictional preset names.

A practical library layout

There is no required structure. The following is a suggested library layout, not a production FWG directory contract:

FWG-Library/
├── Audio-Keepers/
│   ├── Wavetables/
│   ├── Drones/
│   ├── Hits/
│   └── Transitions/
├── JSON-Sidecars/
├── Explorer-Recipes/
├── Templates/
├── Rejected-but-Interesting/
└── Notes/

Use categories that match your own work. The goal is easy reconstruction and reuse, not taxonomy for its own sake.

Name by use, not by every parameter

Name files by the use you actually hear in them rather than trying to encode every parameter in the filename. JSON is already better at preserving exact settings.

When to stop refining

A technically strange result does not need correction if the strangeness is why you like it. A technically clean result does not deserve library space merely because it passes every check.

Does this result have a use that I can recognise and find again later?

If yes, it has earned a place.

Related pages

• Bulk Random — broad search.
• Bulk Explorer — controlled local variation.
• START→END Morph — deliberate refinement.
• Saving, Loading, and JSON Sidecars — reconstruction and import.
• Creating Wavetables — auditioning specifically for wavetable use.