Cabbage3 is a Csound plugin host in development, with Cabbage 2 kept in the archive

The repository moved, and the old one is archived

The first fact in the readme is about history rather than features, and it matters for anyone arriving from a search result. This repository contains the Cabbage3 project and is the canonical home for Cabbage 3 development, previously at the separate rorywalsh/cabbage3 repository, which is now archived. So there are two Cabbage-related repositories online and only one of them is where work happens. The Cabbage 2 code, which is a different and older line, is not in that other repository at all, and it is preserved inside this one. The Cabbage 2 tree is frozen and kept under an archive/cabbage2/ directory, the old mainline lives at archive/cabbage2/main, and the final v2 state is also tagged v2-master-final and v2-develop-final. Those two tags matter more than they look, because a frozen final state is the only way to build the old line reproducibly, and anyone with a Cabbage 2 project depending on that exact tree has a known-good commit to point at.

develop is the working branch and main is the release line

The branch model is stated plainly and it is the sort of thing that bites people who clone and start. The develop branch is the default and is where active development happens, and you are told to expect frequent updates and breaking changes on it. The main branch is the release line, and it is updated at release points. The default branch of the repository is develop, which means a bare clone gives you the moving target rather than the stable one. That is a deliberate choice for a project in heavy development, and it is the right choice for contributors and the wrong choice for a build pipeline that wants reproducibility. The practical consequence is that a CI job that tracks the default branch will break on a schedule you do not control, so a project that depends on Cabbage3 has to pin a commit rather than follow a branch, and the fact that the release tags exist in the history is what makes that pinning practical.

The project's own warning is the first thing to read

The readme carries a note that a responsible evaluator should quote rather than paraphrase. Cabbage3 is still very much under development, the source code presented here is experimental and may undergo significant changes, features are not final, and stability or performance may vary. The instruction is to use it at your own discretion and to expect frequent updates and potential breaking changes. That is unusually direct for a project readme, and it changes how the rest of the documentation should be read. The temporary docs for Cabbage 3 are described as temporary and available separately, and the note says they will be merged with the main Cabbage website when the first release is made public. So the documentation is explicitly provisional, which is consistent with the branch layout and with the release history, where the newest tag is v2.10.0 from January 2025 against a repository that was pushed to in October 2026. That gap is the fact to reason about: the tags track a different, older product line from the code in the tree.

One cmake command, three build targets with different jobs

Building is a single cmake invocation with a target variable, and the three targets are worth understanding separately because they do different jobs. The command is cmake with the source directory, a build directory, and the CABBAGE_BUILD_TARGET variable set.

cmake -S . -B build -DCABBAGE_BUILD_TARGET=CabbageApp

The valid targets are listed in the readme. CabbageApp is the VSCode service app, and the description is the part that matters, since this application is run each time you run an instrument in VSCode. That makes it a host process rather than a plugin in the audio path, and it explains why it is a separate target from the two plugin targets. CabbagePluginEffect is for plugin effect targets, and CabbagePluginSynth is for plugin synth targets, so the same source tree produces either a processor or a generator depending on which target you build. The repository carries a cmake directory and a CMakeLists.txt at the top, and the source is under src, so the cmake setup is a conventional out-of-source build rather than a bundled build system.

CI produces the binaries, so you do not have to build at all

The readme mentions the CI build before it mentions building locally, and that ordering is a hint about how the project is meant to be used. The GitHub repository has a CI build that produces binaries from the most up-to-date source, and the local cmake command is offered for the case where you need to build yourself. For a plugin framework, that is the sensible split, because the artifacts a user wants are the compiled plugin binaries and the service app, and the build has cross-platform implications that a maintainer handles better than a user. The only build instructions given are the cmake line, with no dependency list and no platform notes, so anyone building locally is expected to bring their own toolchain knowledge. The repository also carries a commit.sh script at the top level, a .clang-format file for C++ formatting, a tests directory and a src directory, and an overview.md document that the readme does not summarise.

Csound does the audio, the framework handles the plugin shell

The project description is short and it carries the architecture in one clause. Cabbage is a framework for developing audio plugins with the Csound programming language, so the DSP and the instrument design live in Csound and the C++ codebase provides the plugin shell around it. That is what makes the CabbagePluginEffect and CabbagePluginSynth targets natural rather than a limitation, since a Csound instrument is either generating or processing and the target decides which kind of binary comes out. The CabbageApp target then sits on top as the editor-side service. The repository primary language is C++, and the plugin topics attached to the project include audio development, so the C++ is the host code. The practical appeal is that a plugin author can stay in Csound, which is the point of the framework, and the practical cost is that you are inside a project whose own documentation says the features are not final.

Where Cabbage3 is the wrong choice

The first wrong case is a production audio product that needs a stable plugin binary and a predictable host behaviour, because the project states the source is experimental and asks you to expect breaking changes, and the newest release tag predates the current development by a wide margin. The second wrong case is a developer who does not already know Csound, since the framework assumes the instrument is written in Csound and the C++ is the surrounding shell, so the learning curve is the language rather than the framework. The third is a team that needs Cabbage 2 behaviour, because Cabbage 2 is frozen and the repository keeps it only for preservation, so the old line is where a stable 2.x build comes from and not the develop branch. The fourth is a plugin format the project does not target, since the readme names only the VSCode service app, plugin effect and plugin synth targets and says nothing about other formats. The fifth is a user who wants a finished product with documentation, since the Cabbage 3 docs are described as temporary and scheduled to be merged with the main website only when the first release is made public.

Editorial conclusion

Audio developers who already write Csound and want to ship a plugin without dropping into C++ are the people Cabbage3 is for, and the VSCode service target, which runs each time an instrument is started in the editor, is the part that makes it feel like an editor integration rather than a plugin SDK. It is the wrong tool for anyone who needs a stable API today, because the documentation states the source is experimental, features are not final, and stability or performance may vary, and the repository asks you to expect frequent updates and potential breaking changes. Check three things before you build on it: that you are on the develop branch and understand that it moves, that the branch you need actually has what you want, since main is only updated at release points, and that the licence terms suit you, because the project carries a custom licence GitHub cannot classify and the repository does not summarise its terms. The last push was on 2026-10-15, the newest release is v2.10.0 from 2025-01-09, and the project also carries its own CI that produces binaries from the most up-to-date source.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. rorywalsh/cabbage on GitHub