# SWS Extension: the community feature set that extends the REAPER DAW

> The SWS extension is a C++ add-on that adds a large set of features to REAPER, the Digital Audio Workstation by Cockos, and it is developed in the open under a permissive licence. The repository is a CMake project with submodules for WDL, TagLib, and third party libraries, and most of the user-facing documentation lives on a separate site.

**reaper-oss/sws** — The SWS extension is a collection of features that seamlessly integrate into REAPER, the Digital Audio Workstation (DAW) software by Cockos, Inc

- Repository: https://github.com/reaper-oss/sws
- Website: https://www.sws-extension.org/
- Stars: 589 · Forks: 108
- Language: C++
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/reaper-oss-sws

## An extension for one DAW, and the scope follows from that

The SWS extension is a collection of features that integrate into REAPER, the Digital Audio Workstation software by Cockos, Inc. That single sentence sets the boundary of the project. It is not a DAW, not a plugin format, and not a general audio library. It is a C++ extension that adds capability to one specific host application, and it inherits that host's threading model, its scripting surface, and its user interface conventions. The repository topics list exactly two tags, reaper and reaper-plugin, which is the compressed version of the same fact. For a user, the practical question is whether the features REAPER itself lacks are the ones this extension provides, and for a developer the practical question is whether the extension API is a place worth spending C++ time, since the plugin surface is REAPER's rather than a standard like VST.

## Where the features actually are is a site, not the repository

The README is short, and the reason is structural. For more information on the capabilities of the SWS extension or to download it, the README points to the end-user website at sws-extension.org, and for information about REAPER itself or the latest version it points to reaper.fm. Everything you would want to know as a user, what the extension does, which version is current, how to get the binary, is published on that site rather than in the repository. The repository is the source, not the manual. That arrangement is normal for a long-lived desktop extension with a separate download and documentation site, and it has a practical consequence for anyone evaluating it: the README alone will not tell you whether a given feature exists. You have to look at the site, and you have to look at the plugin's own menus inside REAPER, because the source tree is organised by implementation area rather than by user-facing feature.

## The source tree is organised by subsystem, not by menu

Based on the repository layout, the extension is a large C++ project with a flat top level and many feature directories. The names read like a menu of the application's internals. There is `MarkerActions/`, `MarkerList/`, and `TrackList/` for the various list views, `SnM/` for what is presumably the arrangement and painting machinery, `Autorender/` for rendering, `Breeder/` and `Wol/` and `Fingers/` for item and finger behaviour, `Freeze/` for track freezing, `Projects/` and `ObjectState/` for project handling, `Padre/` and `IX/` for other subsystems, plus `Color/`, `Console/`, `Utility/`, and `Resources/`. Alongside the directories sit the pieces of the extension proper, `sws_extension.cpp` and `sws_extension.rc` for the entry point and resources, `Menus.cpp` and `Menus.h` for the menu structure, `DragDrop.cpp` and `Zoom.cpp` with their headers, `Prompt.cpp` for dialogs, and `ReaScript.cpp` for the scripting bridge. The top level also holds `cfillion/`, `snooks/`, and `nofish/`, which are the names of contributors whose work is credited in the tree.

## ReaScript is the extension's public surface to users

Several files at the top of the tree are about scripting rather than features, and they hint at what the extension adds for the people automating REAPER. `ReaScript.cpp` is the bridge, and there are helper scripts per language: `reascript_helper.pl`, `reascript_python.pl`, `sws_python.py`, and `reascript_vararg.php`, alongside test scripts in several languages with `reascript_test.c`, `reascript_test.eel`, `reascript_test.lua`, and `test.mjs` elsewhere in the tree. `IX/` is named in the way REAPER names its own extension interface, and `sws_extension.cpp` is where the extension registers itself. The practical takeaway is that a large part of the extension's value is available without clicking anything, through the ReaScript API. If you are evaluating SWS for a scripting-driven workflow, that is where to look first, and it is also where a bug report is most likely to be useful to the project.

## Third party libraries come in as submodules, not vendored copies

The README states that the SWS extension includes three third party libraries, which are all similarly licensed: OscPkt for OSC, libebur128 for loudness measurement, and it also relies on TagLib and WDL. The listing is:

```text
- [OscPkt](http://gruntthepeon.free.fr/oscpkt/)
- [libebur128](https://github.com/jiixyj/libebur128)
```

