Channel Strip
A channel strip is one track's lane in the mixer. It is the column of controls that processes a single part, such as a vocal, bass, or drum bus, before it reaches the master.
The processing order matters. Once you know the order, it becomes much easier to predict what every control does.
This page goes deeper than Mixing Basics and grounds the model in libsonare's ChannelStrip.
The fixed signal order
libsonare processes each block of a strip in one fixed order. Reading it top to bottom explains most "why did that control behave like that?" questions:
- Input trim: a clean level adjustment on the way in, before anything else sees the signal.
- Polarity invert (L/R): flips the waveform; used to fix phase between mics or channels.
- Channel delay: time-aligns the track against others. It is set in whole samples (
setChannelDelaySamples, scene fieldchannelDelaySamples); there is no millisecond form, so convert yourself. - EQ: tone shaping, always before the fader (see below).
- Pre-fader inserts: in-series processors that run before the fader.
- Fader (+ VCA offset): the balance control you ride against other tracks.
- Pan: places the track across the stereo field, using the chosen pan mode and pan law (the pan law sets how loud the center is compared with the sides).
- Stereo width: narrows or widens the stereo image.
- Post-fader inserts: in-series processors after the fader.
- Meter / goniometer tap: measurement, not processing. The goniometer is the dot-plot display that shows how wide the stereo image is.
Why the order matters
The order is not cosmetic. It changes what each processor hears.
| Placement | What happens |
|---|---|
| Compressor before the fader | It reacts to the raw level and keeps reacting the same way as you move the fader |
| Compressor after the fader | It reacts to your balance moves |
| Pre-fader send | It taps before the fader, so it is independent of the mix balance |
| Post-fader send | It follows the fader, so the effect stays proportional as you ride the level |
Picking the wrong tap point is one of the most common routing mistakes.
EQ position
The EQ runs pre-fader, so it shapes the tone that the inserts and fader then act on. The C++ ChannelStrip can move it post-fader with set_eq_position, but scene JSON and the language bindings always run it pre-fader. In a scene the EQ is the strip's eq field (see Mixing Scene JSON).
Cue monitoring: PFL and AFL
Sometimes you need to hear one track in isolation without disturbing the mix everyone else is hearing — checking a vocal for breath noise before a show, or auditioning a track while the room keeps listening to the main output. That is cue monitoring: a separate tap that feeds a headphone or monitor bus alongside the regular mix, not instead of it.
The cue stays separate only when you ask for it. The realtime engine's plain process(...) adds the monitor bus into the main output, so a cued lane is heard twice there (and a muted lane under PFL is heard at all). Use processWithMonitor(...), or create the worklet node with cueOutput: true, to get the program and the cue as two outputs. Offline renders, bounces and freezes never include the cue. See Track monitor taps.
In the realtime engine a track lane has two gain layers. First comes the lane's own strip, the full chain on this page with its own trim, fader, and pan. After it, the lane mixer applies a lane fader, the mute/solo gate, and a lane pan. The cue taps sit between and after those layers.
PFL (pre-fader listen) taps the signal after the lane strip (including the strip's own fader) but before the lane fader, gate, and pan, so a PFL cue stays audible even when the track is muted, gated, or panned away — useful for checking a source's raw content regardless of where the fader sits. AFL (after-fader listen) taps after those stages instead, including the surround path, so it reflects the same level and placement the track is actually contributing to the mix.
How libsonare schedules a cue tap
Cue monitoring is a queueable realtime command: setTrackMonitorMode(laneIndex, mode, renderFrame?) on RealtimeEngine (EngineTrackMonitorMode = 'off' | 'pfl' | 'afl'), mirrored in the C ABI as sonare_engine_set_track_monitor_mode (SonareEngineTrackMonitorMode) and exposed in Python as set_track_monitor_mode. It is reachable from the WASM AudioWorklet path the same as any other engine command, and process(...) folds the monitor bus into the engine's regular output, while processWithMonitor(...) returns it as a separate output and leaves the program unchanged.
How libsonare models a strip
A strip is a ChannelStrip configured by ChannelStripConfig. A block is processed in this order:
trim -> polarity -> channel delay -> EQ -> pre-fader InsertSlot
-> fader with VCA offset -> PannerProcessor
-> StereoWidthProcessor -> post-fader insertsEqPosition (C++ only) chooses whether the EQ runs pre- or post-fader; PannerProcessor takes the strip's PanLaw/PanMode. TapPoint marks where pre- and post-fader sends and the GoniometerBuffer/MeterProcessor read the signal. All gain and pan changes are parameter-smoothed and the path is real-time-safe (pre-allocated, denormal-guarded), so the same strip runs offline and inside an AudioWorklet.
Related: Mixing Basics, Buses and Sends, Pan and Stereo Width, Realtime Engine, Mixing Engine