# qpwgraph draws the PipeWire graph as an editable patchbay > qpwgraph is a Qt based graph manager for PipeWire that presents the audio server as a canvas of nodes and ports you can connect and rewire, in the same mould as QjackCtl. It is written in C++ with CMake, licensed GPL-2.0-or-later, and is developed upstream on freedesktop.org. **rncbc/qpwgraph** — qpwgraph - A PipeWire Graph Qt GUI Interface - Repository: https://github.com/rncbc/qpwgraph - Website: https://gitlab.freedesktop.org/rncbc/qpwgraph - Stars: 740 · Forks: 36 - Language: C++ - License: GPL-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/rncbc-qpwgraph ## A graph manager, not a mixer qpwgraph is described as a graph manager dedicated to PipeWire, using the Qt C++ framework, and the README is careful to place it in a lineage: it is based and pretty much like the same of QjackCtl. That comparison is the fastest way to understand the tool, because QjackCtl is a known thing. If you have used a JACK connection graph editor, you already know the shape of the interface: a canvas of nodes, each with input and output ports, lines drawn between them, and a patchbay where connections are created, broken and saved. What changes with PipeWire is what the graph contains. PipeWire's model is not a set of JACK clients and ports in the same sense; it has session managers, filters, links and streams, and the graph qpwgraph draws is the one the server actually reports. The same editing habit applies to a different topology. The upstream author is Rui Nuno Capela, and the copyright notice covers 2021 to 2026, so this is a project with a few years of development behind it. The source repository is on gitlab.freedesktop.org rather than GitHub, which follows the freedesktop.org convention for desktop infrastructure projects, and there are no GitHub releases to speak of. ## Building it with CMake The build is CMake, version 3.15 or newer, and the README gives the whole sequence. ```bash cmake [-DCMAKE_INSTALL_PREFIX=] -B build cmake --build build [--parallel ] ``` The first command configures into a build directory, with the optional CMAKE_INSTALL_PREFIX to override where it will be installed. The second compiles, and the --parallel flag takes a job count. The result can be run straight out of the build tree without installing anything: ```bash build/src/qpwgraph ``` That is worth doing first, because it separates a build problem from an install problem, and because the executable lives under the src subdirectory of the build directory, which reflects the layout of the source tree where the application code is in src. To install it permanently: ```bash [sudo] cmake --install build ``` The default installation prefix is /usr/local, as the README notes, and the sudo is optional depending on where you installed it. The repository also carries debian and rpm directories, so the project ships packaging recipes for both Debian style and Red Hat style distributions alongside the CMake install. ## The build dependencies, and the ALSA MIDI switch The prerequisites are named as distribution packages, which is how the README expects you to find them. You need a C++20 compiler (g++), the Qt C++ framework, either qt6-qtbase-devel or qt5-qtbase-devel, and the PipeWire API C development libraries and headers, pipewire-devel. The Qt 5 option is worth noting, because it means the source is not hard tied to a single Qt generation and a distribution still on Qt 5 can build it. The optional dependency is the interesting one. On build configure time, ALSA development libraries and headers (alsa-devel) are also required if ALSA MIDI (Sequencer) support is desired, and it is enabled with a CMake option, cmake -DCONFIG_ALSA_MIDI=[1|ON]. So the MIDI sequencer bridge is compiled out unless you ask for it. That is the right default for a PipeWire tool, since the sequencer is a compatibility path rather than the main event, but it means a user expecting ALSA MIDI to appear in the graph will not find it until the option is set and the project rebuilt. The option name itself is a useful signal about how the project is built. The CONFIG_ prefix is the convention used across the author's other projects, and it means feature switches are declared in CMake rather than hard-coded, so a downstream packager can turn them on or off at configure time. ## The patchbay is the part that needs its own manual The documentation section lists two documents, and the split between them is informative. There is a User Manual, and separately a document titled How To Use The Patchbay. The fact that the patchbay needed its own guide says more about the tool than any description would. The reason is that a patchbay is not a trivial interface. In QjackCtl and its descendants, the patchbay is a virtual rack of jacks where you plug one port into another, and the operations are not obvious on first contact. Connecting two outputs by accident, or leaving a cable half connected, produces audio routing that is hard to diagnose, so a guide dedicated to the mechanics is a sign the author took the interface seriously. For PipeWire, the patchbay also does something JACK patches could not do in the same way. Because the graph includes session managers and filters, a patch can involve a filter node in the middle, and the client is not simply connecting two applications. That is a different mental model from JACK, and it is the kind of thing the separate guide exists to explain. Both documents are in the docs directory of the repository as Markdown files, so they can be read in a terminal, in an editor, or rendered on a site, depending on preference. ## Where qpwgraph sits against QjackCtl and a mixer The useful comparison is not with another PipeWire tool but with the two things a user might otherwise reach for. Against QjackCtl, the difference is the audio server underneath rather than the interface. QjackCtl presents a JACK graph, and JACK's model of clients, ports and patching is the one QjackCtl teaches. qpwgraph presents the PipeWire graph, where the same visual language covers session managers, filters and streams. A user moving from JACK to PipeWire keeps the muscle memory of connecting and disconnecting ports, and has to learn the new node types. Against a mixer, the difference is scope. A mixer is a console: channels, faders, sends, a master section, and the business of making a usable listening and recording environment. qpwgraph does not claim to be that. Its job is to show you the server's structure and let you rewire it, which is a different and in some ways more fundamental task. If your problem is that the routing is wrong, a graph editor finds it; if your problem is that the monitor mix is awkward, a mixer is the right instrument. There is a practical point in that too. A graph manager is a diagnostic and configuration tool that sits next to whatever mixer or routing setup you already use, not a replacement for it. Treating it that way keeps expectations straight. ## Licence, packaging and the upstream project qpwgraph is free, open-source software, distributed under the terms of the GNU General Public License version 2 or later. The version 2 or later wording is the practical detail. GPL-2.0-or-later means you can ship it under GPL-2.0 or under any later version, so a distributor bundling it alongside other GPL components is not forced into a particular arrangement. The repository carries a LICENSE.md file, and the README also states that the licence covers the Qt C++ framework it is built on, which is the standard practice of naming the licence of the framework separately from the licence of the application. The packaging situation is what makes this practical to try. Alongside the CMake install there are debian and rpm directories, so the project has the recipes needed for the two dominant Linux distribution packaging systems, and the CMake install with its /usr/local default prefix is the fallback for everything else. The upstream author is Rui Nuno Capela, and the copyright runs from 2021 to 2026. The project lives on gitlab.freedesktop.org, which is the freedesktop.org hosting for desktop components and gives the code a home alongside the other infrastructure projects it interacts with, PipeWire among them. The last push was on 2026-09-19, the repository is not archived, and the ChangeLog file at the top level is where the release history is recorded rather than a GitHub releases page. ## Conclusion qpwgraph suits a Linux audio user who wants to see what PipeWire is actually doing and rewire it by hand, since the canvas exposes the server graph the way QjackCtl exposes JACK, including the patchbay and filter graphs. It is the wrong tool if you want a mixer, a routing preset system or a plugin host, because the project positions itself as a graph manager rather than a console, and it is the wrong tool on systems without PipeWire. Before building, install the Qt and PipeWire development packages named in the prerequisites, and pass -DCONFIG_ALSA_MIDI=ON if you want ALSA sequencer support, since that support is compiled out by default. ## FAQ ### How do I build qpwgraph from source? You need CMake 3.15 or newer, a C++20 compiler, the Qt development packages (qt6-qtbase-devel or qt5-qtbase-devel) and the PipeWire development libraries (pipewire-devel). Then run cmake -B build followed by cmake --build build, and you can try the result with build/src/qpwgraph before installing it with cmake --install build. ### How do I enable ALSA MIDI support in qpwgraph? Install the ALSA development libraries and headers (alsa-devel) and configure with -DCONFIG_ALSA_MIDI=[1|ON]. The README states this support is optional at build configure time, so it is not compiled in by default. ### What is the difference between qpwgraph and QjackCtl? qpwgraph uses the same graph editing approach as QjackCtl but is dedicated to PipeWire rather than JACK. The README describes it as based and pretty much like the same of QjackCtl, so the interface is familiar while the graph it shows is the PipeWire one, with session managers, filters and streams rather than JACK clients and ports. ### Where is qpwgraph's documentation? The repository has a docs directory containing a User Manual and a separate How To Use The Patchbay guide, both as Markdown files. The patchbay has its own document because connecting and disconnecting ports in the virtual rack is the part of the interface that needs the most explanation. ## Sources - [Issues](https://github.com/rncbc/qpwgraph/issues) - [License: GPL-2.0](https://github.com/rncbc/qpwgraph/blob/main/LICENSE) - [Project website](https://gitlab.freedesktop.org/rncbc/qpwgraph) - [README](https://github.com/rncbc/qpwgraph/blob/main/README.md) - [rncbc/qpwgraph on GitHub](https://github.com/rncbc/qpwgraph) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rncbc-qpwgraph