Bounce and Rendering
You have arranged your clips, comped your takes, and warped your loops to the grid. The last step is turning that living arrangement into a single finished audio file you can share. That step is called bouncing (or rendering).
One-line definition
Bounce / render = compute the whole arrangement into a finished audio buffer, offline and deterministically.
Offline and deterministic
Bouncing is offline: it does not have to run in real time. It can run faster than real time on a quick project, or slower than real time on a heavy one. The goal is correctness, not keeping up with the clock.
Offline rendering removes timing jitter and dropouts, and the engine has no random state, so it is also deterministic: on the same build and runtime, the same project plus the same options plus the same instrument always produce the same audio, sample for sample. (A different runtime or platform can differ in the last bits of floating-point rounding.) This is exactly why you bounce a final master from the offline path rather than recording your speakers.
Bounce is not "record the output"
A bounce reconstructs the arrangement from its edit model and renders it cleanly. You are not capturing a live performance of the project; you are computing it, which is why it is repeatable and free of dropouts. Any artifacts the edits themselves introduce (a large stretch, a hard splice) are rendered just as they sound in playback.
The mix is rendered through the mixer scene
A common beginner assumption is that a bounce just adds all the tracks together. It does not. The arrangement is rendered through the mixer scene, so the finished file reflects your full mix.
That means each track passes through its channel strip (its EQ, dynamics, gain, pan), its sends feed shared effects, and everything sums through the buses on the way to the master — exactly as it would when you mix. The bounce is the mix, not a raw sum of clips. See Mixing for what lives on a channel strip.
The signal path below is identical to what you hear during live playback — bouncing simply captures it to a file instead of an audio device.
MIDI tracks need an instrument at bounce
Recall from Clips and Tracks that a MIDI track holds notes, not sound. So at bounce time you must tell the renderer which instrument performs those notes. libsonare gives you several entry points:
| You want… | Use |
|---|---|
| The full patch-driven synth | bounce with the NativeSynth instrument |
| A General-MIDI SoundFont | bounce with the SoundFont instrument |
| A quick built-in oscillator | bounce with the built-in instrument |
| Your own external instrument (Python, JavaScript) | bounce with host-provided instruments |
If you bounce without binding an instrument, MIDI tracks render silently — the notes are there, but nothing is performing them. Audio tracks always render their sound regardless. See NativeSynth for the synth side.
Length is auto-derived (unless you set it)
You usually do not need to specify how long the bounce should be. If you omit the length, it is auto-derived from the timeline — the renderer finds the end of the last clip, plus the longest instrument release tail (the extra time a note needs to ring out and fade after it ends), plus the mixer's own latency and effect tail (a reverb or delay insert keeps sounding after its input stops). So a final reverb or a long synth release is not cut off mid-decay. You only set an explicit length when you want to force a specific duration.
Latency compensation (PDC)
Some instruments and effects introduce latency: they need a few samples of lookahead before they can produce output, so their sound comes out slightly late. If nothing corrected for this, a latent instrument would drift behind the rest of the mix.
The fix is latency compensation, also called PDC (plugin delay compensation). You tell the bounce how many samples of latency the instrument adds, and the step that turns your arrangement into samples (the compile step) shifts the timeline so that instrument lines back up with everything else. The result stays perfectly in time. The bounce renders the reported latency ahead and drops it, so the first sample of the result is the start of the timeline and nothing needs trimming afterwards.
Match the number to the real latency
PDC only works when the latency figure you provide matches what the instrument actually introduces. Too small and it still drags; too large and it leads. When in doubt, query the instrument's reported latency rather than guessing.
How libsonare implements this
Bouncing starts from the Project class. The plain bounce(options?) renders audio tracks and leaves MIDI tracks silent. To make MIDI audible you bind an instrument: bounceWithSynthInstrument (the patch-driven NativeSynth, accepting a SynthPatch, a preset name, or an array), bounceWithSf2Instrument (a GS-compatible SoundFont player using data loaded by loadSoundFont), and bounceWithBuiltinInstrument (the simple oscillator synth); bounce_with_instruments in Python and bounceWithInstruments / bounceWithInstrument in JavaScript let you host your own external instrument. When totalFrames is omitted (or <= 0) in ProjectBounceOptions, the render length is auto-derived from the arrangement plus the instrument's release tail plus the mixer scene's latency and effect tail. Every bounce renders through the mixer scene — per-track channel strip, sends, and buses — rather than summing clips. Latency compensation is supplied via instrumentLatencySamples in the bounce options and passed to the compiler so a latent instrument stays in time. The whole render is deterministic for a fixed project + options + instrument.
Related: Project Bounce, NativeSynth, Warp and Tempo Sync