# Element Audio Plugin Host: formats, graphs, and setup > Element is a C++ audio plugin host for building routed audio and MIDI graphs across AU, LV2, VST, VST3, CLAP, and LADSPA. It fits users who need standalone hosting or DAW integration, though its README delegates build instructions to separate project documentation. **kushview/element** — Element Audio Plugin Host - Repository: https://github.com/kushview/element - Website: https://kushview.net/element/ - Stars: 1,754 · Forks: 146 - Language: C++ - License: not declared - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/kushview-element ## What Element's modular plugin graphs are for Element addresses the gap between running one audio plugin and constructing a routed processing setup from several plugins. It is a modular host for audio effects, virtual instruments, effect racks, and other connected graphs. The intended users are musicians, producers, and developers who need to route audio or MIDI between nodes, reuse a graph in a later performance, or place the host inside a DAW. The application can run standalone or as a plugin in a DAW, according to the README. Its format coverage is its clearest practical distinction. On Linux, the compatibility table lists LADSPA, LV2, VST3, and CLAP. On macOS 10.13 and later, it lists AU, VST, VST3, LV2, and CLAP. On Windows 10 and later, it lists VST, VST3, LV2, and CLAP. LADSPA is not listed for macOS or Windows, while AU and VST are not listed for Linux or Windows. Element is not limited to preset playback. Its documented graph model allows users to connect nodes to one another, embed plugin interfaces directly in graphs, and nest one graph inside another. That makes it relevant when a fixed insert chain is too restrictive. It also adds requirements: users must understand signal routing, monitor levels, and the behavior of each included plugin. ## Audio, MIDI, and nested graph data flow The visible architecture is a node-based graph in which audio and MIDI can move between components. Nodes can represent effects, virtual instruments, placeholder nodes, or custom DSP. Placeholder nodes are documented as a built-in feature, but the README does not explain their exact lifecycle or whether they save routing before another node replaces them. MIDI is part of the routing model rather than an accessory feature. The README says that audio and MIDI can be routed from anywhere to anywhere, and it also lists external synchronization through MIDI Clock. Element includes a built-in virtual keyboard, which gives a source for MIDI without requiring every graph to begin with an external hardware controller. Sub Graphing lets teams treat a nested graph as a component inside a larger graph. This is useful for repeated signal layouts, but the Element User Manual does not establish whether nested graphs can contain every top-level node type. The README also does not document graph serialization, external side-chain routing, or failure handling when a child plugin fails. Those details should be checked before treating deep nesting as an established production pattern. The application supports multiple undo and redo operations, custom keyboard shortcuts, and plugin UIs embedded in graphs. These are editor and workflow features rather than audio-processing guarantees. The README does not provide measurements for DSP latency, processor use, sample-rate changes, or large graph sizes. ## Supported plugin formats and platform boundaries Element is best understood as a format-neutral front end rather than a host tied to one plugin ecosystem. Its support matrix covers five formats on macOS, four on Linux, and four on Windows. The README also says Element loads most major plugin formats, but that broad statement is qualified by the explicit platform table. Ubuntu receives a specific qualification: the README calls Ubuntu the most tested system and says the application should run on other major Linux distributions. That is useful for choosing a first Linux environment, but it is not a guarantee for every distribution, desktop environment, audio server, or plugin package. The DAW integration also raises format questions. A host that can run inside a DAW still needs the DAW's plugin wrapper format on the relevant operating system. The README does not document that wrapper separately, so users should not infer that every host format shown in the compatibility table can also host Element inside every DAW. Scripting is listed as support for custom DSP and DSP interfaces, but no language, API, execution model, or packaging method appears in the README. Developers evaluating automation should locate the Lua documentation workflow referenced by the repository and consult the user manual. Treating scripting as a stable extension API would go beyond what the README confirms. ## Downloading Element and completing a first graph The README does not provide installation commands or package-manager instructions. It directs users to the project website for prebuilt binaries, while source-build users are sent to `docs/building.md`. The repository also includes `CMakeLists.txt`, a `Dockerfile`, and a `Dockerfile.archlinux`, but the README and repository listing do not show the build arguments, host dependencies, or commands needed to produce a working application from them. For the first practical attempt, use the prebuilt binary page linked by the README. Choose the package for the target operating system, then compare that system's listed formats with the plugin formats already installed. The README does not document package signatures, installation permissions, first-run migration, or automatic system plugin discovery, so those checks remain outside the confirmed setup path. After opening Element, the shortest documented workflow is to create a graph, place a source or virtual instrument node in it, add an effect node, and connect the two. Add a MIDI-capable instrument when the task requires MIDI, or use the built-in virtual keyboard as the input source. The documentation does not state the exact menu names, so a tutorial should not invent clicks that may differ from the released interface. The expected result is a routed graph whose plugin interface can be embedded in the editing surface. Test the connection at a safe monitoring level, then save or reuse the arrangement. The README confirms reusable instrument and effect graphs but does not identify the save format, preset extension, or whether saved graphs retain compatibility across Element releases. ## Build, license, and maintenance constraints Building from source is documented outside the main README. A contributor should begin with `docs/building.md`, which the README identifies as the source for instructions and dependency details. The repository's `.gitmodules`, `cmake/`, `deps/`, and platform Dockerfiles indicate that the source tree has external dependencies and multiple build definitions. Their exact revision, initialization, and build commands are not shown in the README. The repository is not archived, and its last push was on 2026-10-08. Releases include Element 1.2.0 on 2026-08-07, 1.1.1 on 2026-07-03, and 1.1.0 on 2026-06-29. Those dates show recent release activity, but they do not establish API stability or compatibility of saved graphs. Upgrade notes should be read in `CHANGELOG.md`, because the README does not summarize migration requirements. The repository includes `LICENSES/`, `REUSE.toml`, and an `AUTHORS.md`, but the repository metadata available for this review does not identify the license. The REUSE badge in the README also does not, by itself, state the applicable terms. Before redistributing Element or incorporating source into another product, inspect `LICENSES/` and `REUSE.toml`. This is a repository-review step, not legal advice. ## Where Element differs from a DAW insert chain Element's direct alternative is a conventional DAW routing view. A DAW generally represents tracks, buses, sends, and inserts through a session centered on timeline recording and mixing. Element instead foregrounds connected nodes, nested graphs, a virtual keyboard, MIDI Clock synchronization, and graphs that can be reused as instruments or effects. Both can run plugin processors, but their editing models differ. Another alternative is a narrow format-specific host. Such a host may provide a simpler loading workflow for one ecosystem, while Element presents a common graph surface for the formats listed in its platform matrix. Element is therefore a better fit when avoiding format-specific tooling matters. It is the less attractive choice when the immediate requirement is a conventional recording timeline and the DAW already provides all needed routing. Element's scripting and custom DSP support may also attract developers, but the absence of API details in the README makes comparison premature. A team that needs generated plugin builds, a documented stable embedding API, or an unattended installation process should verify those capabilities in the project documentation first. ## Conclusion Audio users who need a modular host across several plugin formats should examine Element, particularly if nested graphs, MIDI routing, or DAW integration matters. Users who require a fully documented one-command build should inspect docs/building.md first, and adopters should review LICENSES/ and REUSE.toml before distribution or integration because the README does not state the repository's license. ## FAQ ### Which audio plugin formats does Element support? Linux supports LADSPA, LV2, VST3, and CLAP. macOS 10.13 and later supports AU, VST, VST3, LV2, and CLAP, while Windows 10 and later supports VST, VST3, LV2, and CLAP. ### How do I install or build Element? The README directs users to prebuilt binaries on the Kushview website and source-build instructions to `docs/building.md`. It does not provide platform-specific installation or build commands. ### Can Element run inside a DAW and route MIDI? Yes. The README says Element can run as a plugin in a DAW, route audio and MIDI between nodes, synchronize externally through MIDI Clock, and provide a built-in virtual keyboard. ### What license does the Element repository use? The repository metadata does not state the license. The tree contains `LICENSES/` and `REUSE.toml`, so those files are the relevant starting points for reviewing licensing terms. ## Sources - [Issues](https://github.com/kushview/element/issues) - [kushview/element on GitHub](https://github.com/kushview/element) - [Project website](https://kushview.net/element/) - [README](https://github.com/kushview/element/blob/main/README.md) - [Releases](https://github.com/kushview/element/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kushview-element