The repository has a `.gitmodules` file, so these arrive through Git submodules rather than as copied source, and the tree contains an `OscPkt/` directory and a `libebur128/` directory where they are checked out. WDL is Cockos' own library, which is the same codebase the host application is built on, and TagLib handles audio file metadata. The licence point matters here and the README makes it explicitly, saying the included libraries are all similarly licensed, and the repository carries a `COPYING` file and a `license.h` at the root, so a reader can check the terms of the whole bundle rather than just the SWS code.

## Building is a CMake job with a wiki page, not a README section

There is no build command in the README. Instead, the README points to a wiki page titled Building the SWS Extension for build instructions, and separately to a wiki page on submitting pull requests. The repository root confirms the shape of the build with a `CMakeLists.txt` at the top, a `cmake/` directory, a `BuildUtils/` directory for the build helpers, a `.appveyor.yml` file, and an AppVeyor build status badge in the README. A `.appveyor.yml` plus CMake is a Windows-centric continuous integration setup, which fits a project whose host application runs on Windows and whose users are largely on that platform. The practical guidance for a contributor is therefore short. Fork the repository, send a pull request, read the two wiki pages first, and expect the build to be driven by the wiki's instructions rather than anything in the repository root.

## Contributing is welcomed, and the licence asks for a heads up

The contribution model is stated in one sentence: you are welcome to contribute, just fork the repo and send us a pull request. What follows is an unusual clause worth quoting, because it says something about how the maintainers think about reuse. The README says that while not strictly required by the license, if you use the code in your own project the maintainers would definitely like to hear from you. That is a request rather than a restriction, and it is a reasonable one for a project whose code is MIT licensed and sits on top of WDL. It also hints at a level of adoption the project does not track in the repository, since the tree itself shows no package metadata, no version scheme, and no automated distribution beyond the AppVeyor badge and the separate end-user site. The release list shows tags such as v2.14.0.7 from 2025-09-08, v2.14.0.6 from 2025-09-03, and v2.14.0.5-beta from 2025-08-08, and the last push was on 2026-05-10.

## Conclusion

SWS Extension fits a REAPER user who has outgrown the stock application and wants the community feature set without a commercial tool, and a C++ developer who wants to work on audio tooling with a permissive licence and a real build system. It does not fit a team looking for documentation in the repository, because the README is a pointer to the end-user site rather than a description of the features, and it does not fit a DAW other than REAPER, since the whole thing is a REAPER extension. Before you build it, follow the Building the SWS Extension wiki page, since the repository holds no build instructions, and check the release list, where the newest tag is v2.14.0.7 from 2025-09-08 while the last push was on 2026-05-10.

## FAQ

### What is the SWS Extension and what does it add to REAPER?

It is a C++ extension that adds a collection of features to REAPER, the Digital Audio Workstation by Cockos, Inc. The README describes the extension as a set of features that integrate into the DAW, and points to the end-user site at sws-extension.org for the capabilities and downloads.

### How do I build the SWS Extension from source?

The README does not contain the build steps and points to the wiki page titled Building the SWS Extension. The repository root holds a `CMakeLists.txt`, a `cmake/` directory, a `BuildUtils/` directory, and an `.appveyor.yml` file, so the build is CMake based and driven by the wiki instructions.

### Which third party libraries does the SWS Extension include?

The README says it includes three third party libraries that are all similarly licensed, and it lists OscPkt and libebur128, and notes that the extension also relies on TagLib and WDL. These arrive through Git submodules, with `OscPkt/` and `libebur128/` directories in the tree.

### How do I contribute to the SWS Extension?

The README says you are welcome to contribute, just fork the repo and send a pull request, and it links a wiki page on submitting pull requests. The project also asks that you let the maintainers know if you use the code in your own project, though it says that is not strictly required by the license.

### Where is the documentation for the SWS Extension?

On the end-user website at sws-extension.org, which the README points to for information on the capabilities of the extension and for downloads. The repository README is deliberately short and links out rather than documenting features in place.

## Sources

- [License: MIT](https://github.com/reaper-oss/sws/blob/master/LICENSE)
- [Project website](https://www.sws-extension.org/)
- [README](https://github.com/reaper-oss/sws/blob/master/README.md)
- [reaper-oss/sws on GitHub](https://github.com/reaper-oss/sws)
- [Releases](https://github.com/reaper-oss/sws/releases)

---

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