# Cmajor: a C-family language for writing portable audio DSP

> Cmajor is a C-family programming language designed for DSP signal processing, with a compiler and tooling built on LLVM and a VS Code extension for a one-click install. It suits audio developers who want the performance of C or C++ without hand-porting code across processor architectures, and it carries a commercial end user licence and a heavy build.

**cmajor-lang/cmajor** — The Cmajor public repository

- Repository: https://github.com/cmajor-lang/cmajor
- Website: https://cmajor.dev
- Stars: 756 · Forks: 55
- Language: C
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/cmajor-lang-cmajor

## A C-family language with DSP as the design centre

Cmajor describes itself as a programming language for writing fast, portable audio software. The README puts it plainly: you have heard of C, C++, C# and Objective-C, and Cmajor is a C-family language designed specifically for writing DSP signal processing code.

The design centre matters more than the syntax. Audio code is the kind of code where the inner loop has to be fast, where the same algorithm may need to run on a laptop CPU, a dedicated DSP chip, a GPU or a tensor accelerator, and where a professional user expects it to behave predictably. That combination is what the project goals are written around.

The audience is audio software developers and sound designers. The stated goals list matching, and often beating, the performance of traditional C and C++, making the same code portable across diverse processor architectures such as CPU, DSP, GPU and TPU, offering enough power and flexibility for professional audio industry users, speeding up commercial product cycles by making sound designers less dependent on instrument platforms, and attracting students and beginners by being easier to learn than C or C++.

The documentation lives at cmajor.dev, with a Quick Start Guide for getting set up, a language reference for the details, and an examples/patches folder in the repository for real code.

## Portability across CPU, DSP, GPU and TPU is the point

Read the goals list again and one idea dominates: the same code should move between processor architectures. A DSP algorithm written once should not need a rewrite for a different target, and that promise is what separates a language designed for audio from a general purpose language used for audio.

The cost of that promise is visible in the repository. Alongside the language sources there are modules/, a standard_library/, include/, a javascript/ directory, tools/ and a tests/ tree, plus 3rdParty/ for vendored dependencies and a .gitmodules file. A language that targets several kinds of processor needs its own module system and its own standard library, and it needs a way to expose the same interface to JavaScript, which the javascript/ directory is presumably where.

The project also distributes a native_apps example directory and a patches directory under examples/, which tells you two things about the intended workflow. One is that real programs are expected, not just snippets. The other is that patches are a first class concept in the examples, which fits a language aimed at sound design work where a change to a signal chain is expressed as a patch.

The Cmajor VS Code extension is published to the Visual Studio marketplace and offers a one-click install process, which is how most people are expected to get a working setup rather than building the compiler by hand.

## Building the tooling on macOS, Windows and Linux

Building from source needs a host with suitable compilers and CMake support. The README is specific about the requirements: a recent XCode on macOS, VS2019 on Windows, and on Linux a successful build with both clang and gcc v8 and above. When cloning, submodules must be pulled too, because several third party libraries live there.

On macOS the top level directory is configured with CMake and the XCode generator:

```bash
> cmake -Bbuild -GXcode .
```

The resulting XCode project in the build directory is then opened to build the tooling.

On Windows the equivalent uses the Visual Studio generator:

```bash
> cmake -Bbuild -G"Visual Studio 16 2019" .
```

On Linux the generator is your choice, and the README says ninja works well:

```bash
> cmake -Bbuild -GNinja -DBUILD_PLUGIN=OFF -DCMAKE_BUILD_TYPE=Release .
> cd build
> ninja
```

Two restrictions show up here. On Windows on arm64, building the plugin is not supported for now, and it is disabled with -DBUILD_PLUGIN=OFF. And only Release and RelWithDebugInfo builds of the Windows project are currently supported, because the pre-built LLVM libraries use the release runtime; a Debug build means rebuilding LLVM yourself, which the README warns takes time and produces large libraries.

## CPM and the LLVM libraries replace the submodule workflow

The dependency story is in flux, and the README explains both the current state and the direction of travel.

The pre-built LLVM libraries have recently moved to using cpm, which lets you cache a local copy of the LLVM libraries by pointing the CPM_SOURCE_CACHE environment variable at a suitable cache directory. The README says to read the CPM documentation for the details, which means the exact procedure is not spelled out in the project page itself.

The stated direction is to move away from submodules and toward CPM for all dependencies, and the reason given is that it benefits people using worktrees. That is a developer ergonomics fix, but it also changes the shape of a checkout: the .gitmodules file is still present at the root while the long term plan is that it will not be needed.

For a contributor this matters in a practical way. A clone without submodules will fail to build for reasons that are not obvious from the error, and the difference between a submodule checkout and a CPM populated build is now something you have to know about before you start rather than discover halfway through.

## Where Cmajor is the wrong tool

The honest answer for many teams is that Cmajor is too heavy for the job.

