spotify/pedalboard: Studio Effects as Python Objects
🎛 🔊 A Python library for audio.
At a glance
- What is it?
- Pedalboard wraps C++ audio processing in a Python interface, letting you chain built-in effects or load VST3 and Audio Unit plugins without a DAW. The trade-off is a GPL-3.0 licence and a dependency on platform-specific plugin formats.
- Who is it for?
- Adopt pedalboard if you need scripted, repeatable audio effects inside a Python pipeline, particularly for data augmentation or batch processing where a DAW would be impractical. Do not adopt it if your project cannot ship under GPL-3.0, or if you need a plugin format it does not host.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What pedalboard replaces in an audio pipeline
The README frames pedalboard as a way to add effects to audio without using a Digital Audio Workstation. That is the concrete problem: a DAW is an interactive tool, and interactive tools do not fit into a batch job or a training loop. Pedalboard exposes the same category of processing (chorus, reverb, compression, pitch shifting) as Python objects that can be constructed, chained, and applied programmatically.
The intended audience is stated directly. Spotify's Audio Intelligence Lab built it to use studio-quality effects from Python and TensorFlow, and the README says it is used internally for data augmentation and to help power features like AI DJ and AI Voice Translation. That points at machine learning engineers and audio researchers more than at musicians. A researcher who wants to apply a random reverb to ten thousand clips needs a library, not a plugin window.
The Pedalboard object and how effects chain
The core abstraction is a container. The README's quick start constructs a Pedalboard from a list: Pedalboard([Chorus(), Reverb(room_size=0.25)]). Each effect is an instance with its own parameters, and the board holds the ordered chain. Processing is then a single call on the board rather than a sequence of manual steps.
Audio I/O lives in a separate module, pedalboard.io. The example opens an input with AudioFile('some-file.wav') as a context manager, then opens an output with AudioFile('output.wav', 'w', f.samplerate, f.num_channels), passing the source's sample rate and channel count to the writer. The README's example reads one second of audio at a time, which is the streaming pattern the library is designed around. The documentation also describes on-the-fly resampling of files and streams with O(1) memory usage, and an AudioStream class for live effects.
Underneath, the project is C++ with pybind11 bindings, and it is built on JUCE, the same framework used for plugin development. That explains the VST3 and Audio Unit support: the host code is not a reimplementation, it is the same plugin infrastructure the audio industry uses. The README also claims the library releases Python's Global Interpreter Lock so multiple CPU cores can be used without multiprocessing. That is a design claim about the binding layer, not something visible in the API surface.
Installing pedalboard and loading third-party plugins
Installation is a single command from PyPI: pip install pedalboard. The README states that platform wheels are published, so no compiler is required on supported systems. For newcomers it points to INSTALLATION.md in the repository.
Plugins are loaded with pedalboard.load_plugin, which the README lists as supporting VST3 instrument and effect plugins on macOS, Windows, and Linux, and Audio Units on macOS. The README does not give a code example for load_plugin in the excerpt provided, so the exact return type and parameter names should be checked against the API reference at spotify.github.io/pedalboard before you build around it.
Platform coverage is uneven in ways worth noting. Linux wheels are built for x86_64 and aarch64 as both manylinux and musllinux, and the README warns that most Linux VSTs require glibc greater than 2.27. macOS wheels cover Intel and Apple Silicon. Windows wheels are amd64 only. The README states the library is tested with Python 3.10 through 3.15, which is a wide window, but the plugin testing story differs by platform: Linux and Windows are tested automatically on GitHub with VSTs, while macOS Audio Units are described as tested manually.
Where pedalboard is the wrong tool
The licence is the first constraint. Pedalboard is GPL-3.0. If you are building a closed-source product that links against it, the licence terms apply to your distribution, and that is a decision for your legal team rather than a technical one. For internal research scripts the question rarely arises; for a shipped application it frequently does.
The second constraint is format coverage. VST3 covers macOS, Windows, and Linux. Audio Units cover macOS only. If your processing depends on an AU-only plugin and you deploy on Linux, pedalboard cannot host it. There is no mention of VST2, AAX, or CLAP support in the material provided, so if your toolchain is built around one of those, this is not the library for you.
The third is scope. Pedalboard is a processing and I/O library. It is not a DAW, it does not provide a timeline, and it does not do MIDI sequencing or arrangement. The built-in effect list is deliberately conventional: chorus, distortion, phaser, clipping, compressor, gain, limiter, filters, convolution, delay, reverb, pitch shift, plus GSM and MP3 compression, resampling, and bitcrush. If you need spectral editing or time-stretching beyond PitchShift, you are looking at a different tool. The README's speed comparisons (300x faster than pySoX for single transforms, 4x faster than librosa.load for reads) come from the project's own materials and describe specific benchmark conditions, not general throughput.
How pedalboard differs from librosa and pySoX
The most obvious alternative for Python audio work is librosa, and the README itself benchmarks against it on file reading. The difference in approach is architectural. Librosa is a pure-Python and NumPy/SciPy library oriented toward analysis: loading audio into arrays, computing spectrograms, extracting features. Its effects are implemented in Python and operate on arrays you already hold in memory.
Pedalboard is oriented toward rendering. The C++ core processes audio through a plugin graph, and the I/O layer streams files in chunks rather than loading them whole, which is what the O(1) memory claim refers to. For a pipeline that reads a file, applies a chain, and writes a file, that distinction matters at scale. For a notebook where you want a mel spectrogram, librosa is the direct fit and pedalboard is not.
pySoX and SoxBindings are the other comparison points the README names. Both wrap SoX, a command-line audio processor. The README claims pedalboard is faster for single transforms, but the more important difference is that SoX effects are a fixed set defined by SoX, whereas pedalboard can host arbitrary VST3 and AU plugins. If your processing is one of the standard SoX operations, a SoX binding may be simpler and has a different licence.
Release cadence, maintenance and what to verify
The release history shows a steady cadence: v0.9.23 in May 2026, v0.9.24 in July 2026, v0.9.25 in September 2026. The version numbers are still in the 0.9.x series, which means the project has not declared a 1.0 API stability commitment in its versioning. That is not a warning by itself, but it does mean minor releases can carry changes you should read before upgrading. The repository is not archived and the last push matches the most recent release.
The maintenance cost for users is mostly environmental. Wheels cover a specific set of platforms and Python versions, so a Python upgrade can put you ahead of the wheel matrix until the next release lands. Plugin hosting adds a second variable: a VST3 that works on your development machine may not load in a CI container, particularly on Linux where the glibc version matters. The README's note about glibc greater than 2.27 is the kind of thing that surfaces as a load failure rather than an install failure.
On the licence, the practical question is distribution. GPL-3.0 is a copyleft licence, and the repository ships a LICENSE file at the root. Whether your use triggers its obligations depends on how you distribute your work, and that is a question for a lawyer, not for this article.
What to verify first, in order: that pedalboard.load_plugin returns what you expect for your specific plugin on your specific platform, that your Python version has a matching wheel, and that your deployment environment meets the glibc floor if you are on Linux. Each of those can be checked in a single session before you write any pipeline code around the library.
Editorial conclusion
Adopt pedalboard if you need scripted, repeatable audio effects inside a Python pipeline, particularly for data augmentation or batch processing where a DAW would be impractical. Do not adopt it if your project cannot ship under GPL-3.0, or if you need a plugin format it does not host. Before committing, verify that your target VST3 or Audio Unit loads on your platform and Python version, since the README notes platform-specific plugin support rather than universal coverage.
Community notes