# Pamplejuce: a template for shipping JUCE audio plugins > Pamplejuce is a JUCE plugin template that comes with the parts a plugin project normally has to assemble by hand: a C++23 CMake setup, Catch2 tests and benchmarks, pluginval validation in CI, macOS notarization and Windows code signing through Azure Trusted Signing. The trade-off is that it tracks JUCE's develop branch and its own release history is thin. **sudara/pamplejuce** — A JUCE audio plugin template. JUCE 8, Catch2, Pluginval, macOS notarization, Azure Trusted Signing, Github Actions - Repository: https://github.com/sudara/pamplejuce - Website: https://melatonin.dev/manuals/pamplejuce - Stars: 775 · Forks: 75 - Language: C++ - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/sudara-pamplejuce ## A template that arrives as a working project Pamplejuce is the JUCE audio plugin template maintained by sudara, and the README opens with a correction of its own framing. It is a template lifestyle for creating and building JUCE plugins in 2026, with the word template struck through. The joke is that a template is what you copy and then throw away, whereas this is a repository you keep, and the surrounding tooling is what makes keeping it worthwhile. The repository description reads as a list of what is inside: JUCE, Catch2, Pluginval, macOS notarization and Azure Trusted Signing, wired into GitHub Actions. The homepage is a manual rather than a landing page, at melatonin.dev/manuals/pamplejuce, and the documentation is treated as part of the project rather than an appendix to it. The technical baseline is stated as a numbered list. It runs C++23, uses JUCE 9.x as a git submodule tracking the develop branch, uses CPM for dependency management, and relies on CMake 3.25 or higher for cross-platform building. Tests use Catch2 v3.8.1, and there is a Tests target and a Benchmarks target with examples to start from. Melatonin Inspector is installed as a JUCE module to take the pain out of building a plugin user interface. There is one inconsistency worth flagging before you rely on the description. The repository description still says JUCE 8, while the README says the submodule tracks JUCE 9.x develop. The README is the more current of the two, and the template is pinned to a moving branch, so the exact JUCE revision you get depends on when you clone. ## CMake configuration, a VERSION file and a shared ignore list The repository layout is a working plugin project rather than a skeleton. At the top level there is a CMakeLists.txt, a cmake directory, modules for the JUCE modules including the inspector, source for the plugin code, tests, benchmarks, packaging for the platform artefacts, docs and an assets directory. A .gitmodules file records the JUCE submodule, and a JUCE directory holds it. Three small files carry more weight than their size suggests. The .gitignore is described as covering all platforms, which is the kind of detail that otherwise leaks build artefacts into a diff on the first macOS build. The .clang-format file keeps the C++ tidy without each contributor inventing a style. And the VERSION file propagates through JUCE and into the application, so there is a single place to bump a version rather than a constant duplicated in several build files. The CMake configuration is where the template earns its name. The README describes it as carrying a lot of useful comments and options, and for a JUCE project that file is where the awkward decisions live: the format definitions, the module list, the plugin descriptors, the per-platform compile settings and the output naming. Copying a well-annotated version of that file is worth more than any amount of example code, because the example code is the part you delete. Dependency management goes through CPM rather than a Julia-style manifest or a vendored copy, so the Catch2 dependency and any others are fetched during the CMake configure step rather than committed into the tree. ## Tests, benchmarks and the plugin UI inspector The testing setup is part of the template rather than an add-on. Catch2 v3.8.1 is the framework and runner, the repository ships a Tests target and a Benchmarks target, and both come with examples so that the first thing you do is edit a working case instead of wiring up a target from nothing. The CI integration runs the tests and the benchmarks, which means a benchmark you add is measured on every push rather than only on your machine. For a plugin, the unit tests cover the DSP, but the parts that break in practice are the editor, the state save and load, and the parameter handling. That is where Melatonin Inspector earns its place as a JUCE module. It gives a developer a view of a running plugin's internals, so a parameter that is not wired up or a state mismatch is visible rather than guessed at. For a framework with the surface area that JUCE has, the README puts it plainly, the module is there to help relieve the headaches of building the plugin UI. The validation layer is separate again, and it is pluginval. The CI runs pluginval 1.x against the built binaries, which is a separate project that checks a plugin for the kinds of mistakes that a unit test will not catch, such as a plugin that misbehaves when the host scans its parameters or when the editor is opened and closed repeatedly. Together the three layers cover different failure modes: Catch2 for the logic, the inspector for the editor, pluginval for the host-facing contract. ## CI that builds on three platforms and signs on two The GitHub Actions integration is the part of the template that would take a team the longest to reproduce. The list in the README covers building and testing cross-platform binaries for Linux, macOS and Windows, running the tests and the benchmarks in CI, running pluginval 1.x against the binaries, a configuration for installing Intel IPP, code signing and notarization on macOS, and Windows code signing through Azure Trusted Signing. Two of those deserve comment. Intel IPP is an Intel library of optimized primitives, and the template ships a configuration step that installs it, which suggests the plugin code is expected to use IPP on the platforms where it is available. And Azure Trusted Signing is Microsoft's cloud signing service, so a Windows binary gets a certificate without the maintainer holding a hardware token, with the workflow doing the work. The macOS path is the one with the most moving parts, since a plugin for that platform has to be signed, notarized and stapled before a user can run it without warnings. The README links a separate article on signing and notarizing macOS audio plugins in CI, which is where the detail lives. The consequence for a user of the template is that the first build produces artefacts that a host will accept, rather than a local build that works for the developer and nothing else. For distribution, that is the difference between a project and a demo. ## Using the template: your own copy, and the first red test run The repository is a GitHub template, not a fork target. The README is explicit that you should use the Use this template button to get your own copy rather than forking, and that the copy can be private or public as you prefer. That distinction matters for a template with a CI history: a fork inherits the upstream workflow runs and the upstream repository as parent, while a template copy starts with a clean history that is yours. After the copy, the README points to the setup documentation so you know what to change, and the document is a checklist of the values that have to be edited: the project name, the identifiers, the bundle and signing settings, and the CI configuration. There is a warning in the README that catches people out. Tests will immediately run and fail, going red, until code signing is set up. In other words, the first CI run on your fresh copy is expected to fail, and the cause is a missing signing configuration rather than a broken template. The reason is structural: the CI runs on the hosted runners, and a build that is not signed cannot be validated on those machines in the way the workflow expects. The template also has an unusual accommodation for a newer way of working. The included CLAUDE.md and AGENTS.md carry a first-time setup wizard, and the README tells an AI coding agent to run it to set up the project, with the wizard walking through naming, CI configuration and code signing. Whether or not you use an agent, that file is a compact description of the setup order, which is the part that is easy to get wrong by hand. ## Release history, licence and what the template does not decide for you The licence is MIT, with the text in the LICENSE file at the repository root, which is the permissive default a template should have: you are not obliged to publish your plugin's source because you started from this repository. The release history is thin, and it is worth understanding why. The two tags are v0.0.1 from 2023-03-28 and v0.0.2 from 2025-01-22, while the last push was on 2026-10-17. The project is a template, so its releases are not the artefacts most people consume; the artefacts are the copies people generate. The tags mark the state of the template itself, and the fact that the last push is nine months after the last tag tells you that improvements land on the default branch without a release being cut for them. That distinction is also a warning for anyone who depends on the template rather than copying it. A dependency on the template upstream means tracking a repository whose releases are rare, whose JUCE submodule follows the develop branch, and whose CI configuration is a moving target. Copying it is the intended use, and copying it means you own that maintenance. What the template deliberately does not decide is the plugin itself: the DSP, the parameter set, the preset format, the editor design and the licensing model of the resulting product are yours. The README is candid about the scope of the repository, describing it as covering a lot of ground, noting that JUCE itself has a lot of surface area, and framing maintenance as a group effort, which is an admission that a template this size is more than one person can keep in shape indefinitely. ## Conclusion Adopt Pamplejuce if you are starting a JUCE plugin and would rather inherit a working cross-platform CI, pluginval validation and code signing setup than assemble those yourself. Do not adopt it if you need a pinned JUCE version, because the template tracks the develop branch, or if you need a template with a release cadence of its own, since the last tagged release is v0.0.2 from 2025-01-22. Before you start, set up code signing first, because the README warns that the tests go red until signing is configured, and read the setup page at melatonin.dev/manuals/pamplejuce for the values you need to change. ## FAQ ### What does Pamplejuce give me out of the box? A C++23 project on CMake 3.25 or higher, JUCE 9.x as a git submodule tracking develop, CPM for dependency management, Catch2 v3.8.1 with Tests and Benchmarks targets, and the Melatonin Inspector installed as a JUCE module for debugging the plugin interface. ### How do I get my own copy of Pamplejuce? The README says to use the Use this template button on the repository rather than forking, so that you get your own copy instead of one that keeps the upstream as its parent. The copy can be private or public. ### Why do the tests fail on a fresh copy of Pamplejuce? The README warns that tests will run and fail until code signing is set up. It is not a broken template, it is a missing signing configuration, and the setup documentation lists what to fill in. ### What does the CI in Pamplejuce do? It builds and tests binaries for Linux, macOS and Windows, runs the tests and the benchmarks, runs pluginval 1.x against the binaries for plugin validation, installs Intel IPP, and handles macOS signing and notarization plus Windows code signing through Azure Trusted Signing. ### Which JUCE version does Pamplejuce use? The README says JUCE 9.x is included as a git submodule that tracks the develop branch, so the revision you get depends on when you clone. The repository description still refers to JUCE 8, which is out of date. ## Sources - [License: MIT](https://github.com/sudara/pamplejuce/blob/main/LICENSE) - [Project website](https://melatonin.dev/manuals/pamplejuce) - [README](https://github.com/sudara/pamplejuce/blob/main/README.md) - [Releases](https://github.com/sudara/pamplejuce/releases) - [sudara/pamplejuce on GitHub](https://github.com/sudara/pamplejuce) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sudara-pamplejuce