The build is the first hurdle. It needs a full C++ toolchain, CMake, and LLVM libraries that on Windows may have to be rebuilt from source in Debug configuration. That is a build environment to maintain, not a dependency to add. If you want a plugin format or a plugin host, neither the README nor the repository layout suggests an ecosystem to plug into.

The second limitation is platform coverage in practice. The plugin is not built on Windows arm64, and Windows debug builds are not supported out of the box. A team targeting Apple silicon Macs is fine, since the macOS path uses XCode, but a Windows arm64 shop is working with a reduced feature set today.

The third is the licensing model. The repository contains EULA.md and LICENSE.md, the GitHub licence field reports a custom licence it cannot classify, and the README states that all content is copyright 2023 Cmajor Software Ltd unless marked otherwise. Before using Cmajor in a commercial audio product, those files have to be read, and they are the part of the evaluation most likely to change a decision.

## Cmajor against C++ with a portability layer

The realistic alternative is to stay in C++ and handle portability yourself, usually with a per-platform abstraction layer over the DSP code.

The difference in approach is where the effort lands. In C++, the abstraction layer is a set of headers and build configurations that you write and maintain, and every new target means new platform code, new build files and new testing on hardware you may not own. The algorithm itself stays the same, but the surrounding engineering grows with each target.

Cmajor moves that effort into the language and the compiler. Portability across CPU, DSP, GPU and TPU is a stated project goal rather than something you assemble, and the C-family syntax means the code you already know how to write is close to what you write here. The trade-off is that you accept the language's rules, its module system and its standard library instead of your own layer, and you accept a toolchain built around LLVM and CMake.

The other alternative is to write the algorithm once in a library you maintain in several languages, or to accept that some targets get a separate implementation. That is what the Cmajor goal of speeding up commercial product cycles by making sound designers less dependent on instrument platforms is aimed at, and it is the clearest way to see who the language is for.

## Version numbering, cadence and the files that define the terms

The releases are numbered with a four digit build suffix: 1.0.3209 on 2026-09-24, 1.0.3175 on 2026-07-10 and 1.0.3066 on 2025-11-23. The repository was last pushed on 2026-10-15, the default branch is main, and the repository is not archived.

There is no stated release policy in the README, so the version numbers cannot be turned into a support window, but they do show that the project ships frequently enough that a quarterly upgrade is plausible, and that the version is tied closely to the underlying LLVM build, which is likely why the numbering differs from a plain semantic version.

Four documents at the repository root shape the legal and practical terms. LICENSE.md is the licence file, and GitHub cannot classify it, so it must be read. EULA.md is the end user licence for the tooling. CLA.md is the contributor licence agreement for people submitting code. CLAUDE.md sits alongside it as an instruction file for automated tooling that works in this repository.

The copyright line in the README reads that all content is copyright 2023 Cmajor Software Ltd unless marked otherwise, which tells you that the documentation and the example code are not automatically free for reuse in a commercial product without checking the terms.

## Conclusion

Cmajor fits audio software teams that want to write DSP once and deploy it across CPU, DSP, GPU and TPU targets, and that are willing to live with a C-like language and a CMake and LLVM based toolchain rather than an existing audio framework. It does not fit a team that needs a plug-in ecosystem, a debugger with mature third party support, or a build that works out of the box on every platform, since Windows debug builds and the arm64 plugin are not supported today. Before you commit, read EULA.md and LICENSE.md, build the tooling with the Release configuration on your platform, and confirm the example patches under examples/patches compile against your own target hardware.

## FAQ

### What is Cmajor used for?

It is a C-family programming language designed specifically for writing DSP signal processing code, with portability across CPU, DSP, GPU and TPU targets listed among its project goals.

### How do I get started with Cmajor?

The VS Code extension offers a one-click install process, and the Quick Start Guide at cmajor.dev covers other options including the command line tools. Example code lives in the examples/patches folder of the repository.

### What do I need to build Cmajor from source?

A host with suitable compilers and CMake support: a recent XCode on macOS, VS2019 on Windows, and on Linux clang or gcc v8 and above. On Linux the README suggests configuring with the Ninja generator and then running ninja in the build directory.

### Why does my Cmajor build fail on Windows or need a Debug build?

Only Release and RelWithDebugInfo builds of the Windows project are supported because the pre-built LLVM libraries use the release runtime, and on Windows arm64 the plugin cannot be built and must be disabled with -DBUILD_PLUGIN=OFF.

## Sources

- [cmajor-lang/cmajor on GitHub](https://github.com/cmajor-lang/cmajor)
- [Issues](https://github.com/cmajor-lang/cmajor/issues)
- [Project website](https://cmajor.dev)
- [README](https://github.com/cmajor-lang/cmajor/blob/main/README.md)
- [Releases](https://github.com/cmajor-lang/cmajor/releases)

---

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