PiSampler
A multi-voice hardware sampler and synth built on a Raspberry Pi, played from a Cirklon sequencer, with granular playback, a vocoder, a formant 'singer' voice and chaotic modulation.
- Raspberry Pi
- Pure Data
- Python
- FastAPI
- Svelte
- JACK
- MIDI
What it is
PiSampler is a sampler I built to do the job an Octatrack or Blackbox would do in my hardware studio. It’s a small box with no screen that I play from a Sequentix Cirklon sequencer over MIDI. It has eight sample voices, each with granular or direct playback, tempo-synced loops, slicing, reverse, glide, filters, six types of saturation, and its own reverb and delay. It also has some voices you wouldn’t find on a stock sampler: a noise voice with 28 generators, a vocoder you can set to 8, 16 or 32 bands, a formant “singer” that steps through a syllable on each trigger, and a Lorenz-attractor chaos modulator that can drive 10 destinations. Everything is mapped to MIDI CCs, so the sequencer plays it and saves its state per step. A web UI on the local network is there for loading samples, managing presets and checking how the engine is doing.
How it works
-
Hardware: a Raspberry Pi 5 (8GB) with a Blokas Pisound audio/MIDI HAT. It takes MIDI over USB, DIN or network RTP-MIDI and outputs stereo audio.
-
Software: the audio engine is written in Pure Data (Pd) with the ELSE library. It runs as a cluster of Pd processes on JACK at a 64-sample buffer, about 4ms. A Python/FastAPI daemon looks after the sample library, presets, MIDI routing and a Svelte web UI. The daemon and Pd talk to each other over UDP.
-
The hard part, part 1: fitting the DSP on four ARM cores. One Pd process can’t run eight voices with all their effects. So the engine is split into three worker processes and a master bus, each its own JACK client, and the patches for that layout are generated by a Python tool. The first version added 58ms of latency because Pd buffers audio between processes. Switching every process to JACK callback mode brought trigger latency down to about 9ms.
-
The hard part, part 2: debugging audio on hardware you can’t see into. Silence or a click usually doesn’t tell you what went wrong. I built diagnostic and test tools to deal with that:
- a doctor that checks the whole chain, from the controller to the audio out, and names the first broken link
- probes for live signals and control messages
- spectral and pitch analysis of captured audio
- a static checker for the structure of Pd patches
- a test gate that runs on the device itself
The tools found bugs that listening never would have, including a file-descriptor leak in a C audio-loading external that left voices silent after enough sample loads.