pinponpanpon

A recipe is the asset.
A WAV is one render of it.

pinponpanpon is a local-first workshop and reusable sound-effect library for games. Every sound on this page was synthesised on a laptop from a small editable text file — no model, no sample pack, no GPU, no account. Re-run the recipe and you get the same bytes back.

A folder of downloaded sounds loses where each one came from, what you may do with it, and which of them belong together. A recipe keeps all three, and it stays editable long after any subscription lapses.

1 · A family is a performance, not a list

Sound libraries are auditioned one file at a time, which is exactly how a UI sound gets shipped and then becomes unbearable. This plays a family as a real interaction — hover, hover, confirm, … error — with human timing, bursts and overlaps. Two things become obvious that a file list can never tell you: whether these sounds are a family, and whether they grate at rate.

 

2 · Keep the family, change one member

The interaction the whole tool exists for. Pick a role, pull a perceptual axis, hear it against the version before. The family's shared seed and timbre are what keep it recognisably the same sound.

Every clip here was rendered by the real engine before this page was built — there is no synthesiser running in your browser. What you hear is exactly what pin render produces.

what this would write into the recipe

  






  
3 · Five families,  sounds

  

    ui-soft and ui-crisp perform the same six
    functions and share no timbre — that contrast is the answer to the obvious
    objection, that procedural synthesis makes everything sound like one
    oscillator at different pitches. A test asserts their brightness stays at
    least a factor of two apart, so it fails the build rather than being a
    matter of opinion.
  

  






  
4 · In context

  

    A click that is charming once can be intolerable on the fortieth hover.
    Hover the tiles, then run the stress test. Bounded — it fires a fixed number
    of events and stops.
  

  

    
    
    
  

  

  

  






  
5 · What is verified, and what is not

  

    

      
Measured

      

        Every sound is checked in the context it is for: a loop on its seam and
        on not starting with silence, a UI sound on onset latency and length, a
        one-shot on not being truncated. There is no blanket loudness target and
        no quality score — nothing computes one, so nothing reports one.
      

    

    

      
Not measured

      

        Whether any of this is good. That is a listening decision and
        no assertion in the repository substitutes for it. The library tracks it
        as a separate gate from the technical checks and from rights clearance,
        precisely because a sound can pass both and still be irritating.
      

    

    

      
Not published