# cycfi/q: A C++20 Audio DSP Library for Desktop and Microcontrollers

> cycfi/q is a header-oriented C++20 audio DSP library for building filters, synthesizers, pitch processors, MIDI systems, and plugins. Its three-layer design lets applications choose the lightweight core or add desktop I/O and plugin tooling.

**cycfi/q** — C++ Library for Audio Digital Signal Processing

- Repository: https://github.com/cycfi/q
- Stars: 1,445 · Forks: 180
- Language: C++
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/cycfi-q

## The Core DSP Scope of cycfi/q

cycfi/q addresses the problem of implementing audio signal processing directly inside C++ applications. Its target audience includes developers building audio effects, musical instruments, synthesizers, pitch tools, firmware, and plugins. The project is not limited to one effect category. The documented core includes biquad and resonant filters, envelope followers, compressors, expanders, automatic gain control, delay lines, granular synthesis, virtual analog synthesis, FM synthesis, oscillators, noise generators, and fast math approximations.

The pitch-processing facilities are also part of the library rather than a separate add-on. The documentation lists BACF pitch detection with sub-cent accuracy and a signal conditioner intended for real instruments. This makes the core useful when an application needs to analyze an incoming signal before routing it through effects or synthesis code.

The project targets modern C++20 and describes its API in terms of composable function objects, including stateful and stateless objects. This is a meaningful design constraint for adoption. It suits developers who are comfortable expressing signal paths as C++ abstractions, but it is not a drop-in procedural audio API designed to be copied from a traditional C signal-processing book.

## cycfi/q's Three-Layer Architecture

The repository is organized around three layers with different responsibilities. `q_lib` is the DSP core. It contains filters, envelopes, dynamics, oscillators, synthesis, pitch detection, MIDI support, and shared support facilities. The README describes this layer as header-only and dependent only on the C++ standard library and the header-only Cycfi infrastructure.

`q_io` adds audio and MIDI input and output for desktop applications. According to the README, it covers devices, streams, and audio files, and is built on RtAudio and libremidi. Tests and examples use this layer, while applications that already provide their own I/O or run as plugins can avoid it.

`q_plug` is an optional plugin framework. The documented model separates DSP code, parameters, and an Elements GUI into three plain classes. The resulting plugin implementation can target CLAP, with wrappers for VST3 and AudioUnit and a standalone application. QPlug is off by default, so selecting it is a separate architectural decision from using the core DSP library.

This separation gives cycfi/q a clear adoption path. A microcontroller project can focus on `q_lib`. A desktop instrument can add `q_io`. A hosted plugin can use `q_plug` without importing every desktop device facility into the DSP path.

## Composable Function Objects and MIDI Support

The documented programming model uses fine-grained, reusable function objects and function composition to build DSP graphs. This is more than a stylistic preference. State is kept in function objects when a processor needs memory, such as a filter, delay line, envelope follower, or compressor. The design allows processing stages to be assembled as C++ components instead of hiding all behavior behind a large engine.

The library also documents C++20 Concepts, type-safe units such as `440_Hz`, `10_ms`, and `-6_dB`, and a header-only DSP core. Those features can reduce accidental mixing of incompatible numeric meanings in code, provided that the application uses the supplied abstractions consistently. They do not remove the usual DSP concerns of sample rate, numerical stability, latency, and buffer handling.

MIDI support is unusually broad for a DSP library. The documentation lists MIDI 2.0 Universal MIDI Packets, Per-Note Expression, MPE, MIDI-CI, and translation between MIDI 1.0 and MIDI 2.0 in both directions. It also states that conformance tests cover the UMP, MIDI-CI, and MPE clauses, and that the implementation has been verified with the MIDI Association Workbench, including over USB on a device running Q firmware.

That MIDI scope distinguishes cycfi/q from a small filter collection. It can fit a connected instrument or firmware system where MIDI parsing, expression handling, and DSP processing need to coexist. The README does not, however, provide a complete list of hardware interfaces or a compatibility matrix for every MIDI endpoint, so device-specific verification remains necessary.

## Installing cycfi/q and Starting a First DSP Use

The README directs readers to the online setup documentation for supported platforms and compilers. The documented platform scope is macOS, Windows, and Linux, plus microcontrollers with an FPU and a C++20 compiler. The README specifically names STM32 with Arm GCC 12 as a tested combination.

The repository layout provides the starting points for a real first use. The top-level `CMakeLists.txt` is the build entry point, while `example/` contains projects such as `sin_osc`, `delay`, `fm_synth`, `grain_freeze`, `poly_synth`, `va_synth`, and `square_synth`. These examples are more useful as an initial path than trying to assemble an audio application from scratch, because they show which facilities belong to the core and which belong to the surrounding example infrastructure.

