projectM: the Milkdrop-compatible visualizer library, and what its repository actually ships

The repository is the library, not the app you probably want

The single most important thing about this project is a scoping decision the maintainers made and then documented in the README: this repository now only contains the projectM shared/static library, and all frontends, plug-ins and other tools were moved into separate repositories. The library's stated job is to read an audio input, detect tempo, and render Milkdrop-style equations into visuals. That is a developer-facing contract. If your goal is to watch psychedelic visuals on a laptop tonight, cloning this repository gets you a CMake project, headers and source, not an executable you can point at your music player.

The README is unusually blunt about this. It says the releases section here only contains source-code and binary releases of the development libraries and headers, which are not useful for end users. It also warns that the available end-user frontends are development previews, not feature-complete, and may have bugs. So the project is two things at once: a compatibility layer for Milkdrop presets, and an ecosystem of frontends that are still catching up. Anyone evaluating projectM should decide which of those two they are evaluating before they start.

How the audio-to-equation pipeline is structured

The mechanism the README describes is a chain: audio input goes in, tempo detection runs, and Milkdrop-style equations and parameters are evaluated and rendered. Preset files are the unit of that rendering. According to the README, preset files define the visualizations via pixel shaders and Milkdrop-style equations and parameters. That sentence tells you where the compatibility burden sits. projectM is not generating visuals from a model or a fixed effect list; it is interpreting a preset format that originated with Winamp Milkdrop, which is why the project describes itself as a reimplementation of Milkdrop by Geiss in a more modern, cross-platform reusable library.

That framing has a practical consequence for integrators. Your application supplies audio and a rendering surface; the library supplies the preset evaluation and the visual output. The README lists the platforms its CI builds for, with separate workflow badges for Windows, Linux, macOS, Emscripten and Android, which is a reasonable signal of where the project expects to run. What the README does not document is the C API surface itself, the exact audio buffer format expected, or how tempo detection is configured. Those details live in the headers and the docs directory, not in the front page, so budget time for reading source.

Building libprojectM and getting a first preset on screen

The README gives no install steps, because this repository is the library and its build is configured through the CMake files at the repository root: CMakeLists.txt, features.cmake, config.h.cmake.in and a vcpkg manifest in vcpkg.json. The README does not spell out a build command line, so the only thing the repository confirms is that CMake is the build system and that vcpkg is wired in for dependencies. Read CMakeLists.txt and the workflows under .github/ before you run anything, since those are the authoritative sources for the flags this project expects.

Once the library is built, a first real use means linking it from a small host program that feeds audio in and renders to a window, then pointing that host at preset files you downloaded separately. The README does not provide a minimal example program, so the headers in src/ and the docs directory are where the actual call sequence has to be read. Expect the first working frame to take longer than the build itself.

Presets are a separate download, and that trips people up

The README states that the projectM library does not ship with any presets, and that frontends come with varying preset packs found in separate repositories. It also recommends the base Milkdrop texture pack for use with any preset pack. That is a real operational constraint: a correct build of the library can still show nothing interesting if you have not pointed it at preset files and, in many cases, the shared textures those presets reference.

The README names several collections. The Cream of the Crop pack is described as a collection of about 10K presets compiled by Jason Fletcher and currently projectM's default preset pack. The Classic projectM Presets collection is a bit over 4K presets shipped with previous versions. The Milkdrop 2 Presets repository holds the original preset collection shipped with Milkdrop and Winamp. En D Presets is about 50 presets. The README also says bltc201, Milkdrop 1 and 2, projectM, tryptonaut and yin collections are included with projectM, and links an external zip for those. Note the tension: the library does not ship presets, yet some collections are described as included. Treat the preset question as something to confirm against the specific frontend you use rather than the library alone.

Where projectM is the wrong tool

If you need a supported, feature-complete desktop application, projectM is not that today. The README says the end-user frontends are development previews which are not feature-complete and may have bugs. Several distribution channels listed are explicitly old: the Windows Store entry and the macOS Steam entry are both marked as the old 3.1.12 release, and the Homebrew formula is likewise marked old 3.1.12. The macOS Music.app plugin is available only as an unsigned development preview, which matters if you care about Gatekeeper prompts.

The Android situation is a different kind of limitation. The Google Play app exists, but the README states that both the free and paid apps plus the Android TV app are not created or supported by the projectM developers, and that bug reports about the apps in the projectM issue tracker will be closed immediately. So the Android path is real but outside the project's support boundary. The legacy 2.x sources on SourceForge, covering ALSA, XMMS, Winamp and JACK, are described as unmaintained since 2012. Finally, distribution packages are not maintained by the projectM team; the README asks users to contact the package maintainer if a distro package is outdated. If you need a single vendor to be accountable for the whole stack from audio device to pixels, this is a fragmented ecosystem, not a product.

Alternatives and the actual difference in approach

The clearest alternative for a developer is to write against the original Milkdrop preset format on Windows through Winamp or a Milkdrop-compatible plugin. The difference is architectural: Milkdrop is an embedded visualizer inside a specific player on a specific platform, while projectM is a reusable cross-platform library you link into your own application. If you want your visuals inside a player you already run, the plugin route may be less work. If you want visuals inside an application you are building, the library route is the only one of the two that gives you that.

A second option is to skip preset compatibility entirely and write your own shader-based visualizer against a graphics API. That avoids the Milkdrop equation interpreter and the preset ecosystem, at the cost of the roughly 10K presets in the Cream of the Crop pack and the original Milkdrop collections. The trade is compatibility breadth versus control. projectM's whole reason to exist is the compatibility side; if you do not need Milkdrop presets, you are paying for an interpreter you will not use.

Within the projectM ecosystem itself there are distinct integration paths, and they are not equivalent. The GStreamer plugin lives in its own repository, and the Qt-based desktop apps for Linux with PipeWire, PulseAudio and JACK backends live in another, with the README noting the Qt frontend requires libprojectM 4.x. If your application is already GStreamer-based, the plugin is the natural fit; if it is a Qt desktop app on Linux, the Qt frontend is closer to what you want than the SDL standalone.

Licence, maintenance and the cost of tracking releases

The licence is LGPL-2.1. For a library, that generally means you can link it from proprietary code under conditions the licence sets out, and modifications to the library itself carry obligations. This is not legal advice; read COPYING and LICENSE.txt in the repository and get your own counsel if you are shipping a closed-source product that links libprojectM.

On maintenance, the last push to the default branch was on 2026-09-10, and the most recent release is v4.1.7 from 2026-07-14, preceded by v4.1.6 on 2025-11-28 and v4.1.5 on 2025-11-03. That is a steady cadence of library releases rather than a stalled project, and the repository is not archived. The upgrade cost is mostly in the API: the README notes the Qt frontend requires libprojectM 4.x, which implies the 3.x line is not what new frontends target, and the old 3.1.12 builds still circulating on Steam, the Windows Store and Homebrew are a different generation. If you depend on a distribution package, check which major version it carries before assuming your integration code will compile.

Editorial conclusion

Adopt libprojectM if you are writing a C++ or Rust frontend and want Milkdrop preset compatibility, or if you want the GStreamer or Qt integrations. Do not clone this repository expecting a runnable visualizer: the README states plainly that it contains the shared/static library only, and the releases are development libraries and headers. Before building, verify your compiler and CMake toolchain against the build workflows in .github/, check that the LGPL-2.1 terms fit how you link the library, and remember that no presets ship with it, so a texture pack and a preset collection are separate downloads.

Frequently asked questions

Official sources

1. License: LGPL-2.1
2. projectM-visualizer/projectm on GitHub
3. Project website
4. README
5. Releases