The first practical choice is the layer. For a signal-processing prototype, begin with `q_lib` and select an example that matches the intended operation. For desktop audio input and output, inspect `q_io` and its RtAudio and libremidi integration. For a plugin, inspect `q_plug` and the examples under `example/q_plug`.

## Resource Boundaries and Microcontroller Constraints

The main technical trade-off is between breadth and the need to evaluate each module against the target processor. The core is intended to run on small microcontrollers, and the README says the project is efficient enough for that use case. That is a target and design goal, not a universal guarantee for every algorithm, buffer size, or sample rate.

Some modules are naturally more demanding than basic filtering or oscillator generation. Granular synthesis, pitch detection, dynamic processing, FM synthesis, and high-quality virtual analog emulation involve real-time state, lookup data, arithmetic, or memory access. The README lists the features but does not document memory footprints, operation counts, or latency tables for them. An engineer targeting an STM32 or another constrained device therefore needs to inspect the selected implementation and measure the complete signal path on the intended hardware.

The documentation also does not establish a universal sample-rate policy or specify the acceptable buffer sizes for every processor. Those values belong to the host application and hardware environment. A plugin may receive arbitrary buffer sizes from its host, while firmware may use fixed periodic callbacks. The library's reusable function-object design does not by itself solve those integration constraints.

The practical limitation is clear: cycfi/q can fit small systems, but the README's platform statement is not evidence that every feature can fit every microcontroller.

## cycfi/q Compared with a Small Effect-Library Approach

A small effect-library approach usually centers on one processor, exposes a narrow API for that processor, and leaves MIDI, device I/O, plugin formats, and synthesis infrastructure to the surrounding application. cycfi/q takes a different approach. Its core already spans signal conditioning, pitch detection, filters, dynamics, delay, MIDI, and synthesis, while optional layers add desktop I/O and plugin packaging.

This broader scope is useful when the application needs several of those capabilities or expects to share code between firmware, desktop tools, and plugins. It also increases the amount of API and release information that must be reviewed. The optional layers are not interchangeable. `q_lib` does not by itself provide desktop device streams or audio-file handling. `q_io` is unnecessary for an application with its own I/O. `q_plug` introduces plugin and GUI concerns that are outside a minimal embedded DSP loop.

The README presents `master` as tracking the latest stable release, currently v1.5.4, while development for v1.6 occurs on `develop`. `NEWS.md` is identified as the place for release changes. This separation is important when comparing versions: an example or API reference may correspond to a particular documentation path, while the default branch contains the stable release.

## Maintenance, Licensing, and Upgrade Scope

The repository is not archived, and its last push was on 2026-10-14. The latest listed release is v1.5.4, dated 2026-10-08. These facts indicate recent repository activity, but they do not establish the size of the maintenance team or the stability of every module.

cycfi/q is released under the MIT License. The README describes it as open source and links to the license. That permits use, modification, and redistribution under the license's stated conditions, including preservation of its notice and disclaimer. The license does not by itself answer whether a particular audio algorithm, plugin binary, MIDI implementation, or external dependency fits a product's compliance requirements.

Upgrading may require more than changing a version string. The repository has a stable `master` branch and a separate `develop` branch for the next release. The documentation also organizes references and tutorials by version, including v1.5 paths. An upgrading project should compare `NEWS.md`, inspect the selected module's documentation, and confirm that its build configuration still selects the intended layer.

## Conclusion

cycfi/q fits C++ developers who need composable audio DSP building blocks and want the same core to work on desktop systems and suitable microcontrollers. It is less suitable for projects that require a complete audio application immediately without supplying their own interface, plugin packaging, or device integration. Check the exact module dependencies, sample-rate and buffer expectations, target compiler support, and the API corresponding to the selected release before adoption. The stable `master` branch currently tracks v1.5.4.

## FAQ

### What is cycfi/q used for?

cycfi/q is a C++20 audio digital signal processing library. Its documented areas include filters, synthesis, pitch detection, dynamics, MIDI, desktop audio I/O, and plugin development.

### Can cycfi/q run on microcontrollers?

The README says the core is intended for small microcontrollers and documents testing on STM32 with Arm GCC 12. It requires a target with an FPU and a C++20 compiler,.

### Does cycfi/q include MIDI 2.0 support?

Yes. The README lists UMP, Per-Note Expression, MPE, MIDI-CI, and bidirectional MIDI 1.0 and MIDI 2.0 translation as documented capabilities. It also describes conformance tests and verification with the MIDI Association Workbench.

## Sources

- [cycfi/q on GitHub](https://github.com/cycfi/q)
- [Issues](https://github.com/cycfi/q/issues)
- [License: MIT](https://github.com/cycfi/q/blob/master/LICENSE)
- [README](https://github.com/cycfi/q/blob/master/README.md)
- [Releases](https://github.com/cycfi/q/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cycfi-q